Finding a product-market fit is a top priority for startups. The faster you iterate on the product by listening to customers' feedback and requests, the fewer resources you will waste on the delivery of features they won’t use. But when you already know what your customers' pain is, make sure your product is scalable enough to keep offering the same high-quality service when it starts to grow.
At Techstack, we have vast experience growing digital products and a community of 170+ technology professionals with narrow-purpose expertise that can accelerate product growth.
- We have slowed down client attrition and helped grow the platforms’ client bases, leading to product acquisition by one of the leading industry players.
- We have reduced response time and improved system reliability of our partners' products through implementing a serverless architecture and tripled their growth speed.
- We brought an IoT hardware kit and software product having zero experience and a small team to product release and 15+ team members within one year.
We asked our technology experts to describe typical challenges they faced building products that are about to grow extensively and the strategy to overcome them.
Architecture Doesn’t Scale
VP of Engineering
Startups often begin with an easy-to-launch architecture and forget to make sure it can scale in the future. It’s absolutely fine if you want to launch your product fast and find out if the product is viable. Whatever business incentive your decision had, someday you will need to ensure that it can scale.
Each product needs a custom solution for this challenge. I recommend starting with as-is and to-be state analysis. Further, you will be able to implement a new architecture or extend the current one based on the product specifics. A timely and consistent transition from one architecture to the other (for example, from monolith to microservices) may help.
Architecture Scale (Techstack case)
We worked on a product that was built in monolithic architecture and passed through the investment round. However, when the audience and features started to grow, the architecture became a bottleneck for growth. We developed a gradual transition to microservices, which enabled us to triple the growth speed. Why hadn’t the initial product team implemented a microservices architecture from the very beginning? It was cumbersome and not cost-effective for the first development stages. The optimized approach including a transition to microservices enabled them to launch their first product version 3 times faster.
Unaddressed Technical Debt
Head of Software Engineering
Developing new features takes more time, which increases costs. The reason is technical debt – the consequences of software development actions that prioritize client value or project constraints such as delivery deadlines, over more technical implementation and design considerations. If left without attention, tech debt causes bottlenecks.
The product needs change and the code base must change over time as well. To address technical debt, your team should search for solutions that work best in your business. Refactoring is one of the ways to solve the problem; it’s a great investment in code readability and maintainability, which pays off in optimized delivery time.
Technical Debt (Techstack case)
For each reason why legacy code appears in the application, we identify code that needs refactoring and re-write it one module at a time to prevent stress for the production environment. After a code review, we wipe legacy blocks out. Based on my observation, refactoring helps to increase new feature delivery speed up to 7 times, and speed up server queries up to 2.5 times. The coding process also becomes easier – at one of our products developers now wait for 5 times less to compile a new build.
Bugs Multiply Fast
Director of Quality Engineering
As the product grows and more users interact with it, the codebase grows as well. The number of bugs naturally also grows, since there are more code blocks to interfere with each other. More labor is necessary to find and fix the discrepancies, and more users end up not following the best path. If you’re going to grow quickly, take proactive steps to address this increase in workload for your QA function.
Among the measures you can take to avoid a flood of bugs, consider inviting the QA engineer or the QA team to technical requirements grooming, and involving the QA team to work in parallel with the development team.
If you’re already growing and need to take steps to elevate the QA efficiency, automation will help. Increase the number of integration and back-end tests, which helps speed up feedback on the quality and testing coverage. Fixing the testing process allows the introduction of a CI/CD pipeline and automation of quality assurance with IT operations and delivery. This leads to a huge efficiency increase for the team and sets the product quality bar high which, in our experience, reduces bugs to an average of 20-25%.
The Platform Fails to Tackle User Load
Head of Software Engineering
Another threat to your product’s platform is… users. On one hand, user load proves that your product is extremely valuable. On the other hand, you have to ensure that every user can get the same high level of experience regardless of the number of other users wanting the same.
What helps us to ensure the product is ready for the wide audience is thorough a search for bottlenecks in all system layers, including front- and back-end, data storage, and communication protocols. For each specific case, we apply tailor-made solutions: caching, bundle optimization, database normalization, pagination, or others.
User Load (Techstack case)
The reasons why the product can’t withstand user load properly may vary. So, in addition to the increased application user load capacity, you frequently get positive increases in other metrics, for example, improving user experience, system performance, and infrastructure costs. We had cases when user visits grew by 7 times whereas infrastructure costs were reduced by about 2-2.5 times. We developed a solution for an IoT product that couldn’t withstand the load of user data sent to servers simultaneously. The solution included migration to serverless architecture in the cloud, which turned out to be far more affordable than physical servers.
Wrong Data Storage Schema
VP of Engineering
Another common challenge is associated with databases. In many products, there’s one database which has its limits and idiosyncrasies. As the product evolves iteratively, it’s difficult to choose the right data structure and database services from the very beginning since you don’t know all the specifics from the start. Once your product finds product-market fit and the core functionality is there, you can split the base into domains and microservices by applying a master-slave replication, or we can change the data storage concept to an event-based model to ensure the database would never block growth.
In the case of splitting into domains, you transfer all the data associated with the domain of your choice into a different database. Data shared across multiple domains are subject to one-way replication between databases to avoid inconsistency. The same is true for databases split across multiple microservices. The challenge is to project the division so that it can optimize shared data and dependencies.
Data Storage (Techstack case)
We had a project that was a great cast for applying an event-based data sharing model. The transition we implemented helped to grow performance 30-fold. Many customer engagement products may benefit from switching to event-based architecture. Learn whether your product qualifies.
Based on the data structure and nature, you should decide which split type is most applicable and decentralize the data system and increase performance.
Infrastructure Expenses Rise High
Head of Software Engineering
Talking about infrastructure, I must note that often product growth requires an expansion of infrastructure services. If your check for infrastructure becomes hefty, start with an audit of services used by the product and their limitations. You may over- or underestimate the infrastructure capacities necessary for your solution. I’d review which of them you use to their fullest and which you don’t. The next point to pay attention to is the frequency of use. You should not pay high prices for solutions that aren’t in regular use. To ensure you get the most out of your infrastructure costs, segregate use cases by customer segments, location, and time of use (at day, at night, etc.) These details contain the key to optimization, restructuring, or the best choice of the infrastructure provider.
Infrastructure (Techstack case)
Once we worked on the localization of a product that used third-party auto-generated translations for the user interface. Despite being very efficient from first sight, such solution architecture turned out to slow down website page speed. Users needed to wait till the generation was finished to see the page content. We analyzed the languages and locations we needed to provide and decided to reject the site translation on the go and pre-generate static pages with localization ahead of time. Overall, custom up- and down-scaling solutions for infrastructure enabled 10-fold infrastructure cost optimization.
Poor Security Standards
Head of Software Engineering
The last but not least challenge for startups in the phase of growth is security. To become a part of a technology ecosystem and integrate with other players also requires keeping high standards of security. Fixing security issues after breaches brings reputational risks and significant expenses. That’s why a growing product requires profound security. Nevertheless, early-stage startups prioritize the search for a product-market fit over security.
We always analyze the system to find vulnerabilities and proactively integrate a VPC network, encoding schemes, data obfuscation, or any other necessary security measures. It helps to prevent security challenges while focusing on other valuable aspects of development. We believe that user data and product assets' safety can not be compromised to any extent.
Research says growth challenges cause 70 percent of all startups to fail. As technology experts, we can reduce this probability by excluding tech-related risks and taking proactive measures. If you’re not sure that you’re performing optimally in building scalable tech for your product, discuss your challenge with our technology experts. We will help work out possible solutions and prepare a summarized report with the next steps to unlock your growth after. Contact us to learn more.