The last 10% trap, how to strangle your startup project?

If you care about innovation, fast time to market, quick response to consumer demands, then you should be worried about the last 10% trap. It is a problem commonly faced by founders adopting tools and frameworks for their startup projects.

It goes like this, you pick a tool or a framework to develop your software with, it is super easy to use, and you are making super fast progress. You have added many features in a short time and you shipped a version or two. You are at 50% in the total features delivered to your users.

A few weeks goes by, and users request new features, you go to your tool or framework, add these new features, but you notice you are struggling a little bit to implement them. You are at 80% features delivered to your users.

Again, a few weeks goes by, and your users demand more awesome features, this time you add these features but you applied some hacks and tricks to get things done, it was an uphill battle to get there but you made it anyway. You are at 90% features delivered to your users.

A few weeks later, and many users in, your product is now more popular, your users yet again ask for more advanced features, you want to keep the wheel of progress turning, and you try to find a way to implement these features but you are unable to do so. Applying hacks and tricks won’t do the thing this time, you reached the limits of the tool or framework, it is impossible to advance, you are now officially stuck in the last 10% trap.

Once you reach this ugly situation, only one option is left to do, throw away all this code or artifacts you invested time and money on, and do a total rewrite. Yes a total rewrite because there is no way to keep the momentum up, there is no way to keep innovating and delivering to your end users, you finally hit the wall.

The anatomy of this trap

To recap, the pattern for this trap is like this:

• 0% to 50% - You are making super fast progress.
• 50% to 80% - Things are slowing down but you are still delivering new features.
• 80% to 90% - It is hard to add new features, you are employing many tricks and hacks to get things done, and the result is awkward.
• Last 10% - Your project is stuck, no progress is possible. This is the dead end.

What this has to do with MVPs, Low-Code/No-Code?

There is a great lesson to be learned for this trap: Use a tool for it’s target use case and don’t expect it to do everything for you. Prepare yourself to eject or pivot fro that tool as soon as you have reached its usefulness limit.

In case of MVPs and Low-Code/No-Code, prepare yourself to move to a Custom-Code solution as soon as you have validated your idea, have some traction, or have the funding necessary to invest in a more robust and long term solution.

Manifestations of this trap

These are situations where you might find yourself in this trap:

• You use a UI prototyping tool but you need to collect some forms, so you move to Low-Code/No-Code.
• You used a Low-Code/No-Code tool but it doesn’t scale to implement key features, so you move to Custom-Code.
• You use a framework, but it turns out that this framework is only good to build MVC (Model View Controller) pattern solutions, it is not good to build APIs, so you move to a general purpose framework.
• You use an interpreted language which is slow for your scaling needs, so you decide to pick another compiled language to address this issue. A famous instance of this is when engineers at Twitter decided to migrate from Ruby to Scala and Java.

How to avoid this trap?

These are some tips on how to avoid this trap:

• Know the limitations of your tool or framework before investing time on it.
• Bailout as soon as you have reached your goal with the tool, don’t push it to it’s limit.
• Design an initial architecture for your product, this should give you some guidelines on what tools or frameworks to use, and more importantly a plan of when to switch to a different long term solution.

Last word

The main lesson learned is, there is no silver bullet in software development. Tools and frameworks are good only for the target use cases they are developed or designed for, once you stray away from these perfect use cases you will face the hard truth and limitations of this choice.

There is a saying that “If the only tool you have is a hammer, you tend to see every problem as a nail”, and this is the main reason many adopters of tools and frameworks get caught in the last 10% trap. They are blinded by their initial choice and will think that any solution to implement a new feature is within the narrow capabilities of that tool or framework.

In a sense, they are not thinking outside the box, even though they are free to pick the best tool for the job and mix and match different tools to get things done.

I have seen many projects use a framework far more than what it was designed to handle, and end up with a failure to innovate, a slow time to market, and a sky rocketing cost to maintain their product, all this because of poor choices from the get go, and a lack of vision or architecture design to see where and how this product will evolve.