Startups, Pivots, and the Strangler Fig Pattern - June 2026

Recently at work, we've had to deal with a business pivot, yet, again. I wasn't happy to hear this after carefully planning the first version of the app, but my intuition told me it was going to happen, which is why I worked to keep the system's architecture flexible. Let me introduce you to the core problem, how I've been solving it, and how you could prevent similar things from happening in the future.

1. The business change

The first prototype (V1) - January and May 2026

In V1, we were working with separate locations (tenants) in our app. It was a traditional multi-tenant architecture in a granular way, as the requirements of January 2026 suggested. My CEO's words:

• Location is the primary unit of experience.

• Pricing is per location.

• Users interact in a location.

• Posts and chats are never shared across locations.

• Brands are labels only; locations are the product.

• Do NOT merge locations into one shared feed."

The pivot (V2) on May - June 2026

Weeks after launch, on May 29, I received a suggestion from my CEO. "Fran, we've noticed the current business model won't scale, and the logistics are hard to manage. Let's merge the related tenants to brands and create a global app per brand". My mistake? I pretty much married everything to the local tenant_id as shown below:

What I did not know was that each tenant needed to belong to a brand as well. Essentially allowing brands to be the main entity, not the location.

I ended up adapting to the change because the database schemas were flexible and I understood the codebase well. The reasoning behind this change is related to profit. We found out that brands can give the startup the most revenue, while individual locations were not profitable for us. We're working on migrating the core app architecture to work with brands.

2. The strangler fig pattern

The strangler fig pattern is a software architecture pattern where you create a new system alongside the old one, and eventually the new system deprecates the old one due to the new changes in the core functionality. With this migration, we've done the following:

• We focused on building the new admin features related to brands, as in a B2B app, you always need to maintain two types of systems: the customer-facing application and the administrative one (who creates the main system information, deals with reports, user management, and sees the metrics? Correct, the system administrators; now you know it).

• We've kept the core user authentication almost the same and only extended a few API endpoints to retrieve new fields or support brands without major changes in the core logic.

• For the new brand and social features, we've created a V2 of the API where the main logic relies on the brand, not on the location as we were doing before.

• We introduced graceful degradation strategies in the frontend, where users are now redirected to the brand page once they are migrated from a location to a brand, keeping a seamless UX/UI.

3. Don't add everything they ask you for at once

The team and I were asked to introduce the following as well:

1. Filters and being able to search users by brand

2. User location preferences Geolocation and extending existing locations

I added these features to the backlog as they were pure scope creep. The main goal right now for the team is to finish the business model change and ensure existing users can use the new, polished app.

Once we've shipped this new system and we've accomplished the given business goals, we can keep enhancing the existing foundation we built. You cannot build on broken foundations.

4. Continuing the migration

Besides the strategies I mentioned in the Strangler Fig pattern section, there are other strategies I'm going to apply.

• Add the brand_id to the social-related tables and make them nullable while we perform the migration process, and stop using location_id entirely in the new API to match the new business context.

• Migrate users from locations to brands using a membership table, where we also had the location_id. We migrate our users both in-app through endpoints like "/me" and using a startup script triggered by a feature flag.

• Don't make new columns non-nullable until the migration process is done, and don't remove the location_id yet until the new migration strategy works for 100% of users. We always need backwards compatibility in case of a disaster or a wrong business plan.

5. Lessons learned & conclusion

• Multi-tenancy is hard. You won't get it right at the first attempt, and even if you do so, you'll have to deal with RLS (Row Level Security) and complex RBAC permissions.

• Keep your schemas and architecture flexible in the initial startup stage. There will be pivots, and your code needs to adapt to the business, not the other way around.

• Learn how to learn from pivots and changes in business directions. You're getting paid to solve problems; some of them are interesting, others are not so fun, but you still have to find meaning during the process.

I've been improvising lately on the electric guitar, where you have to adapt your skills to others' music; the same happens with startups, adapt your skills to the business, not the other way around. Thanks for reading, I'll continue working on this challenge, and I hope you have learned something new :)