Here you go: the years of hard work, sleepless nights and chasing after clients finally allowed your product to grow. You’ve got some big whales who want you. You’ve got requests for amazing projects. You expand your operational team to process more orders and delegate more and more work. But all a sudden, you realize that you’re getting bottlenecked from a place you never expected…

...your software.

Your web or mobile application starts to hang in the places where it never did it earlier days, and your clients complain about that. Your tech team of two or three hardworking developers simply gets stuck on how to even debug the newly appearing performance and functional issues. Your backlog gets longer every day. Your most tech savvy person who only actually knew how to do everything gets hunted by a giant corporation. And you suddenly realize that you have no real documentation or a formal knowledge transfer process. Your infrastructure costs grow without any visible reason. Finally, you find out that you could have grown twice over the last few months, but you can’t. Because you are simply not getting anything done, being capped by this app, or blog, or CRM system…

Sounds familiar?

On the new peak

Many early stage IT products are getting made fast and to the point of working, even when they end up having very advanced functionality. They have to solve specific tasks at the critical initial period of business “at least somehow”, to get the work done and stay in the game. Fast and sudden growth often can be disastrous for such products. There are very good reasons for that, you bring in people who can make it fast, because you know that’s what actually matters at the beginning. But even a good team, having to act fast, never really gets to think about project architecture, testability and scalability. They can't provide sophisticated monitoring and security. There is no reliable deployment flow. No wonder: these things may take months of work by a senior team, oftentimes headed by an experienced architect and engineering manager. Even if you can afford such a team from a financial standpoint, you cannot afford the time needed for that process when you’re at the start. Apart from that, your product evolves so fast that no development plan or architecture can cover that. There is no room to think about outer space when you just need to address the needs of two major paying clients. You and your tech squad barely get to fulfill their flow of incoming requirements. And that’s a natural and reasonable pathway for every young technical project.

Better late than never - as far as it's not too early

Yet, what was impossible and unfeasible to do at start, should be done now when you experience significant growth. An essential process of giving your software proper architecture is now a cornerstone for your business to approach new heights. It becomes critical for you to get together with your tech partner and re-evaluate your product from the get go and properly address its bottlenecks.

No matter how complicated this process could be, it boils down to answering simple questions:

• Is the way the project has been built adequate enough for a growth momentum the business is gaining?
• What would it take to set and maintain the quality and security bar? And how much of a margin does that leave to keep up to speed with new product features?
• Finally, is your tech team mature and open minded enough to go this way? Or should it be reinforced by another senior member or two, at least for the time being?

When you get the answers to those questions right, you get able to understand where you actually are at. The rest is just a matter of experience, time and your and your tech partner’s joint work. But what if the answers you get are not so pretty?

Not this again...

Sometimes it may appear that the project was not built adequately enough at all. Luckily, there is n+1 way of improving an existing project without rewriting it. It may be just a touch of superficial refactoring, update of the dependencies, partial rebuild of the architecture and occasional modular rewritings here and there.

More often it’s actually simpler than that: the software hits some particular bottlenecks, but some of the software modules have been built in a way where these bottlenecks are very hard to fix and even identify. In this case, the action items include concrete steps to solve that, and prevent such incidents in future. The latter is mostly about proper monitoring capabilities.

A very common problem is a piece of software that suffers from numerous issues all the time during the development. Bug fixing becomes business as usual. On one hand, that may scream about bad design. But more importantly, it often means that the project is lacking good automated testing and reliable deployment flow. Correspondingly, that might be the main area to look into.