[ad_1]
Technology debt is the off-balance sheet cost of technology work that must be done in the future. It accumulates by choosing a limited / less expensive technical solution now and pushing the complete / more expensive solution into the future. By not implementing the complete solution now, companies are faced with the need to “rework” software development in the future.
Having worked closely with more than 25 startups during their journey from early stage to growth stage, I have come to understand how tech debt triggers rework and what startups need to do to avoid it and move to the next level.
Startups often consider the short-term benefit of quick delivery to achieve the milestone, acquire important customers, or raise the next round of funding. It’s also common for startups to add functionality that wasn’t part of the original roadmap by neglecting the long-term vision.
You can’t completely walk away from doing things the fast and dirty way at a startup. However, if you don’t pay your tech debts on time, the debts plus ‘interest’ add up, making it even more difficult to implement changes later.
Here are four common ways startups rack up tech debt.
1. Let me onboard the customer first and focus on the product roadmap later.
When customizing the capabilities of a product to acquire a customer, startups often neglect generic product design and capability. They do not see beyond the initial needs and consequently they build a product that is not useful to a wider audience.
For example, I worked with a company that built two versions of the same product: one version was customized for a marquee client, and the second was a generic product. Ongoing custom work continued for a full year. It became a nightmare for the team as merging and stabilizing the product set the team back 20 months in man-hours.
A product cannot be customer specific, but implementations can. However, business owners are often drawn to early insights and implement implementations rather than develop a product.
The demands of marquee customers often force them to quickly add required features to the product. In fact, these offers make it difficult to negotiate deadlines, causing startups to cut corners and cut corners.
As they rush to meet deadlines, they don’t consider the platform as a whole and how it will adapt to all these custom changes later.
Startups typically take around 18 months to obtain the next level of funding. So spending more than a quarter on rework would hamper your chances of moving to the next level of funding.
Adding new developers to the team to speed up rework is not a viable option. Someone coming from outside would not fully understand the whys and whys of the project, and it can affect the team as a whole.
Lesson: Reworking a product to generalize features to customer-specific implementations could lose a quarter per year.
2. My product is stable, why change it?
Startups tend to get complacent when they have enough customers paying for their product in a particular domain. They often take advantage of the pioneer advantage to get the jump start. Then direct or tangential competitors emerge and begin to nibble on your market share.
This is when the stability of architecture, design, technologies, and versions are often overlooked in the rush to add new features to the predictable, revenue-generating product.
But just focusing on making the product feature-rich can be a mistake. It’s important to ask yourself if the foundation is good enough to accommodate these new built-in features.
For a software product, the foundation is its technology and architecture. These two cannot be easily altered. Overloading of features may cause the foundation to crumble.
The foundation is what makes scale possible, or not. Scaling the product is not just about managing volume; it also requires fast paced shipping features. Upgraded versions of architectures or technologies are simpler, better suited for feature additions, and provide a better experience. In addition, developers do not want to work with outdated technologies, which affects their productivity and lowers morale.
Another major deterrent that prevents startups from improving technology is ROI. Businesses do not want to interrupt the usual flow if the influx of paying customers is satisfactory.
I experienced this first hand when proposing a technology rewrite to a client. It was a job with a requirement of 80-100 man-months, and the customer didn’t want to waste so much time rewriting code for a stable product that was generating constant revenue.
Unfortunately, this company is now spending more time reworking and hacking to keep the product stable.
Lesson: When team productivity falls beyond an acceptable level, the adoption of new technologies helps accelerate 2x-3x product development.
3. We embrace open source technology – it’s ready for the future
Open source is definitely a good option for startups. In the early days, startups are primarily concerned with their product and its ROI. This is natural, since a company at this stage does not usually have paying customers.
Some early-stage companies don’t even have investors. In such circumstances, taking a profitable measure is an expected move.
But to use open source software, one has to continually update to newer versions as they are released. Skipping one might not cause much of a problem, but failing to update two or three major versions could create a huge tech debt, which could take a colossal effort to resolve. The process could consume significant man-months with dedicated teams.
As an example, in one of my projects, the client had to set aside a team of developers for four months to incorporate changes that would make the updates possible. This is a quarter of the entire financial year, which, for a startup, could be a deal breaker. If the company had been updated on time, they would only have faced a two-week setback.
I have also seen projects where such implementations were not possible. In one of those cases, we were using the Broadleaf Commerce framework for an e-commerce marketplace.
To make up for the lack of features, developers began creating hacks to support customization of the framework. When the updates for Broadleaf became available, they did not set aside time for it.
Later, after some major releases, the upgrade became impossible and the company was stuck with a non-standard framework with patches. As a result, the team spent more time adding capabilities to the framework, which were part of the omitted versions.
Companies that update open source software on a regular basis benefit in other ways as well. Updated open source frameworks come with many built-in features, which are free. It reduces the total cost of the project and frees up a lot of developer capacity that can be used to develop other basic functions.
Lesson: Transitioning more than two major versions of an open source framework requires more than 25% of the annual bandwidth of the entire team.
4. Let me meet immediate needs and redesign the product only if necessary.
In an attempt to capture the initial market or meet growing business demands, most startups try to meet immediate needs and avoid any bottlenecks. By doing this, they ignore future technology challenges.
The reason this usually happens is because engineering teams often get limited visibility into the future of a startup, which is important for making certain architectural decisions.
But even with full visibility, you may need to focus more on medium-term needs considering the ROI of implementing complex solutions at the time.
Engineering leaders must have a thorough understanding of NFRs, even when selecting short-term solutions. It is important to set aside time to handle technology debt that NFRs could accumulate.
If this debt is not paid on time, it will destabilize the architecture and lead to a complete remodel. Re-architecture may seem like an easy decision, but it takes several months, and matching the re-architecture with serving existing clients is challenging.
To develop this aspect, let me share with you another real experience. One client was looking for retail investors and they were precise about the markets they wanted to explore, having limited the amount of data they had to filter.
When we were batching, this reduced data never affected us. But with the influx of investments, the company went from being a regional entity to a national player.
One obvious result was an increase in data volume, making batch processing difficult to manage. Scaling quickly to meet the requirements became a big problem. This type of tech debt is fine for a specific business scenario, but it can cause chaos if you change your business strategy.
Lesson: Understanding the product vision and identifying non-functional requirements (NFR) in advance will avoid the need for a complete re-architecture.
The bottom line
The fate of startups and tech debt are intertwined. If early-stage companies neglect technology debt for too long, they can face significant challenges of restructuring products with associated costs that grow over time. This reality will have an impact on the business result both in terms of product development and ROI.
Despite knowing some of these realities, many startups still fail to manage technology debt in the rush to achieve their next milestone. Identifying future challenges and keeping your startup future-ready requires planning, discipline, and ongoing effort.