Bootstrap Architecture That Lasts: Boundaries, Testing, and Maintainability in Real Teams

[0:00]Rustam: Welcome to the Bootstrap Stack podcast, where we dig into the patterns and pitfalls of building scalable interfaces with Bootstrap in the real world. I'm your host, Jamie, and today we’re tackling an issue that haunts almost every team: how do you design a Bootstrap architecture that survives more than a handful of contributors or rapid feature growth?

[0:45]Rustam: Joining me is Morgan Ruiz, Lead Frontend Architect at Ensemble Systems. Morgan’s seen Bootstrap projects from their first commit to the thousandth pull request. Morgan, thanks for coming on!

[1:05]Morgan Ruiz: Thanks so much for having me, Jamie. I’ve definitely seen my share of Bootstrap codebases that evolved a little...let’s say unexpectedly.

[1:25]Rustam: I love that. We’re here to talk about boundaries, testing, and maintainability—three words everyone uses, but few define in actionable terms. So let’s start at the beginning: why do teams keep running into trouble with Bootstrap as projects grow?

[2:05]Morgan Ruiz: Great question. Bootstrap is fantastic for quick iteration and getting consistent UIs out the door, but it’s easy to forget how fast a codebase can balloon. The main issue is that teams often treat Bootstrap like a magic bullet—just add classes, ship, and move on. But as requirements change, you end up with overrides, duplicated patterns, and a lot of global styling that’s hard to unwind.

[2:40]Rustam: So, it’s a classic case of short-term wins stacking up long-term headaches?

[2:55]Morgan Ruiz: Exactly. It’s quick until it isn’t. Once you have five people working in the same codebase, or the product pivots, those little hacks and overrides become landmines.

[3:15]Rustam: Let’s pause and define what we mean by 'boundaries' in Bootstrap architecture. How would you put it in plain language?

[3:40]Morgan Ruiz: For me, boundaries are about drawing clear lines between components, features, and even responsibility. In Bootstrap, that means ensuring your CSS, your JavaScript behaviors, and your customizations stay as isolated as possible. So, a button in one module shouldn't accidentally break another feature just because someone changed a class or a variable.

[4:10]Rustam: That makes sense. Do you have an example from your experience where missing boundaries led to a real mess?

[4:45]Morgan Ruiz: Absolutely. I worked with a fintech team where, over time, every new feature just piggybacked off the main Bootstrap theme file. There was a set of global overrides for every button, table, and alert—no separation at all. Eventually, changing a warning color in one place broke a dozen unrelated features. Debugging became a nightmare, and at one point, half the team was afraid to touch the stylesheets.

[5:25]Rustam: Ouch. That sounds familiar for a lot of listeners. What should they have done differently?

[5:45]Morgan Ruiz: The first thing is to scope your changes. If you need to override Bootstrap, do it inside a component or feature-specific file. Make sure your selectors are narrowly targeted. And it helps to have a pattern—like using BEM naming or CSS Modules—so you don’t end up with global collisions.

[6:15]Rustam: Let’s talk about the temptation to just throw everything in global styles. Why does that keep happening even when teams know better?

[6:40]Morgan Ruiz: Honestly, speed. When teams are in crunch mode, global styles feel faster. You add a class or override a variable, and it 'just works'—for now. The cost comes later, when you have to figure out why one feature breaks another, and you realize that quick fix was actually a time bomb.

[7:00]Rustam: Let’s walk through a mini case study. Can you share a story where a Bootstrap project spiraled out of control—and how you helped reel it back in?

[7:30]Morgan Ruiz: Sure. At one point, we inherited a dashboard project that had started as a proof of concept. By the time we got involved, there were hundreds of overrides, custom classes, and even some inline styles. Nothing was documented. The first thing we did was a style audit—mapping out which styles affected which features. We then modularized the stylesheets, so each feature owned its own overrides. It took a few sprints, but suddenly, new bugs stopped popping up in unrelated areas.

[8:20]Rustam: That’s a great playbook. For teams starting fresh, what’s the very first thing to do to avoid that fate?

[8:40]Morgan Ruiz: Set up a clear folder structure and naming convention from day one. Even if it feels like overkill, you’ll thank yourself later. And document your approach—who owns which part of the styles, and how customization should be handled.

[9:10]Rustam: I want to zoom in on the word 'boundaries' again. Are we just talking about CSS, or does this spill over to JavaScript and HTML, too?

[9:30]Morgan Ruiz: It’s all connected. Bootstrap isn’t just CSS—it’s also markup structure, and sometimes JavaScript behaviors. If you don’t have clear boundaries in your HTML and JS, you end up with leaky abstractions. For example, modal dialogs can easily conflict if you’re not careful about unique IDs and event handling.

[9:55]Rustam: So you’re saying a well-architected Bootstrap project considers the whole stack, not just the styles?

[10:10]Morgan Ruiz: Exactly. The best teams treat their Bootstrap code as part of a broader system, not just a theme. That means making sure components are self-contained, have predictable APIs, and don’t rely on global side effects.

[10:30]Rustam: Let’s get concrete. How do you define a boundary for a Bootstrap component? Say, a custom dropdown.

[10:50]Morgan Ruiz: For a dropdown, I’d create a dedicated folder with its own SCSS file, maybe a small JavaScript module if needed, and a set of markup guidelines. All overrides and customizations would be inside that folder. No leaking styles or IDs to the global scope. That way, if you need to change its appearance or behavior, you know exactly where to look.

[11:20]Rustam: You mentioned BEM naming and CSS Modules earlier. For listeners who aren’t familiar, can you explain what those are and why they help?

[11:40]Morgan Ruiz: Absolutely. BEM—or Block Element Modifier—is a naming convention that structures class names like 'button--primary' or 'dropdown__item'. It helps you see the relationships between elements and avoids ambiguity. CSS Modules are a way to scope your styles automatically, so classes only apply where you import them. Both help enforce boundaries and prevent accidental style leaks.

[12:10]Rustam: Let’s shift to encapsulation. Why is it so hard to keep Bootstrap components encapsulated in real-world projects?

[12:40]Morgan Ruiz: The main culprit is inheritance and specificity. Bootstrap’s global selectors are designed for flexibility, but that means your overrides can get tangled fast. If two teams tweak the same component in different ways, specificity wars break out. The trick is to minimize how often you need to override at all—ideally, you customize via variables and documented extension points, not by brute-forcing selectors.

[13:10]Rustam: What’s your take on using !important in Bootstrap overrides?

[13:25]Morgan Ruiz: It’s a last resort. If you need !important, it usually means your architecture is struggling. Sometimes it’s unavoidable—maybe you’re integrating with third-party code—but in most cases, it’s better to refactor your selectors or reconsider your approach.

[13:50]Rustam: Let’s get practical. What’s a pattern you’ve used to avoid global overrides when customizing Bootstrap?

[14:10]Morgan Ruiz: One pattern is wrapping your custom components in a namespace class—like '.app-dashboard'—so all your overrides are scoped under that parent. That way, you don’t touch the global Bootstrap classes directly, and your changes only apply where you intend.

[14:30]Rustam: Are there trade-offs to that approach? Does it make the HTML more complex?

[14:45]Morgan Ruiz: A little, yes. You add a wrapper div, and your selectors get longer. But in exchange, you get predictability and avoid accidental regressions. For me, it’s worth the minor complexity.

[15:00]Rustam: Let’s talk about global styles. When—if ever—should teams use them in Bootstrap projects?

[15:30]Morgan Ruiz: Global styles are fine for true base elements—like resetting box-sizing or setting a default font. But for anything application-specific, keep it local to the component or feature. Think of global styles as a shared foundation, not a dumping ground for every tweak.

[15:55]Rustam: What’s the most common pitfall you see with global styles in Bootstrap?

[16:10]Morgan Ruiz: Teams often start by copying the Bootstrap theme file and adding their changes directly. That works for tiny projects, but once you have more than a handful of features, every new style risks breaking something old. I've seen teams spend days tracking down which global override broke a form or modal.

[16:35]Rustam: What’s a better way to manage customizations?

[16:55]Morgan Ruiz: Leverage Bootstrap’s variables and SASS customization points as much as possible. If you need to go further, isolate custom overrides by feature, and document why each one exists. The best teams can look at a color or spacing and trace it directly to a feature owner.

[17:10]Rustam: Let’s delve into best practices. What are your top two for modular Bootstrap code?

[17:30]Morgan Ruiz: First, use a consistent file structure—group components, utilities, and themes separately. Second, document every override and deviation from the default Bootstrap styles. When someone new joins, they should know immediately where to look and what the rules are.

[17:55]Rustam: What about CSS-in-JS or modern frameworks? Do those change the Bootstrap story?

[18:15]Morgan Ruiz: They help, but they don’t solve everything. CSS-in-JS can encapsulate styles at the component level, but if your team is still using Bootstrap classes globally, the same risks apply. The architecture principles matter no matter the technology.

[19:10]Rustam: Let’s take a listener question. Alex asks: 'How strict should we be with naming conventions in a shared Bootstrap codebase?'

[19:30]Morgan Ruiz: Very strict. Naming conventions are like traffic signals—they keep everyone moving in the same direction. Whether you use BEM, custom prefixes, or something else, consistency is key. Otherwise, the codebase turns into a guessing game.

[20:05]Rustam: Let’s pivot to testing. Bootstrap is often seen as 'just CSS,' but what’s your philosophy on testing Bootstrap UIs?

[20:35]Morgan Ruiz: Testing is essential, especially as teams grow. I think of it in three layers: unit tests for any custom JavaScript or logic, integration tests to check component behavior, and visual regression tests to catch style drift. Bootstrap makes things predictable, but only if you test your customizations.

[21:05]Rustam: Can you expand on visual regression testing? A lot of teams skip it.

[21:25]Morgan Ruiz: Visual regression testing compares screenshots of your UI before and after code changes. Tools like Percy or Chromatic highlight even tiny unexpected shifts. It’s a lifesaver when you’re refactoring styles or upgrading Bootstrap versions—you catch the pixel-level regressions before users do.

[21:55]Rustam: Any tips for making visual regression part of the workflow without slowing everyone down?

[22:15]Morgan Ruiz: Automate it! Integrate it with your CI pipeline, so every pull request runs visual checks. And set clear thresholds—some differences are OK, but major layout shifts should block a merge.

[22:40]Rustam: Where do unit, integration, and visual tests fit together? Do you always need all three?

[23:00]Morgan Ruiz: Not always, but the bigger the team or the older the codebase, the more you need the full stack. Unit tests catch logic bugs, integration tests catch interaction problems, and visual tests catch style drift. If you skip any layer, you risk surprises.

[23:25]Rustam: What’s a common mistake teams make with Bootstrap testing?

[23:45]Morgan Ruiz: Relying only on manual QA. Teams often assume Bootstrap’s defaults are safe, but customizations break things in subtle ways. Automated tests are your safety net.

[24:05]Rustam: Let’s bring in another mini case study. Can you share a story where testing saved—or failed—a Bootstrap project?

[24:40]Morgan Ruiz: Absolutely. We once upgraded a project from Bootstrap 3 to 4. Without visual regression tests, we would have missed a dozen subtle spacing bugs—forms that shifted, buttons that wrapped, alerts that lost their icons. Automated screenshots caught every one. On another project, no tests meant a quick theme tweak broke crucial accessibility—for weeks, nobody noticed.

[25:20]Rustam: So, for listeners upgrading Bootstrap, visual regression is a must-have?

[25:35]Morgan Ruiz: Absolutely. It gives you confidence to move fast. Otherwise, you’re playing whack-a-mole with UI bugs.

[25:50]Rustam: Let’s talk about breaking out of Bootstrap monoliths. What does that process look like in practice?

[26:15]Morgan Ruiz: It starts with mapping dependencies. Figure out which components are tightly coupled, then refactor them into standalone modules. Each module gets its own styles and tests. Over time, you migrate features out of the global namespace. It’s work, but it pays off fast.

[26:45]Rustam: What’s the biggest challenge teams face when modularizing a legacy Bootstrap project?

[27:05]Morgan Ruiz: Untangling deeply nested selectors and undocumented overrides. Sometimes, the hardest part is just understanding what affects what. That’s why audits and incremental refactoring are key—you can’t fix everything at once.

[27:30]Rustam: As we wrap up this first half, let’s recap: set boundaries, scope your styles, and invest in testing. Anything you’d add before we dive deeper into maintainability next?

[27:30]Rustam: Alright, so we’ve covered the basics of boundaries and why they matter. Let’s zoom in now on some of the real-world challenges teams hit once the project grows beyond that first prototype. What tends to break down first when a Bootstrap-based app starts scaling with a real team?

[27:46]Morgan Ruiz: That’s a great way to frame it. What usually cracks first is the implicit contracts between different parts of the codebase. Early on, it’s easy for one developer to just reach across a boundary—say, from a UI component straight into a data service. But once more people join, those blurred lines create confusion. Suddenly, two developers are making changes in the same layer, stepping on each other’s toes.

[28:05]Rustam: Yeah, I’ve seen that. You end up with components that know too much, right? They’re not just displaying data but fetching it, mutating it, formatting it, sometimes even handling business rules.

[28:22]Morgan Ruiz: Exactly. And in Bootstrap projects—which often start small and grow rapidly—it’s tempting to skip enforcing those boundaries at first. But the longer you wait, the more tangled things get. Technical debt accumulates, and then you hit a wall where even small changes require risky refactors.

[28:34]Rustam: So, let’s get practical. What’s one thing a team can do, today, to prevent those blurred boundaries in a Bootstrap app?

[28:51]Morgan Ruiz: Start by defining clear interface contracts. Even if it’s just a TypeScript interface or a Python docstring, make it clear what each module expects and returns. Take a day to write out the responsibilities for each layer—the UI, business logic, and data. If you can’t describe what a component should or shouldn’t do, it probably means the boundary is still too fuzzy.

[29:10]Rustam: Nice. Let’s pivot to testing for a moment. Bootstrap is famous for getting teams off the ground quickly, but automated testing often lags behind. Why do you think that is?

[29:30]Morgan Ruiz: There’s this perception that tests slow you down at the start, so teams defer them. But the real slowdown comes when you don’t have tests and you’re scared to deploy, or you’re constantly fixing regressions. In Bootstrap-based projects, tests are often skipped because the code feels straightforward—until it isn’t. And then, when you try to backfill tests, you find the architecture doesn’t support isolation.

[29:46]Rustam: So it’s a classic case of ‘move fast, pay later’. Have you seen any teams recover from skipping tests early on?

[30:06]Morgan Ruiz: I have, but it takes a deliberate effort. One team I worked with built an internal dashboard using Bootstrap components. At first, they relied on manual QA and just tested in the browser. A year in, as the dashboard became critical for business operations, small changes started breaking unexpected features. They paused feature work for two sprints, wrote a test harness for their key workflows, and then refactored their components to be more testable. Painful, but it stabilized their velocity and confidence.

[30:29]Rustam: That’s a great example. Did they do anything specific to make Bootstrap components more testable?

[30:44]Morgan Ruiz: Yes, they started using more container-presentational splits, even though Bootstrap tends to encourage reusable UI widgets. By separating logic from presentation, they could test the logic independently, mocking the Bootstrap UI layer. They also introduced data-test attributes to make selectors more robust for automation.

[31:02]Rustam: Love that. Let’s get into maintainability. What are some common anti-patterns you see in Bootstrap-heavy codebases when it comes to long-term maintenance?

[31:20]Morgan Ruiz: There are a few classics: one is ‘CSS soup’, where every component ends up with its own styles, often copy-pasted and slightly tweaked, so you get a mess of overrides. Another is what I call ‘utility class overload’—using so many Bootstrap classes that the HTML is unreadable, and small design tweaks require hunting down a dozen class names. Finally, business logic sneaks into the UI layer, making it hard to reuse or test.

[31:43]Rustam: That’s so true. I’ve seen teams try to fix that with custom utility classes, but then you lose consistency. What’s the right balance for teams who want to customize Bootstrap without breaking maintainability?

[31:59]Morgan Ruiz: I recommend treating Bootstrap as a foundation, not the finished product. Define your own design tokens—colors, spacing, typography—and map them to Bootstrap variables. If you need custom utilities, keep them minimal and well-documented. Regularly audit your stylesheets and prune unused classes. And always have a single source of truth for your design decisions, even if it’s just a shared Google Doc.

[32:17]Rustam: Let’s pause for a mini case study. Can you share a story where maintainability was preserved, or maybe lost, in a Bootstrap project?

[32:33]Morgan Ruiz: Sure. I worked with a SaaS startup that built their client portal with Bootstrap. They started strong: centralized variables, clear boundaries, and a small set of custom components. But as pressure mounted to ship features, they let developers add inline styles and new utility classes for one-off needs. Six months later, the CSS bundle was massive and hard to debug. To recover, they did a style audit, removed 40% of unused rules, and created a living style guide. After that, onboarding new devs became much easier.

[32:58]Rustam: That’s a great turnaround. So, boundaries, testing, maintainability—they’re all connected. How does team culture play into whether these patterns actually survive real-world pressure?

[33:15]Morgan Ruiz: Culture’s everything. If a team values shipping at all costs, they’ll cut corners, and architecture suffers. But if leadership carves out time for code reviews, refactoring, and documentation, it signals that maintainability matters. Celebrating small wins, like deleting dead code or improving test coverage, also helps. In healthy cultures, people speak up when boundaries start to blur.

[33:32]Rustam: Let’s do a quick rapid-fire round. I’ll throw out a Bootstrap pattern or concept, and you give me your gut take—good, bad, or ‘it depends’. Ready?

[33:37]Morgan Ruiz: Let’s do it!

[33:39]Rustam: Global CSS overrides.

[33:42]Morgan Ruiz: Necessary sometimes, but risky—document every override.

[33:45]Rustam: Bootstrap grid versus custom Flex layouts.

[33:48]Morgan Ruiz: Bootstrap grid for speed, custom Flex for unique layouts—mix carefully.

[33:51]Rustam: Inline styles in components.

[33:54]Morgan Ruiz: Quick for prototyping, avoid in production.

[33:57]Rustam: Component libraries built on top of Bootstrap.

[34:00]Morgan Ruiz: Great for consistency, but watch out for version lock-in.

[34:03]Rustam: Using !important in CSS.

[34:06]Morgan Ruiz: Last resort only—signals a boundary problem.

[34:09]Rustam: Adding JavaScript directly to Bootstrap HTML.

[34:12]Morgan Ruiz: Can work, but separate concerns whenever possible.

[34:15]Rustam: Bootstrap themes—buy or build?

[34:18]Morgan Ruiz: Buy for speed, build for control. Hybrid is fine.

[34:21]Rustam: Alright, last one—Bootstrap icons or custom SVGs?

[34:24]Morgan Ruiz: Bootstrap icons for quick wins, custom SVGs for branding.

[34:29]Rustam: Awesome. Thanks for playing. Let’s talk about testing strategies that actually work in Bootstrap-heavy apps. What’s your first move when introducing automated tests into an existing legacy codebase?

[34:46]Morgan Ruiz: Start with smoke tests—basic end-to-end tests that cover the main user flows. It’s tempting to dive into unit tests, but if you don’t know what’s critical, you’ll waste time. Once you’ve got green lights on the main paths, identify brittle areas—usually forms or dynamic tables—and add targeted component tests. Don’t try to get 100% coverage overnight.

[35:06]Rustam: Do you recommend snapshot testing for Bootstrap UIs?

[35:17]Morgan Ruiz: It’s helpful for catching unexpected changes, but don’t rely on it alone. Bootstrap updates can cause lots of noise in snapshots. Use them as a safety net, not as your main strategy.

[35:28]Rustam: Let’s tackle a second case study. Any stories where testing saved a team from disaster?

[35:41]Morgan Ruiz: Definitely. I consulted for a healthcare startup with a patient portal built on Bootstrap. One day, a third-party library update broke their appointment scheduler. Their automated test suite flagged the issue before deployment—otherwise, patients would have lost access. Because they had clear test boundaries, they could roll back safely and isolate the problem quickly.

[36:01]Rustam: That’s the dream! It shows the ROI of investing in tests, even if it’s not glamorous.

[36:06]Morgan Ruiz: Exactly. And it builds trust—between devs, and with stakeholders, too.

[36:11]Rustam: Let’s dig into refactoring. Say you inherit a Bootstrap app with tangled boundaries and no tests. Where do you start?

[36:28]Morgan Ruiz: First, map out the current structure. Draw diagrams—what talks to what? Identify hotspots: files that change often or break frequently. Then, pick one boundary to clarify. Maybe split data access from UI, or extract business logic into services. Write a few high-level tests as you go. Don’t try to fix everything at once—incremental wins add up.

[36:44]Rustam: And what are the warning signs that you’re refactoring too aggressively?

[36:57]Morgan Ruiz: If you’re rewriting more than 20% of the codebase at once, or if pull requests are getting stuck in review for weeks, that’s a red flag. You want steady, reviewable progress—not a big bang rewrite.

[37:12]Rustam: Let’s transition to maintainability again. How do you keep a Bootstrap codebase healthy as team size grows?

[37:27]Morgan Ruiz: Documentation is key—a living style guide, clear folder structure, and onboarding guides for new devs. Regular code reviews focused on boundaries and testability. And a culture where it’s okay to ask ‘why does this component exist here?’ or ‘can we move this logic out?’.

[37:41]Rustam: Do you recommend any tools for tracking architectural drift in Bootstrap projects?

[37:54]Morgan Ruiz: There are static analysis tools that can help, like dependency graph generators. Even a simple script to list all CSS classes in use can reveal duplication or drift. Regularly review your bundle size and audit for unused code.

[38:08]Rustam: Nice. As we approach the end, I want to do an implementation checklist—sort of a spoken summary for listeners. Can you walk us through the steps?

[38:28]Morgan Ruiz: Absolutely. Here’s my recommended checklist for Bootstrap architecture that survives real teams: 1. Define clear boundaries—UI, business logic, and data layers. 2. Document interface contracts, even minimally. 3. Start with smoke tests for main flows. 4. Regularly review and prune CSS and utility classes. 5. Use a living style guide as your design source of truth. 6. Practice incremental refactoring—don’t rewrite everything at once. 7. Foster a culture of code reviews and knowledge sharing.

[38:58]Rustam: That’s gold. I love the focus on incremental change and culture. Anything you’d add for teams just starting out?

[39:11]Morgan Ruiz: Don’t underestimate the power of a shared language—agree on naming conventions and folder structures early. It saves so much pain down the road.

[39:24]Rustam: Alright, before we wrap, let’s take one audience question. This one’s from a listener who asks: ‘How do you balance Bootstrap’s out-of-the-box features with custom branding requirements?’

[39:41]Morgan Ruiz: Great question. Start by customizing Bootstrap’s variables—colors, fonts, spacing—so your app feels on-brand right away. For unique elements, build custom components that use your design tokens. Avoid overriding Bootstrap styles directly whenever possible; instead, extend them. And always document your customizations so future devs know what’s intentional.

[40:01]Rustam: Excellent advice. Any closing thoughts on why investing in boundaries, testing, and maintainability pays off—especially for Bootstrap teams?

[40:17]Morgan Ruiz: It’s really about future-proofing your work. Bootstrap gets you moving fast, but the real success comes from being able to change direction without breaking everything. Boundaries, tests, and good habits turn a quick prototype into a stable, evolving product.

[40:31]Rustam: Couldn’t have said it better. Let’s do a very quick recap for folks listening on the go. Three main takeaways from today’s chat?

[40:42]Morgan Ruiz: One: Set and respect boundaries early. Two: Invest in testing before you think you need it. Three: Prioritize maintainability, even when deadlines loom.

[40:54]Rustam: Love it. Thank you so much for joining us today and sharing these hard-won insights. Where can listeners connect with you or learn more?

[41:07]Morgan Ruiz: I’m active on developer forums and occasionally write deep-dives on architectural patterns. You can find links in the episode notes.

[41:18]Rustam: Perfect. Thanks again! Before we officially close, any final words for teams out there wrestling with their Bootstrap codebases right now?

[41:32]Morgan Ruiz: Don’t be afraid to pause and clean things up. A few days spent on boundaries and tests now can save you from weeks of headaches later. And don’t go it alone—engage your teammates in the process.

[41:46]Rustam: Great advice. That’s a wrap for today’s episode on Bootstrap architecture patterns that survive real teams. Check the show notes for resources and links, and be sure to subscribe for more episodes on practical software architecture. Thanks for listening, and we’ll see you next time!

[41:55]Morgan Ruiz: Thanks for having me! Happy coding, everyone.

[42:06]Rustam: And as always, if you enjoyed this episode, leave us a review and share your own architecture war stories with us—we’d love to hear them. Until next time, keep your boundaries strong and your code maintainable. Bye!

[42:16]Morgan Ruiz: Bye!

[42:28]Rustam: And that brings us to the end of today’s show. Thanks again for tuning in to Softaims. Stay curious, stay pragmatic, and we’ll catch you in the next episode.

[42:35]Morgan Ruiz: Take care!

[55:00]Rustam: Signing off.