Moving from prototype to scale
There is an old adage in technology that prototype code always ends up in production. What might have started out as a nice proof-of-concept, eventually ends up serving real customers and accumulating technical debt. There are many reasons for this but the end result is that this code was rarely designed to scale, be secure, or be extensible. This code becomes the IT skeleton-in-the-closet, joked about and even used to shame.
While it is necessary to get to market quickly, often company leadership doesn’t always ensure the technology platform is what is actually necessary for customers and the company. Seems obvious, but because of the urgent need to start generating revenue, features are often added to the prototype code. Sometimes the company doesn’t realize that they are building on quicksand until much later – which of course makes it a more expensive and difficult problem to resolve.
Even worse, the prototype technology might have been created by the founders or purchased as part of a merger. This can lead to a reluctance to admit that the technology isn’t as good enough. What was a prototype years ago is suddenly an unsupported or insecure albatross hanging over the company.
At 4DA we built a prototype stack consisting of a Spring Boot API backend and a Flutter mobile app. Using this prototype we were able to demonstrate our idea, and generate interest in our Scriptio product. Using the technology we were comfortable with or able to hire out to contractors, we used that rather than slides or a pitch deck because the concept can be difficult to explain with just words.
What is scale?
A major benefit to our approach is that our API and app could adjust to requests. Because what we are doing has never been done, we had made quite a few assumptions. A prototype helped us to evaluate those assumptions and the design evolved with customer questions and expectations. These evolutions helped the technology team understand what features and functionality were needed. Features like HIPAA could be ignored in a prototype, but it helped define how to address it in a production platform.
When we started to build out the new platform, what we will call 1.0, we evaluated the prototype technology and offset it with what we thought the scale would be. It is very difficult to find the balance between ultimate scale and affordability. It is very temping to apply the latest design patterns and buzzwords and incur massive hosting fees. For example, should a platform start with a messaging bus, or be built in a way that it can be added if deemed necessary? What about AWS vs Azure vs GCP – which one will provide the functionality and cost you can be affordable AND productive?
Calculating scale is comparable to Total Addressable Market – very difficult to determine how many people are in your market and will use your services. If you calculate this wrong, you could end up with a dozen services running dozens of instances when really all you need is a single application (aka monolith). But if you underestimate, and the product takes off you could have serious architecture liabilities that are catastrophic to your customers – nobody in health care wants to have their data unavailable.