Project Estimation for Legacy Software Development

Three years ago, every project estimate started the same way. Break it into tasks, assign story points, divide by velocity, call it a deadline.

About 40% of the time I burned.

Not because I was bad at decomposition. The tasks were fine. The problem was that on a legacy project with a client's Bitrix backend, tasks aren't the main variable. Risk is.

I've since changed the order. First I name three things that can break everything. Then I give the timeline. Clients who find that uncomfortable aren't my clients.

Why story points fail outside stable teams

Story points work when you have reliable velocity — when a month of data tells you that 30 points equals two weeks of work. That's an honest tool for a product team with a steady backlog and a known codebase.

On a client project, none of that exists. There's no velocity to reference. There's a Bitrix backend you've never touched, a REST API with no documentation, and shared hosting that may not match what was discussed on the sales call.

When you estimate "get products from the API" at 5 points, you're estimating the effort under ideal conditions. You're not accounting for an API that returns 14 different response structures depending on product type, or offset-based pagination that quietly breaks at 10,000+ records.

Story points measure work. Risks need to be measured separately.

Three risk categories I check on day one

Before I give any timeline, I look at three things.

The first is integration risk. What's the external system, and how much can I actually trust it? If the backend's an undocumented Bitrix instance, I budget two to four days just for reconnaissance — what I call a Catalog Probe. Map the response structures, test edge cases, find where the API lies before it surprises you mid-sprint.

Second is infrastructure risk. What's the hosting setup, is there CI/CD, how does the site currently deploy? I've worked on projects where "deploy" meant FTP and prayer. Getting a proper pipeline in place can cost a week nobody budgeted for.

Third is requirements risk. If the answer to "how do discounts work in the catalog?" is "well, it's complicated" — you'll lose time to clarifications in the middle of the project instead of the start. That's not a reason to walk. It's a reason to price the uncertainty separately.

What a risk map looks like for a real project

On the 28,000 SKU headless migration — Next.js on top of a Bitrix backend — the task-based estimate came out to eight weeks.

Here's what the risk map looked like before we started:

Bitrix REST API: undocumented, structure unknown → 3-day Catalog Probe, +4 days buffer on the integration milestone
Catalog: 28k SKU, imported from 1C over several years → risk of dirty data → +2 days for data-cleansing pass
Hosting: shared server, no SSH access → migration needed → +3 days infrastructure
Filter requirements: "same as the old site" → ambiguity → +2 days for UX alignment

Total buffer: 11 working days on top of the original eight weeks. I quoted 10.5 weeks.

We delivered in 10 weeks and 2 days. The API did return 14 response structures. The Catalog Probe found that on day three, not week three.

You pay for reconnaissance upfront, or you pay for surprises in week six.

Buffer isn't a safety net — it's the price of uncertainty

When I explain a buffer to a client, I sometimes hear: "So you're adding padding for your own mistakes." No.

The buffer is the cost of information we don't have yet. On a familiar project with my own stack, I won't have a 20% buffer. On a client's legacy system with an unknown API, I will.

Think of it like a renovation estimate. An experienced contractor working on a house they've never opened the walls of will quote 15% for surprises. Not because they're bad at their job — because the walls haven't been opened yet.

If a client can't accept that logic, they're expecting ideal conditions in a place where none exist. That conversation is better had before signing, not after.

The client conversation

"We don't know yet" sounds like incompetence.

"There are three unknowns, and here's what we're doing with each one" sounds like control.

I explain the risks specifically: "The API isn't documented, so we're spending three days confirming the structure before we build on top of it. That doesn't delay the start — it reduces the chance of redoing work in week six."

The client doesn't hear "we're scared." They hear "we're managing risk." That's a different posture, and it reads differently across the table.

Projects where clients accepted this framing finished on time or early. Projects where I agreed to "let's figure it out as we go" burned about 70% of the time. Not an exaggeration.

What changed

Since switching to risk-first estimation, I've had fewer conversations about deadline slippage and more conversations about outcomes. Clients who went through the Catalog Probe with me understood why the timeline was what it was. They'd seen the data.

I still use story points. On internal work with a known stack and stable team, they're fine. But the first question on any new client project isn't "how many points is this?" It's "what could break everything here?"

That question takes half an hour. It saves a week of rework.