Evolving Patterns and Modern Trends in React Native

[0:00]Matthew: Welcome back to the React Native Stack podcast, where we dig deep into the real-world patterns shaping mobile development. I’m your host, Jamie Patel, and today we’re exploring the evolving landscape of React Native architecture—what’s changing, why it matters, and how to make the right choices for your team. Joining me is Samantha Lin, Lead Architect at MobileCraft Solutions. Samantha, thanks for coming on.

[0:15]Samantha Lin: Thanks for inviting me, Jamie. I’m excited to get into the nitty-gritty of how teams are rewriting the rulebook with React Native.

[0:28]Matthew: Before we dive in, could you share a little about your background and what you do at MobileCraft?

[0:40]Samantha Lin: Absolutely. I lead our architecture group, focusing on mobile experiences across multiple business domains. I’ve spent the last several years helping teams transition from legacy React Native setups to modern, maintainable architectures—sometimes painfully, but always learning.

[1:40]Matthew: We love those battle scars. Let’s start big picture: why are React Native architectures changing so much these days?

[1:55]Samantha Lin: A few things. First, mobile apps are just more complex now—think more features, integrations, edge cases. Second, teams are growing, and old code organization patterns just don’t scale. And finally, the ecosystem has matured: tools and community patterns have caught up to the pain points.

[2:18]Matthew: So, it’s not just hype—it’s necessity?

[2:25]Samantha Lin: Exactly. We’re seeing the limits of early React Native approaches: single giant files, no clear boundaries, and a lot of copy-paste. When you hit a certain size, everything slows down—builds, onboarding, even decision-making.

[3:00]Matthew: What about maintainability? I hear that word thrown around, but what does it mean in practice for a React Native team?

[3:10]Samantha Lin: It’s about making sure a new developer can jump in and not get lost. If your codebase is a maze, every change is risky. Maintainable means well-organized, tested, and—ideally—modular, with clear ownership.

[4:05]Matthew: Let’s pause and define that. When you say ‘modular’, what are we talking about?

[4:15]Samantha Lin: Great question. Modular means breaking your app into smaller, self-contained pieces—modules—that handle one concern each. For example, you might have a payments module, a user profile module, etc. Each can be built, tested, and deployed independently.

[4:50]Matthew: What does that look like in practice? Are we talking about separate repos, or something else?

[5:05]Samantha Lin: Usually, it’s a monorepo—a single repository housing all your modules. But you can also split by features inside one repo. The point is to avoid one massive folder with everything mixed together.

[6:30]Matthew: So, what’s driving teams to revisit architecture now, not just keep patching up the old way?

[6:45]Samantha Lin: Honestly, pain. When you spend hours trying to figure out why a change in one place broke something totally unrelated, you realize patching isn’t enough. Plus, as apps add more features, you need clearer boundaries to move quickly without breaking things.

[8:20]Matthew: Let’s get specific: what’s an architectural pattern, and why does it matter for React Native?

[8:35]Samantha Lin: An architectural pattern is a reusable solution for organizing code. Think about the Model-View-Controller pattern in web apps—React Native teams might choose patterns like feature-based, domain-driven, or layered architectures. Each shapes how you separate concerns and manage dependencies.

[9:15]Matthew: Are there trade-offs between these patterns?

[9:25]Samantha Lin: Definitely. Layered architectures can feel organized but sometimes get rigid—too many rules. Feature-based makes it easier to find everything related to one part of the app, but you can accidentally duplicate code or blur boundaries.

[10:10]Matthew: Let’s talk about the classic ‘big ball of mud’—the anti-pattern. What’s the risk there?

[10:25]Samantha Lin: The big ball of mud is where everything’s tangled—no clear structure, just a lot of interconnected code. Small teams can survive with it for a while, but as you grow, it becomes impossible to test, refactor, or even onboard engineers. Eventually, you grind to a halt.

[11:15]Matthew: So modularization is the antidote. How do teams actually achieve that in React Native?

[11:30]Samantha Lin: A lot of teams start by splitting business features into folders, then extract shared utilities. For bigger orgs, monorepos with tools like Yarn Workspaces or TurboRepo help manage dependencies between modules. The goal is clear: each module should have a single responsibility.

[13:00]Matthew: But let’s be real—it doesn’t always go smoothly. Can you share an example where modularization went wrong?

[13:20]Samantha Lin: Absolutely. At a previous company, we rushed into modularization—split everything up, but didn’t define interfaces well. Suddenly, teams were duplicating logic because nobody knew where the source of truth was. We ended up with modules depending on each other in circles, and builds broke constantly.

[14:05]Matthew: Ouch. How did you fix it?

[14:15]Samantha Lin: We hit pause, mapped out clear ownership, and enforced interface contracts between modules. Only then did modularization actually start paying off in speed and reliability.

[15:25]Matthew: Let’s get into monorepos. I hear they’re all the rage, but are there downsides?

[15:40]Samantha Lin: There are. Monorepos make code sharing and refactoring easier, but they can slow down builds and make tooling complex if you don’t set them up right. Plus, versioning and deployments get trickier as you grow.

[16:15]Matthew: What kind of tooling helps with those pain points?

[16:30]Samantha Lin: Tools like Nx, TurboRepo, or Yarn Workspaces help manage dependencies and speed up builds. But the real win is in automation—scripts to lint, test, and deploy only what changed, not the whole codebase.

[17:55]Matthew: Let’s jump to an example. Can you share a mini case study from your experience?

[18:15]Samantha Lin: Sure. We worked with a fintech team that modularized too aggressively—every tiny feature got its own module. It sounded neat, but they ended up with hundreds of tiny packages and spent more time managing dependencies than building features. We helped them merge modules by domain and things sped up.

[20:10]Matthew: So, moderation matters. Let’s talk about sharing business logic. How are modern teams making that work across mobile and web?

[20:25]Samantha Lin: The goal is to avoid duplicating your core business rules. Many teams now extract logic into shared packages—sometimes written in TypeScript—then import those packages into both React Native and web projects. You have to watch out for dependencies on browser or native APIs, but it pays off in consistency.

[21:05]Matthew: Is there a catch? What can go wrong with sharing code like that?

[21:18]Samantha Lin: Definitely. The main issue is hidden platform differences. Code that works perfectly on the web can fail on mobile, especially if you’re using native modules. That’s why clear boundaries and lots of tests are crucial.

[22:15]Matthew: Let’s switch gears: state management. It’s a heated topic. What’s changed in the last few years?

[22:30]Samantha Lin: Teams are moving beyond Redux for everything. Context API, Zustand, and other lightweight solutions are gaining traction, especially for local state. Redux still makes sense for complex, cross-cutting state, but you don’t need it everywhere.

[23:05]Matthew: Do you ever disagree with the trend away from Redux?

[23:15]Samantha Lin: Sometimes. If your app has a ton of shared state, Redux’s predictability and tools can be a lifesaver. But for smaller apps or modules, Context or Zustand is simpler and easier to reason about. It’s not one-size-fits-all.

[24:00]Matthew: So, the advice is: pick the right tool for the job. Let’s talk performance. What are the biggest mistakes teams make with bundle size or startup time?

[24:15]Samantha Lin: One common mistake is importing huge libraries for one tiny feature, bloating your bundle. Another is not code-splitting—so users pay the cost of loading everything up front. Lazy loading and dynamic imports can help a lot with both.

[24:45]Matthew: How do you measure performance in production, not just on your own device?

[25:00]Samantha Lin: We use real user metrics—tools like Sentry or Firebase to track startup times, crashes, and slow renders. That feedback loop is critical; otherwise, you’re just guessing.

[25:45]Matthew: Handling platform-specific code is always tricky. What’s your approach?

[26:00]Samantha Lin: We keep platform-specific code isolated. Use file naming conventions—like .ios.js or .android.js—so it’s clear what’s what. Avoid scattering platform checks everywhere; that gets messy fast.

[26:35]Matthew: Quickly: what’s the worst you’ve seen with messy platform code?

[26:45]Samantha Lin: I once saw a single file with dozens of Platform.OS checks mixed in. It was impossible to debug, and a change for Android accidentally broke iOS. It took days to untangle.

[27:30]Matthew: Let’s recap. We’ve covered why architecture is in flux, the move to modularization, trade-offs of monorepos, sharing business logic, state management choices, and performance pitfalls. Next up: how to test all this complexity. Stay with us.

[27:30]Matthew: Alright, let’s pick up where we left off. We’ve talked foundational patterns, component architecture, and touched on performance optimization. Now, I want to go a bit deeper into some of the architectural decisions teams are making nowadays with React Native. So, what are you seeing as the modern best practices for structuring large-scale React Native apps?

[27:46]Samantha Lin: Great question. Lately, what I’m seeing more and more is teams leaning towards modular, feature-driven architectures. Instead of lumping code by technical type—like all reducers in one folder, all screens in another—they’re grouping everything by feature. So, authentication is its own domain, complete with screens, hooks, state, API logic, and tests. It’s much like the ducks pattern, but adapted for cross-platform React Native.

[28:16]Matthew: That makes sense. I imagine that helps with scaling teams too, since people can own features end-to-end.

[28:30]Samantha Lin: Exactly. It’s easier for teams to work in parallel, and it reduces merge conflicts. Plus, it’s much clearer when onboarding new devs where to look for a certain piece of logic.

[28:42]Matthew: Can you share an example of how this played out in a recent project you worked on?

[28:55]Samantha Lin: Absolutely. I was working with a fintech startup. Their app started small, but as they grew, they kept everything in global folders. Eventually, onboarding new engineers took days just to understand the folder layout. We refactored to a domain-driven structure. Each feature—like payments, cards, user profiles—became its own module, with clear boundaries and even some shared utilities. It cut onboarding time in half and improved code reviews overnight.

[29:29]Matthew: Love that. And I guess it also helps with things like code splitting and lazy loading?

[29:41]Samantha Lin: Yes, exactly. With features isolated, you can start selectively loading what you need. This is especially helpful for bigger apps where initial bundle size can become a real issue.

[29:56]Matthew: Speaking of performance, let’s talk about that dreaded word: re-renders. What are some effective ways teams are managing renders and state today?

[30:13]Samantha Lin: There’s a lot of nuance here. The trend is towards more localized state—using hooks like useState and useReducer at the component or feature level, and only escalating to global state when absolutely necessary. And memoization is big. Tools like React.memo, useMemo, and useCallback are everywhere, but the key is using them judiciously—over-memoization can backfire.

[30:37]Matthew: Yeah, I’ve seen folks go wild with memoization and end up making things worse. Any quick test you use to decide when it’s worth it?

[30:52]Samantha Lin: If a component is heavy and receives props that rarely change, memoize. But for lightweight elements, don’t bother. Also, always profile first. Real-world profiling has saved us from premature optimization more times than I can count.

[31:11]Matthew: That’s a great point. Now, I want to shift gears to another hot topic: navigation. React Navigation versus native navigation solutions—what are you seeing in production apps?

[31:27]Samantha Lin: React Navigation is still the default for most teams because it’s flexible and fits most use-cases. But for apps with a heavy native feel or complex navigation stacks, teams are reaching for native solutions or hybrid approaches. One interesting trend is using React Native Screens under the hood to improve performance, even when sticking with React Navigation.

[31:52]Matthew: What are the trade-offs there?

[32:06]Samantha Lin: Native navigation can give you better performance and smoother transitions, but it comes at the cost of more complexity, especially if your team isn’t comfortable with native code. Plus, it might slow down iteration speed if your team’s main strength is JavaScript.

[32:26]Matthew: That’s a good segue into another trend: integrating native modules. Are you seeing more teams bridging to native for performance-critical features?

[32:40]Samantha Lin: Absolutely. For things like video rendering, complex animations, or Bluetooth, pure JavaScript solutions just don’t cut it. What’s new is that the tooling and documentation for bridging have improved a lot. Libraries like react-native-reanimated and react-native-gesture-handler let you write performant animations without dropping to native as often.

[33:07]Matthew: Have you seen any pitfalls when bridging custom native modules?

[33:20]Samantha Lin: Definitely. One mistake is ignoring memory management or not handling async callbacks correctly, which can lead to app crashes you won’t see until production. Another is failing to account for differences between iOS and Android APIs, which leads to subtle bugs.

[33:38]Matthew: Yeah, that can be painful. Let’s bring in another mini case study. Do you have an example of a team that got tripped up here?

[33:52]Samantha Lin: For sure. There was an e-commerce team that built a custom barcode scanner module. It worked flawlessly on iOS, but on Android, it had a memory leak that only appeared after scanning dozens of items. Months went by before they realized native resources weren’t being released properly. It took a deep dive with Android Studio’s profiler to finally squash it.

[34:21]Matthew: Ouch. That’s a real-world example of why robust testing—including stress testing—is crucial.

[34:31]Samantha Lin: Exactly. And it’s a reminder to always test on both platforms, under as many real-world conditions as possible.

[34:43]Matthew: Alright, let's switch to rapid-fire questions! Just say the first thing that comes to mind. Ready?

[34:46]Samantha Lin: Let’s do it.

[34:49]Matthew: Best state management approach for most teams?

[34:51]Samantha Lin: Start with React context and hooks. Graduate to something like Zustand or Redux Toolkit if you need more.

[34:56]Matthew: Favorite navigation library?

[34:58]Samantha Lin: React Navigation for flexibility, but native stack for performance-sensitive flows.

[35:02]Matthew: TypeScript or JavaScript?

[35:04]Samantha Lin: TypeScript—hands down. Saves so much time on large teams.

[35:07]Matthew: Expo or bare React Native?

[35:10]Samantha Lin: Expo for prototypes and MVPs. Bare for anything custom or at scale.

[35:14]Matthew: Testing: unit, integration, or E2E?

[35:16]Samantha Lin: All of the above! But if you have to pick, integration tests catch the most real-world issues.

[35:21]Matthew: Preferred animation library?

[35:23]Samantha Lin: react-native-reanimated for anything non-trivial.

[35:27]Matthew: Favorite dev tool for debugging?

[35:30]Samantha Lin: React Native Debugger and Flipper together. Can’t beat that combo.

[35:36]Matthew: Awesome. Thanks for playing! Let’s zoom out a bit. What about code sharing between web and mobile? How practical is it today?

[35:50]Samantha Lin: It’s more feasible than ever. Libraries like React Native Web have matured a lot. You can share up to 90% of your business logic and even some UI components, as long as you’re disciplined about separating platform-specific code.

[36:10]Matthew: What’s the catch? Where does it break down?

[36:23]Samantha Lin: Navigation and animations are the big ones. Web and mobile have different paradigms—so you’ll almost always need custom code for those. Also, you’ll hit platform-specific styling quirks. But for things like form logic, API calls, and business rules, sharing is smooth.

[36:44]Matthew: What about monorepos? Are you seeing teams go that route, or is it overkill?

[36:56]Samantha Lin: Monorepos are on the rise, especially for companies maintaining multiple apps or packages. Tools like Nx and TurboRepo have made it easier to manage dependencies and shared code. The main risk is overcomplicating your setup too early. If you have just one app, a monorepo might be unnecessary overhead.

[37:21]Matthew: Let’s talk about deployment. Fastlane, EAS, CodePush—what’s your go-to deployment strategy these days?

[37:35]Samantha Lin: For managed workflows, EAS is hard to beat. It simplifies builds, signing, and over-the-air updates. But for custom native code, Fastlane is still the gold standard. And yes, CodePush is still relevant for pushing JS updates, but always remember app store rules and don’t overuse it.

[37:56]Matthew: Any horror stories from overusing CodePush?

[38:07]Samantha Lin: I know a team that shipped a broken update on a Friday via CodePush. They fixed it within hours, but a chunk of users was stuck in a bad state because of caching. Lesson: test updates thoroughly, and never push on a Friday!

[38:29]Matthew: Classic. Let’s circle back to testing. What are the must-haves in a React Native CI pipeline today?

[38:42]Samantha Lin: Linting and TypeScript checks are non-negotiable. Then unit and integration tests. For bigger teams, snapshot tests for UI regressions. And if you’re serious about quality, add E2E tests with Detox or Maestro. Plus, automate deployments to staging so QA sees every build.

[39:05]Matthew: How do you keep CI times under control as the codebase grows?

[39:16]Samantha Lin: Parallelize jobs, run tests in shards, and cache dependencies aggressively. Also, don’t run heavy E2E suites on every PR—schedule them nightly or on merges to main.

[39:34]Matthew: Let’s touch on error monitoring. What are teams using today to catch crashes and errors in production?

[39:46]Samantha Lin: Sentry is the go-to. It offers real-time error tracking, stack traces, and even context on user actions. Bugsnag and Firebase Crashlytics are also popular. The key is setting up source maps correctly so you actually get readable errors.

[40:04]Matthew: Very true. Now, a curveball: with all these improvements, what’s still hard about architecting React Native apps?

[40:17]Samantha Lin: The hardest part is maintaining performance and consistency across devices and OS versions. Fragmentation is real—there are hundreds of device combinations. Also, keeping up with dependency updates and deprecations can be a headache.

[40:39]Matthew: Have you seen any strategies work well to tackle device fragmentation?

[40:51]Samantha Lin: Automated device farms help. Services like BrowserStack or Firebase Test Lab let you run tests on real devices. But nothing beats having a set of physical devices for hands-on testing, especially for tricky UI bugs.

[41:10]Matthew: Let’s bring in our second mini case study. Can you share a story of how a team handled fragmentation in production?

[41:23]Samantha Lin: Sure. There was a health tech company whose users skewed older Android devices. Their calendar UI looked fine on emulators, but on some real phones, dates overlapped and buttons disappeared. They invested in a small device lab and set up weekly manual regression testing on those devices. It caught issues before users did and made a huge difference in user satisfaction.

[41:55]Matthew: That's a great tip. Alright, let's talk about trends in UI patterns. What’s modern in React Native design systems and theming?

[42:11]Samantha Lin: Component libraries are more mature now—things like React Native Paper, Tamagui, and NativeBase. More teams are adopting custom design tokens for theme management and supporting light/dark mode out of the box. And there’s a move toward using TypeScript for prop validation and IntelliSense, which reduces runtime bugs.

[42:35]Matthew: Any advice on rolling your own design system versus using a library?

[42:49]Samantha Lin: If your brand requires a unique look, rolling your own is worth it, but start with a library to accelerate development. You can always incrementally customize as you go. Just don’t underestimate the effort—maintaining a design system is almost a full-time job.

[43:11]Matthew: Let’s get hands-on: what’s your checklist for implementing a robust architecture in a React Native project today?

[43:23]Samantha Lin: Great, let’s do a quick bullet rundown. First, define your folder structure—preferably feature-based. Second, choose your state management—start simple, scale as needed. Third, set up navigation, pick between React Navigation and native stack. Fourth, implement type safety with TypeScript. Fifth, integrate robust testing—unit, integration, and E2E if possible. Sixth, automate with CI/CD. Seventh, set up error monitoring and analytics. And finally, document everything for the team.

[44:00]Matthew: That’s a solid list. I’ll add: don’t forget regular code reviews and cross-platform device testing!

[44:11]Samantha Lin: Absolutely. Peer reviews and manual testing on both iOS and Android devices save so much pain down the road.

[44:25]Matthew: As we head toward the end, I want to ask: how do you see React Native fitting into the broader cross-platform landscape now?

[44:40]Samantha Lin: React Native has carved out a sweet spot—fast prototyping, great developer experience, and solid performance for most use-cases. It’s not right for every app—if you need full access to device APIs or ultra-high performance, go native. But for most business apps, it hits the balance between speed, quality, and cost.

[45:05]Matthew: And what about learning curve? Is it easier for web developers to get into React Native than native mobile devs?

[45:18]Samantha Lin: For sure. If you know React, you’re halfway there. The trickiest part is learning mobile paradigms—navigation, gestures, and the app lifecycle. But the JavaScript core makes onboarding smoother for web folks.

[45:39]Matthew: Let’s talk mistakes. What’s the most common architectural mistake you see teams make in React Native?

[45:52]Samantha Lin: Trying to predict every future requirement and over-engineering from the start. It slows teams down and makes onboarding painful. Instead, start simple, refactor as you scale, and adopt proven patterns incrementally.

[46:15]Matthew: Is there a time when you do recommend upfront heavy planning?

[46:27]Samantha Lin: If you know you’ll have multiple teams or plan to open source your app, then it’s worth spending time upfront on conventions and documentation. But for most startups, speed trumps perfection early on.

[46:47]Matthew: I want to squeeze in one more audience question. Someone asks: what’s the best way to handle feature flags in React Native?

[47:00]Samantha Lin: Great question. Services like LaunchDarkly and Firebase Remote Config work really well. But for smaller teams, even a custom solution—using a config file fetched at launch—can work. Key thing is to avoid deeply coupling features so you can turn them on and off independently.

[47:24]Matthew: What about analytics? Are there any pitfalls React Native teams fall into?

[47:38]Samantha Lin: Not standardizing event names and parameters is a big one. You want to define a clear analytics schema early and automate as much as possible. Also, always test events on real devices before shipping—they sometimes silently fail on certain platforms.

[48:02]Matthew: Before we wrap, let’s each share a final tip for teams getting started with modern React Native architecture.

[48:13]Samantha Lin: Mine would be: don’t be afraid to leverage open source. There’s a huge community, and most problems you’ll face already have good solutions or libraries.

[48:30]Matthew: Love that. I’ll add: invest early in a solid design system and consistent code formatting—it pays off fast.

[48:39]Samantha Lin: Couldn’t agree more.

[48:44]Matthew: Alright, time for an implementation checklist. I’ll read out the steps, and you can chime in with details.

[48:51]Matthew: Step one: Set up your project with TypeScript and a clear, feature-based folder structure.

[49:00]Samantha Lin: Yes, and make sure to include Prettier and ESLint from day one.

[49:08]Matthew: Step two: Choose state management—start with Context, scale up as needed.

[49:15]Samantha Lin: And don’t overcomplicate—avoid global state until you really need it.

[49:22]Matthew: Step three: Implement navigation, keeping performance and user experience in mind.

[49:30]Samantha Lin: Profile navigation stacks early, and avoid deep nesting when possible.

[49:36]Matthew: Step four: Integrate testing—unit, integration, and E2E.

[49:44]Samantha Lin: Automate as much as possible, and don’t forget snapshot tests for UI changes.

[49:51]Matthew: Step five: Set up CI/CD for builds, tests, and deployments.

[49:57]Samantha Lin: Yes, and make sure staging builds go to QA automatically.

[50:04]Matthew: Step six: Add error monitoring and analytics, with source maps configured.

[50:10]Samantha Lin: Test tracking on real devices—don’t just trust the dashboard!

[50:16]Matthew: Step seven: Prioritize documentation and code reviews.

[50:22]Samantha Lin: Documentation is your future self’s best friend. And peer reviews catch subtle bugs.

[50:30]Matthew: Perfect. Thanks for running through that. As we wrap up, any predictions for future trends in React Native architecture?

[50:43]Samantha Lin: I think we’ll see even tighter integration with native code, and more tools for code sharing across platforms. Also, design systems will become more automated, maybe even design-to-code pipelines.

[51:00]Matthew: Exciting times ahead. Any final words of wisdom for our listeners?

[51:12]Samantha Lin: Keep learning and don’t be afraid to refactor. The ecosystem moves fast, but the fundamentals—clean architecture, good testing, and clear documentation—never go out of style.

[51:27]Matthew: Couldn’t have said it better. Alright, before we sign off, let’s do a quick recap checklist for listeners:

[51:33]Matthew: 1. Favor feature-based folder structures.

[51:37]Matthew: 2. Start simple with state, scale up if needed.

[51:41]Matthew: 3. Use TypeScript for safety and maintainability.

[51:45]Matthew: 4. Choose navigation wisely—balance flexibility and performance.

[51:49]Matthew: 5. Prioritize testing at all levels.

[51:53]Matthew: 6. Automate CI/CD and error tracking.

[51:57]Matthew: 7. Invest in documentation and code reviews.

[52:01]Matthew: 8. Test on real devices—don’t just trust simulators.

[52:07]Samantha Lin: Exactly. And remember, architecture is a journey—don’t be afraid to evolve as your app grows.

[52:17]Matthew: Thank you so much for joining us and sharing such actionable insights. Where can people find you if they want to connect or learn more?

[52:26]Samantha Lin: I’m always happy to connect on LinkedIn or GitHub. Just search my name, and you’ll find me. I also post occasional deep dives on my blog.

[52:39]Matthew: Awesome. And thanks to everyone listening. If you enjoyed this episode, please subscribe and leave us a review—it really helps.

[52:47]Samantha Lin: Thanks for having me. This was a lot of fun!

[52:55]Matthew: Alright, that wraps up today’s conversation on React Native architecture and trends. For more episodes, check out our site at Softaims, and follow us for updates.

[53:10]Matthew: Until next time, keep coding, keep learning, and we’ll see you in the next episode.

[53:16]Samantha Lin: Take care, everyone!

[53:22]Matthew: And that’s a wrap. Thanks for listening to Softaims. Have a great week!

[55:00]Matthew: Episode complete at 55:00.