Types of Technical Debt
Ward Cunningham, who coined the term, originally used technical debt to describe a specific type of intentional shortcut: deliberate simplification accepted knowingly, with the intention of refactoring later. The taxonomy has expanded since then. Intentional debt is taken deliberately: a team knows the approach is not ideal but accepts the trade-off for a reason, such as shipping before a fundraising deadline. This is manageable if documented and addressed in a planned refactoring cycle. Unintentional debt accumulates without awareness: poor code quality, missing tests, or architectural mistakes made by a team that did not know better at the time. This is harder to manage because it is not tracked. Environmental debt accrues as the surrounding ecosystem changes: a library that was the right choice three years ago is now deprecated, a cloud service has changed its pricing model, a dependency has unpatched security vulnerabilities. For AI products, there is an additional category: model debt. Prompts written for an older model version, evaluation suites calibrated to a specific model, and architectural assumptions based on current context window limits all become technical debt as models evolve.
How Technical Debt Accumulates in MVPs
MVPs are the highest-risk environment for technical debt accumulation. The pressure to ship quickly, the uncertainty about which features will survive, and the limited resources of early-stage teams all push toward shortcuts. Common MVP-phase debt includes insufficient test coverage, which makes later refactoring dangerous. Hardcoded configuration values that should be environment variables create deployment friction. Monolithic functions that do too many things make features difficult to change independently. Database schemas designed for the first version that do not accommodate later product requirements create painful migrations. For AI MVPs specifically, prompts written as inline strings rather than versioned configuration files make prompt iteration difficult. Missing evaluation suites mean that model changes or prompt updates cannot be assessed for quality regression. Recognising these patterns in advance allows teams to make deliberate choices about which shortcuts are acceptable and which create unacceptable future cost.
The Cost of Unmanaged Technical Debt
Technical debt compounds. A codebase with moderate debt levels requires some extra time on every new feature, typically 20-30% overhead. A codebase with severe debt may reach the point where adding new features takes longer than building from scratch, because every change requires untangling existing complexity and navigating fragile, untested code. Development velocity drops, onboarding new engineers takes longer, and bugs introduced by changes in one part of the system cascade unexpectedly to unrelated parts. For AI products, the compounding is particularly acute because AI components interact with the rest of the system in non-obvious ways. A change to a data processing pipeline may silently degrade AI output quality in ways not caught by conventional tests. Without clear interfaces and evaluation suites, AI product debt is especially hard to navigate safely.
Managing Technical Debt Strategically
The goal is not zero technical debt. Zero debt would mean never taking shortcuts, which would mean shipping too slowly to compete. The goal is managed, visible debt with a servicing plan. Several practices support this. Debt documentation: when a shortcut is taken intentionally, log it as a known issue with the reason it was accepted and an estimated timeline for addressing it. Debt allocation: reserve a fraction of each sprint for debt reduction, often 15-20%, so debt does not accumulate without limit. Refactoring milestones: after a product phase that accumulates significant debt, schedule a dedicated refactoring sprint before the next major build phase. Test coverage tracking provides a coarse signal for whether debt is accumulating faster than it is being serviced.
Technical Debt and GDPR Compliance
Technical debt in the security and data handling layers has regulatory consequences in the UK and EU. Under UK GDPR and EU GDPR, organisations are required to implement appropriate technical and organisational measures to protect personal data. This includes keeping software dependencies up to date, implementing access controls correctly, and ensuring that data subject rights such as erasure can be fulfilled. A codebase with significant debt may have hardcoded user identifiers in multiple tables with no clean deletion path, making the right to erasure impossible to fulfil without extensive remediation. The ICO has levied fines for data breaches that were preventable with basic security hygiene. For UK startups, treating GDPR compliance debt as a first-class category of technical debt with its own management practices is not overcompliance, it is risk management.
How SpeedMVPs Manages Technical Debt
SpeedMVPs builds MVPs designed to be production-ready and maintainable, not just functional for a demo. This means test coverage for core business logic, typed interfaces between system components, versioned prompt configuration, and infrastructure as code rather than manually provisioned environments. We distinguish between debt we accept knowingly for delivery speed and debt we do not accept because the cost is too high, such as missing authentication or unencrypted personal data. Known accepted debt is documented and included in the handover so clients know exactly what to address first as the team grows. GDPR-relevant technical decisions, including data handling, personal data flows through AI APIs, and data deletion paths, are implemented correctly by design rather than deferred. Projects from GBP 8,000, 2-3 week delivery, full code ownership transferred on completion.