4 tech debt pitfalls your startup needs to avoid

Tech debt is the off-balance sheet cost of technology work that needs to be done in the future. It accumulates by choosing a limited/less expensive technical solution now and pushing off the full/more expensive solution to the future. By not implementing the full 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 gained an understanding of how tech debts trigger reworking and what startups should 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 marquee customers, or raise the next round of funding. It’s also common for startups to add functionality that was not part of the original roadmap by neglecting the long-term view.

It’s not possible to completely move away from doing things the quick and dirty way in a startup. However, if you don’t repay tech debts in time, the debts plus ‘interest’ pile up, which makes it even more difficult to implement changes later on.

Here are four common ways startups pile up tech debt.

1. Let me onboard the customer first and focus on the product roadmap later

While customizing features for a product to acquire a customer, startups often neglect generic product capability and design. They fail to see past the initial needs, and consequently, they build a product that is not useful for a larger audience.

For example, I worked with a company that built two versions of the same product – one version was customized for a marquee customer, and the second was a generic product. The ongoing customized work continued for a whole year. It turned into a nightmare for the team as merging and stabilizing the product pushed the team back by 20 months in man-hours.

A product cannot be customer-specific, but implementations can. However, business owners often get lured by the initial prospects and do implementations instead of developing a product.

Demands from marquee customers often force them to add required features to the product quickly. In fact, such offers make negotiating deadlines difficult, which results in startups cutting corners and taking shortcuts.

While rushing to meet deadlines, they don’t consider the platform as a whole and how it will later accommodate all these customized changes.

Startups typically have about 18 months to raise the next level of funding. So spending more than a quarter on reworking would impede their chances of moving to the next funding level.

Adding new developers to the team to expedite rework is not a feasible option. Someone coming from the outside would not fully understand the whys and the whats of the project, and it may affect the team as a whole.

Lesson: Reworking a product to generalize features from 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 paying customers for their product in a particular domain. They often leverage the first mover’s advantage to get initial momentum. Then either direct or tangential competitors emerge and start nibbling at their market share.

This is when the stability of the architecture, design, technologies, and versions often get ignored in the race to add new features for the predictable revenue-earning product.

But only focusing on making the product feature-rich can be a mistake. It’s important to ask if the foundation is good enough to accommodate these new feature additions.

For a software product, the foundation is its technology and architecture. These two are not easily alterable. If the burden of features is too much, the foundation might crumble.

The foundation is what makes scaling possible, or not. Scaling the product is not just about handling volume; it also requires shipping features at a rapid pace. Upgraded versions of architectures or technologies are leaner, better suited for feature additions, and deliver a better experience. In addition, developers don’t want to work with obsolete technologies, which affects their productivity and lowers morale.

Another major deterrent that holds back startups from tech upgrading is ROI. Businesses don’t want to disrupt the usual flow if the paying customer influx is satisfactory.

I experienced this first hand while proposing a rewriting of the technology to a client. It was a job with a requirement of 80-100 man-months, and the client did not want to spend that much time rewriting code for a stable product that was generating constant revenue.

Unfortunately, this company is now spending more time on reworking and hacks to keep the product stable.

Lesson: When the productivity of the team drops beyond an acceptable level, adopting new technologies helps speed up product development 2x-3x.

3. We adopted open-source technology – it’s future-proofed

Open-source is definitely a good option for startups. In the initial days, startups worry mostly about their product and its ROI. This is natural since a company at this stage typically doesn’t have paying customers.

Some early-stage companies don’t even have investors. Under such circumstances, adopting a cost-effective measure is an expected move.

But to use open-source software, one has to continuously upgrade to newer versions as they release. Skipping one may not cause much trouble, but failing to upgrade 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 to make the upgrades possible. This is a quarter of the entire financial year – which for a startup, could be a deal-breaker. If the company had upgraded in time, they would have faced only a two-week setback.

I have also seen projects where such implementations were not possible. In one such instance, we were using the Broadleaf Commerce framework for an ecommerce marketplace.

To make up for the lack of features, the developers started building hacks to support customization for the framework. When the upgrades for Broadleaf became available, they did not set aside time for it.

Later, after a few major versions, upgrading became impossible and the company was stuck with a framework that is non-standard with patches. As a result, the team spent more time adding capabilities to the framework, which were part of the skipped versions.

Companies that update open-source software on a regular basis also benefit in other ways. Updated open-source frameworks come with a lot of built-in features, which are free. It reduces the total project cost and frees up a lot of developer capacity that can be used to develop other core features.

Lesson: Transitioning more than two major versions of an open-source framework requires more than 25% of the yearly bandwidth of the entire team.

4. Let me fulfill the immediate needs and re-architect the product only if required

In a bid to capture the initial market or fulfill growing business demands, most startups try to meet the immediate needs and avoid any bottleneck. By doing this, they ignore future technological challenges.

The reason this happens is usually because engineering teams often get limited visibility about a startup’s future, which is important to make certain architectural decisions.

But even with complete visibility, you might have to focus more on medium-term needs considering the ROI of implementing complex solutions at that time.

Engineering leaders should have complete know-how about NFRs, even in the case of selecting short-term solutions. It’s important to set aside separate time to handle tech debts that NFRs could pile up.

If this debt is not paid up in time, it will destabilize the architecture leading to complete re-architecting. Re-architecture might seem to be an easy decision, but it takes several months, and coinciding re-architecting with serving existing customers is a challenge.

To elaborate on this aspect, let me share another real experience. A 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 doing batch processing, this narrowed-down data never affected us. But with the influx of investments, the company expanded from a regional entity and became a national player.

An obvious outcome was an increase in the volume of data, which made managing the batch processing difficult. Scaling fast to meet the requirement became a huge problem. This type of tech debt is fine for a specific business scenario, but can trigger mayhem if the business strategy changes.

Lesson: Understanding the vision for the product and identifying Non-Functional Requirements (NFRs) in advance will avoid the need for complete re-architecture.

The bottom-line

The fate of startups and tech debts are intertwined. If early-stage companies neglect tech debts for too long, they can face significant challenges of rearchitecting products with associated costs that grow over time. This reality will impact the business outcome both in terms of product development and ROI.

Despite knowing some of these realities, many startups still fail to manage tech debt in the rush to achieve their next milestone. Identifying future challenges and keeping your startup future-ready requires planning, discipline, and continuous effort.