How to Price Technical Debt in Days: A Worked Example

Why "the code is messy" can't be priced

Nobody can budget "messy." They can budget "payment logic is copied in three places, merge it into one." The first is an opinion. The second is a task with a start, an end and a cost. Most technical debt guides are written for engineering teams and assume tools that scan code and report hours. A non-technical founder needs something simpler: a list they can read, question and defend in front of an investor or a new developer. Technical debt is the extra work you'll do later because of shortcuts taken now. The principal is the work to fix it. The interest is what it costs you each week you leave it alone. You put a price on both.

Step 1: One problem per line

The method takes five steps. In the first, each line names one problem in plain words, specific enough that a developer could start on it tomorrow. If a line fails either of these two tests, split it or rewrite it:

• Could someone who never saw the code understand the line?
• Is there a clear point where the fix is done?

Step 2: A range in days, then keep the high end

Ask whoever knows the code for a low and a high estimate on each line. Use the high end. Fixes in tangled code take longer than planned because touching one part breaks the part next to it. If you can, get a second estimate from someone who didn't write the code. The original builder tends to know the shortcuts and underrate them. When the two estimates are far apart, ask why. That conversation alone tells you a lot.

Step 3: Add testing and handover

The high-end total isn't your final number yet. Add two things:

• Testing. Every fix needs checking, and so does the code around it. Pick a buffer and write it down so nobody forgets it was there.
• Handover. If a new developer will do the work, they need days to read the code and get it running before they fix anything.

Step 4: Write the interest next to each line

For each line, write one sentence on what leaving it costs you today. Examples: "a user could see another user's bookings," "every new feature takes longer," "only one person can release." That sentence decides the order of the work, not the number of days.

Step 5: Sort into three buckets

Spend the "now" bucket first, whatever the total says.

• Now: anything that puts user data or money at risk.
• Before the next milestone: anything an investor, a new hire or the App Store will run into.
• Later: anything that only slows you down.

A worked example from start to finish

Here is a made-up but typical case. A founder built a class booking app for a fitness studio with Lovable. It runs on the web, takes payments, and has a mobile version that is the web app inside a shell. Here is the debt list once each line is written properly:

• 1. API keys sit in the front-end code. Range: 0.5 to 1 day. High end: 1 day. Interest if left alone: anyone can read them and use your paid services. Bucket: now.
• 2. Database rules missing: any logged-in user can read all bookings. Range: 2 to 4 days. High end: 4 days. Interest if left alone: customer data exposed. Bucket: now.
• 3. Payment logic copied in three places. Range: 2 to 3 days. High end: 3 days. Interest if left alone: a price change fixed in one place stays wrong in two. Bucket: before milestone.
• 4. App can only be deployed from the builder, no rollback. Range: 2 to 3 days. High end: 3 days. Interest if left alone: every release is a gamble, one person can ship. Bucket: before milestone.
• 5. No error tracking. Range: 0.5 to 1 day. High end: 1 day. Interest if left alone: you hear about bugs from customers. Bucket: before milestone.
• 6. User table mixes accounts and studio profiles. Range: 3 to 5 days. High end: 5 days. Interest if left alone: every new feature needs a workaround. Bucket: later.
• 7. Mobile app is a web wrapper. Range: not a fix. High end: priced separately. Interest if left alone: store rejection risk, weak mobile experience. Bucket: separate project.

The arithmetic

Now the arithmetic:

• 1. High-end total for lines 1 to 6: 1 + 4 + 3 + 3 + 1 + 5 = 17 days.
• 2. Testing buffer: in this example the founder chose 30%, so about 5 days. Total: 22 days.
• 3. Handover: a new developer will do the work and needs 2 days to get set up. Total: 24 working days.
• 4. Line 7 stays off the total. A native iOS and Android app isn't a fix to a wrapper. It's new work, priced as its own project.

What the founder now knows, by bucket

By bucket, the founder now knows:

• Now: 5 days of work plus its share of testing. This starts this week.
• Before the milestone: 7 days, done before anyone outside the team gets access.
• Later: 5 days, planned once the urgent items are closed.

Turning days into calendar time

24 working days for one developer is about five weeks. Adding a second developer rarely halves it, because some lines depend on others. Here, the deploy setup (line 4) should be in place before the payment fix (line 3) ships, and the data model (line 6) touches almost everything. To get the cost, multiply the days by your developer's day rate. You now have a budget you can explain line by line. If you'd rather see what a clean build of the same scope involves, our app feature cost estimator gives you a quick reference point. Or bring both numbers to a free 30-minute call and we'll look at them with you. Book a call.

Mistakes that make the total wrong

Five mistakes come up again and again:

• Pricing "refactor the app" as one line. It hides everything. Split it until each line has a clear end.
• Using the low end. It's the number you hope for. Budget the one you'll probably get.
• Forgetting security items. Run our free AI App Production Readiness Score first and put its punch list on the same sheet.
• Pricing new features as debt. "Add a referral program" isn't debt. Keep it on the roadmap, not on this list.
• Treating a missing export as a small fix. If the code only lives inside a builder, check what you can actually take out before you price anything. Our guide on Lovable export options covers this.

What to do with the total

Once you have the number, set it next to a rebuild estimate for the same scope. That comparison is a separate decision, and we cover it in technical debt in startups: when to fix it and when to ship anyway. One rule holds either way: a rebuild only works if the scope stays the v1 you already validated. New features come after launch. More on taking AI-built apps further is in our AI prototype to production articles.

How BuildMVPFast builds an MVP

If your list points to a clean build, here is our MVP offer. If you already have an app, we go through it together on the call first. No work starts until you have the fixed quote. Our services page shows how we work. Have a debt list and no idea whether the total is reasonable? Bring it to a free 30-minute call and we'll go through it line by line. Book a call.

• Fixed at $3,460, with a fixed quote given before we start.
• Your app on the web, iOS and Android.
• Delivery in about 20 days.
• Progress shown every week.
• Design included.
• 100% of the code is yours, on your GitHub.
• 2 weeks of fixes after launch.

Who should estimate the days on my debt list?

Start with your current developer, then get a second estimate from someone who didn't write the code. Keep the high end of both, and ask about any line where they disagree a lot.

How big should the testing buffer be?

There's no universal number. It depends on how tangled the code is and whether it has any tests. Pick a percentage with your developer, write it on the sheet, and don't remove it later to make the total look smaller.

Should I fix the cheapest lines first?

No. Fix what puts data or money at risk first, even if it costs the most. Cheap lines that only slow you down can wait.

How long does a rebuild take?

It depends on your scope. Book a free 30-minute call, we look at your app together and you get a fixed quote before we start.