Luka Leskovsek
VP of Engineering @d.labs
Starting a business is not for the faint of heart. Navigating through different growth stages and adapting to keep functioning is essential, but many startups struggle with this process and ultimately fail.
One of the critical aspects of this process is designing an effective technical architecture. When starting from scratch, it's paramount to design a technical architecture that aligns with the company's goals and needs, but let's face it, it's not always a walk in the park. Engineers often fall into the trap of focusing on big up-front technical architecture and inadvertently introduce unnecessary complexity into the project.
But wait, don't lose hope just yet! In this article, I'll walk you through the key principles for designing a technical architecture that will significantly increase your chances of success.
One strategy that can be a game-changer is Just in Time Software Architecture, or JITA for short. JITA is all about designing software systems that are agile, flexible, and ready for market changes. It's a way to allow the business to adjust quickly and easily, adding features to their existing system as market needs change, without starting from scratch.
In other words, engineers only implement the architectural work that is necessary and important at that point in time. We avoid any significant upfront investment into architecture.
When creating the technical architecture of a digital product, it's crucial to keep in mind the business objectives and the needs and goals of all stakeholders. The engineer should work hand in hand with the business and all stakeholders to identify the current requirements of the product and make sure that the architecture is designed to support those needs. For instance, let's say you're planning to offer a freemium or a trial package. In that case, the technical choice must reflect this. A potential mismatch between the business and tech could break the bank, burning too much cash with freemium/trial users for the infrastructure and different vendors.
Engineers need to map out the technical vision - their North Star Architecture. The technical vision should act as a compass throughout the development process, assisting in keeping the architecture on target. It's vital to regularly review and update the technical architecture vision to ensure that it stays current and in line with the product's and the business's overall goals. Even though you should start lean and focus on the present, it's crucial to plan ahead and analyze different technical architecture options and vendors before you need them.
One effective way to understand the concept of Just-In-Time Architecture (JITA) is by considering how it can be applied to a startup at different stages of growth. By examining the challenges and opportunities a startup may face as it evolves, we can gain insight into how JITA can help a company adapt and thrive in a constantly changing business landscape.
To determine the validity of your hypothesis, it is essential to quickly generate and test a range of ideas with potential customers, user groups, and trusted individuals in your network. This process allows you to gather sufficient evidence to secure funding for the next growth phase. The focus of this effort is to validate the idea and ensure its viability.
While this phase can be done without any working software, it is usually accompanied by a proof-of-concept (POC) or an early-stage MVP version of the product.
The software architecture must be flexible and adapt to changing requirements at this stage. To achieve this, it is advisable to utilize a range of Software-as-a-Service (SaaS) services and No/Low-Code tools, which can keep the architecture simple and streamlined.
For example, suppose you are trying to validate a marketplace idea. In that case, a good start is to use Sharetribe and quickly iterate to validate your idea and get satisfactory confirmation of a potential PMF (product-market-fit). If you require a simple mobile application, you can use FlutterFlow (mobile app builder) and Firebase (backend) to quickly develop your POC/MVP. While someone with no technical background could use those tools to get the most out of them, it is advised that an experienced developer works with them.
Having a simple architecture at this stage is essential. This stage’s output, whether a proof-of-concept (POC) or minimum viable product (MVP), is typically temporary and not meant to be used long-term. As the company progresses to the next stage, it will require a more robust and scalable architecture to support its growing needs.
The growth stage is a crucial phase in a startup's development, as it is the point at which the company starts to scale and expand its operations. During this stage, the startup has a functional product and a small customer base, focusing on growing these areas.
The growth stage is a busy and exciting time for a startup as it works to scale its operations and continue developing as a company. The startup needs to focus on growth while also maintaining a strong foundation and solid business model to sustain its success over the long term.
Before making any architectural changes, we must evaluate the existing product and the architecture to identify the broken/less-performant parts. We look for the characteristics of the system and product that are causing issues for the business and, more importantly, causing frustrations for the clients.
This brings us to the early POC/MVP you built in the discovery stage. You need to ask yourself which parts of the system are causing the business the most pain? Do you have challenging customer acquisition times, or is the retention rate not improving?Once you identify the area you need to work on and improve — it is time to identify the root issue and replace it with a more suitable solution.
For example, let's say that your product's customer payment check-out flow is not optimal and is causing problems. According to your data, this is resulting in a significant number of customers abandoning the final payment step. This issue is likely generating frustration and inconvenience for customers and lost revenue for the company. It is essential to address this problem as soon as possible to improve the customer experience and maintain the health and success of the business.
Thinking in the JITA mindset, we now know we need to remove this piece of the system and replace it with a more suitable alternative. One of the essential key elements is that you are not replacing/optimizing anything else in the system. The rest of the system must continue running on the initial architecture and codebase, even if aspects need improvement. While it may be tempting to completely rewrite the whole system to address all issues simultaneously, this can be time-consuming and resource-intensive. By focusing on targeted changes and using an approach like JITA (Just-In-Time Architecture), we can stay agile, lean, and responsive to the needs of the company and its customers.
In the coming months, the engineering team will need to slowly replace the remaining parts of the system and transition them to a new architecture. This deliberate process requires support and understanding of the entire business. It's important to carefully plan and execute this transition to minimize disruptions and ensure a smooth transition to the updated system.
The next phase is heavier on engineering, as it usually means that the business has entered the (maybe even hyper) scaling/expansion stage.
During the scaling or expansion phase, a startup is focused on growing operations and expanding its reach. Some weaknesses/problems in the existing system/product/architecture have likely become apparent. It's important to identify and address these issues to maintain a high level of service quality and keep the business running smoothly.
To tackle these issues, it's essential to follow the same steps as before: identify the system's riskiest and most problematic areas and think about what needs to be designed and built to support the company during this phase. The troublesome areas at this stage usually include inadequate vendor choices and the pressure it’s placing on the business. Compliance requirements as a result of entering new markets. Not scalable architecture is potentially caused because the company's growth was too rapid, and the tech couldn’t keep up with it (e.g., just continued building on a disposable POC or an early MVP without rethinking if the approach makes sense). Broken user journeys (e.g., customer payment flow, signup) codebases are sub-optimal and cause delays when delivering changes.
Another essential aspect to consider is vendors and their pricing. It's important to keep in mind the projected growth of the company and its business model (B2C, B2B, B2B2C, Freemium, …).
Overall, this phase is the crucial time for a startup and requires careful planning and attention to these critical areas to ensure success. As the company grows and attracts more attention, compliance becomes increasingly important. This includes adhering to regulations that depend on the markets you are active in (GDPR, CCPA, APA, HIPAA regulations, or SOC2, ISO certifications). Additionally, security becomes a more significant concern as more people look at your product. It's important to consider how user authentication and personal data are handled, among other security considerations.
JITA is not something you do just once, as the business constantly evolves and grows. JITA is a mindset. The existing department's scale as we hire new people, acquire new customers and tap into new markets. The software architecture must continuously adapt to serve the customers and work for the business.
It is a balancing act, and you will not get it right on the first try. This is why a constant iterative approach to digital product development is crucial. The moment when the company starts to notice that parts of the product are causing problems, it is time to start adapting the software architecture.
Remember, JITA is a mindset. It is a way to constantly think about how the architecture of your product is serving the business. The engineering team needs to understand the company's direction, customers' feedback, and the market's reality. It must be a regular discussion with different stakeholders.
The engineering team uses all this information to ensure that your architecture is always optimal.
Does your company require help designing software systems that work? Drop us a line at sales@dlabs.io.
.png)
