It’s a trade-off often faced by startups: you’re told to ship quickly, and out of financial necessity you have to. But shipping something unpolished could have a cost down the track: in time spent re-coding elements of your platform, or costs to replace a system which can’t be scaled because of inherent limitations.

It’s called incurring a ‘technical debt’ and for technical founders the concept is not new, but for non-technical founders, it helps to understand the trade-offs constantly faced by your development team.

American computer programmer Ward Cunningham first came up with the term ‘technical debt’, in an attempt to explain how making a development decision to ship something quickly can have an impact down the track.

As enterprise software consultant and author Martin Fowler explains on his blog, by treating this trade-off like financial debt, it becomes much easier to quantify.

“Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.”

It’s a concept Stephen Neville, Director at Commoncode, a Melbourne-based web development and outsourcing collective, is very familiar with. His organisation undertakes web development projects for large companies as well as startups, helping their existing teams to build new applications. It has built the e-commerce platforms for Kogan and Cotton On, among others.

“The metaphor is based on using the concept of financial debt,” he says. “You’re essentially borrowing money against the future.”

So what does this metaphor mean for startup companies using the lean methodology?

Paul Dyson, founder of  Singletrack Systems, has given this some thought. He argues that technical debt is very different for a startup compared to an established business. For a startup, the priority is determining what your customers want, and even who they are. He says the primary objective is finding those customers and not necessarily building for sustainability. That’s a concern for later — only if users respond to a feature does it make sense to pay off that debt.

Stephen Neville says its important for non-technical founders to understand the concept of technical debt (Image: Courtesy of RLHyde)

Like paying off your credit card, ‘refactoring’ your debt, and paying down the principal helps to reduce the amount you owe; you’re monitoring the limitations of your system, which can snowball out of control if they’re not kept in check.

“It’s something non-technical founders don’t always understand. The pressure to meet a deadline or release a new feature can have implications down the track,” says Neville.

Neville says setting a side time each month or quarter to go back and review previous code can help manage the potential cost of technical debt. Another simple solution is to stick a Post-It on the wall for every change you want to go back and fix. That way there’s a running list of things to go back and refactor when the time comes.

“A great example is Facebook. It’s incurred so much technical debt, it requires 50 engineers to go back and refactor code.”

New York based agency Alexander Interactive, discusses on its blog why distinguishing between the ‘business’ and the ‘technical team’ can cause problems too —  in reality both are running the same race: “It is in dealing with these constraints from ‘the business’, that we regularly incur technical debt: to meet a deadline, or to facilitate a sudden change in requirements, we commit to compromises in the code or architecture that we know we’ll need to fix someday.”

Neville explains that SAAS solutions can be great to test an idea, but inevitably there will be some limitations when you reach a certain size. Shopify or Bigcommerce might be fine to use when you’ve just launched your ecommerce startup and are after proof the concept works. However, once you require more specialised features like a multi-lingual, multi-currency online store, you may have to build your own solution. There’s a trade-off in the meantime; think of it as the opportunity cost of each option. The same goes for all the other platforms you use: email marketing, payment solutions etc.

“It’s something in the startup scene to keep a focus on. Sometimes when you’re making decisions, you’re incurring some kind of cost,” Neville says.

It’s part-and-parcel of building new products, and in itself, technical debt is not a bad thing. It’s just important to understand the trade-off between now, and the future.

How do you measure how much technical debt your startup has incurred? How heavily into debt are you prepared to go? How do you plan to dig yourself out of technical debt? Keep these questions in the back of your mind, ensure your founding team agree on the answers, and review them regularly to make sure you’re still managing your business with this sometimes hidden debt included in your calculations.