Scaling from a low-code MVP

Following a successful investment, a startup founder, who initially developed their MVP using a low-code/no-code platform, has outlined a plan they have to rebuild it in-house.

While functional, the current solution (already on the market in 11 countries) presents an exciting opportunity for growth but requires an unsustainable amount of manual labor to keep the product working.

So they are hiring the first in-house technical hire (tech lead) to build the tech team, set up the foundation, architecture, and strategy, and work on it hands-on.

I won’t deconstruct that job description today; I want to focus on what it means to transition to building software from the ground up (including the team).

Here’s the thing …

Building it custom is not just a tech upgrade; it’s a strategic move.

You’ll need to choose a sound technical foundation.

You’ll need to plan how to build and grow the team.

You’ll need to identify which parts of the existing MVP to custom-build first so that they start generating value as soon as possible.

It’s a significant investment in time, effort, and money, so the upside of the change needs to be massive.

Here’s the plan …

Use a hybrid approach; start by building out the part of the system that solves a concrete problem and has a clear benefit.

Get to production fast with it. Start the learning loop.

Iterate and expand, custom-building more of the overall system.

Define goals in terms of outcomes, not features.

Here are a few pitfalls to avoid.

**Overengineering **Don’t replace parts that don’t need to be replaced, and use boring technology.

**Isolation **Keep the tech team from building in isolation. Quick deployments. Cross-functional teams. User-centric.

**Unrealistic expectations **Be honest about timelines and outcomes. It will be more expensive and take longer than you think, especially if you have a side project of building an amazing engineering team from zero while rebuilding the product.

**Neglecting the cultural shift **This will impact all other departments and how they function. The company will need to adapt. Plan for it.

One final thing …

Mistakes at the start of such a project can be costly because many decisions that need to be made are non-reversible or hard to reverse.

Once you build a few services in Java, you cannot switch to Go if that proves to be a better choice for the type of project you’re building.

Be careful about going in without a plan, but don’t only depend on a plan. As you go on, knowledge increases. Lean on principles and stay flexible.

Best regards, Taj