Software development timeline estimate: reading vendor bids in 2026

1. TL;DR
2. Why one bid says ten months and another says twenty
3. Two 2026 deadlines already sitting inside your delivery plan
4. How we read a delivery timeline
5. What a delivery timeline is actually made of
6. The clock you control is bigger than you think
7. Eight questions for the vendor with the short number
8. When a short timeline is honest
9. What our own published delivery record shows
10. A timeline is a claim about who does the unglamorous work
11. Send us the requirements and get an estimate with the scope written out
12. Frequently asked questions
13. Sources

TL;DR

A software development timeline estimate is a statement of scope dressed as a measurement. When one vendor quotes 10 months and another quotes 20 for the same product, the gap says little about how strong either team is. It says what each of them counted: discovery, integrations, data migration, security review, your approvals, and the work starting after launch.

• Across 5,392 IT projects, the mean ratio of actual to estimated cost was 1.8 and the median was 1.0. Most land on the number, a minority miss catastrophically.
• Large IT projects in the McKinsey and Oxford study ran 45% over budget and 7% over time, delivering 56% less value. Dates get held by deleting scope.
• Two 2026 deadlines sit inside plans already signed: Google Play's Android 16 requirement and the EU Cyber Resilience Act.
• Before comparing numbers, make each vendor write down what its number excludes.

Why one bid says ten months and another says twenty

Three proposals land and the eye goes to one number. Twenty months against ten and twelve reads as slower, pricier, padded. That reading is usually wrong.

A timeline is not a measurement of speed. It is a statement of scope. Twenty and ten answer different questions: what it takes to put a working, supportable product in front of your users, and what it takes to hand you a build. Only one ends where you thought it did.

The evidence on estimates is unkind to everyone. Flyvbjerg and co-authors assembled 5,392 IT projects and found the mean ratio of actual to estimated cost was 1.8, with schedule overruns following the same power law. The median project came in exactly on its estimate. That gap between median and mean is the risk profile: most land near the number, a minority miss so badly the average stops meaning anything. So the spread between two bids says little about how good either team is at estimating.

The question is not who is fastest. It is who counted the same work.

Two 2026 deadlines already sitting inside your delivery plan

Dates you did not choose are already in your plan. A bid that ignores them is short by that much.

Since August 31, 2026, Google Play has required new apps and updates to target Android 16, API level 36, before they can be submitted. Existing apps must target Android 15 to stay available to new users on newer devices. This repeats yearly and surprises someone every time.

Since September 11, 2026, the EU Cyber Resilience Act has required makers of products with digital elements to report actively exploited vulnerabilities and severe incidents: early warning within 24 hours, fuller notification within 72 hours, final report within 14 days of a fix. That is not a launch task but a permanent capability, and someone builds the triage path those hours assume.

How we read a delivery timeline

Five criteria, applied to any timeline someone hands you.

• Where the number stops: demo, feature-complete build, live product, or product in support.
• Which work the bid names, and which it assumes you did.
• How much of the schedule depends on decisions only you can make.
• What the vendor moved onto your desk without saying so.
• What happens to the date when the first integration goes wrong.

Public evidence comes from primary sources, linked in the text. Mercury Development sells the work described here, so we have an interest in this argument. We have also been the long bid in a three-way comparison and lost, which is why these are the questions we would want asked of us.

What a delivery timeline is actually made of

Nothing there is optional. The only variable is whose calendar it lands on, and an honest bid says so.

The clock you control is bigger than you think

One number should change how you read proposals. The McKinsey and Oxford study of more than 5,400 projects found large IT projects ran 45% over budget and delivered 56% less value than predicted, while running 7% over time.

The schedule is what looks fine. Teams hold the date by deleting scope, and the deletion shows up as missing value rather than a late launch. A vendor who promises the date and says nothing about defending scope sells the 7% and hides the 56%.

Much of what causes slippage sits on the client side. In a Hacker News thread on replacing a vendor's platform, one commenter with a decade in asset management wrote that migration onto the new platform is what you think about from day one. Another, a consultant hired repeatedly to move businesses off vendor platforms, added that the plan has to cover users as well as data, because every replaced piece means retraining.

Migration is real engineering work and usually the part nobody sized. Retraining is not engineering at all. Both sit on the critical path, and neither appears in a bid that stops at handover.

Eight questions for the vendor with the short number

1. Does your date end at a demo, a feature-complete build, a live product, or a supported one?
2. Which work is in your price, and which do you assume we have already finished?
3. Which third parties are on the critical path, and what happens if one is late?
4. Who moves and cleans the data, and when in the plan does it start?
5. Who runs the security review and accessibility checks, and is remediation priced?
6. What do you need from us, and by when, for the date to hold?
7. What have you excluded, in writing, that we will have to buy elsewhere?
8. Show us a product you took to launch and supported afterwards, with the dates.

If a bidder answers all eight and the number stays short, it may be real. If the answers arrive as reassurance, the missing months are still there, in your budget.

When a short timeline is honest

Short is not a lie. It is a scope.

A vendor goes genuinely fast when requirements are written and agreed, the design exists, one decision maker has authority, integrations are documented and in your control, and nobody migrates ten years of data. Those conditions are not rare. They are rare together.

Short is also honest for the work it is sized for: a feature on a codebase somebody knows, a throwaway proof of concept, a launch into one market instead of six. Say which one you are buying and the number stops being mysterious.

Dishonest is a number that stays short because nobody named the missing work.

What our own published delivery record shows

We counted our case studies rather than describing them.

Around 30% of the case studies published on our site state how long a piece of work took, and every one of those durations runs in weeks or months. A corporate application for Burger King went from first contact to a working app in under a month. Reverse-engineering an undocumented Bluetooth protocol for Fitbit took two months. Short numbers do not frighten us.

Around 40% of the same case studies describe engagements that ran for years or still run. MiMedia grew from legacy support into a relationship with more than thirty engineers across four parallel projects.

Put both numbers together and the pattern is plain. Work short enough to describe in one sentence is the exception. Most products keep needing attention for years after release, and that part is what a short bid rarely covers. When the bid describes one shape and your product needs the other, the difference arrives later, as a change order.

A timeline is a claim about who does the unglamorous work

Opinion, stated plainly. A bid's length tells you where a vendor drew the edge of its own responsibility, and little else.

There is a reason short bids win. In any competitive process, the proposal that looks best is the one whose author was most optimistic about the parts nobody can see yet. That is selection, not always dishonesty: the bid assuming documented integrations, clean data and fast approvals beats the bid that priced those risks, until month four.

We have been on the losing end of this comparison. Our estimate came in at roughly twice the shortest competing bid, the technical fit was never in dispute, and the shortlist went elsewhere on the headline number. We stand by the estimate.

None of this makes the longer number automatically right. It makes the comparison honest. A scope written down can be argued with, cut, phased or deferred, and a buyer who sees the whole list gets to choose what happens now and what waits. A number with nothing behind it offers no such choice, because the work it left out still has to happen.

Written by Rob Devereaux, Chief Operating Officer at Mercury Development. Rob has run the firm's operations from Hudson, Ohio since 2019 and has over 20 years of operational and financial experience. The delivery records and contract scopes behind this article's timeline comparisons sit in the operations he oversees.

Send us the requirements and get an estimate with the scope written out

Tell us what you want built and we will come back with an estimate that names what is in scope, what we assume your side handles, and what we would move past the first release. You get the list, not only the number.

Frequently asked questions

Why do two vendors quote such different timelines for the same project?

Scope, in almost every case. One number covers a build, the other a live and supported product. The long bid usually includes discovery, integrations, data migration, security review, your acceptance testing and stabilisation. The short bid assumes those belong to you. Compare exclusion lists, not months.

How accurate are software project estimates?

Across 5,392 IT projects, the mean ratio of actual to estimated cost was 1.8 and the median was 1.0, with schedule overruns following the same power law. Most projects land close to their estimate and a minority blow through it entirely. Ask about the failure mode, not the average.

Is a short development timeline a red flag?

Not by itself. Short is a scope, and it is honest when requirements are written, design exists, integrations are documented and one person decides. It turns red when the vendor cannot say what the number excludes, or when the plan has no answer for the first thing that goes wrong.

What should I ask a vendor who quotes a much shorter timeline?

Eight things, in writing. Where the date ends. What is priced and what is assumed. Which third parties sit on the critical path. Who moves the data. Who runs security and accessibility work. What they need from you and when. What is excluded. One product they launched and supported.

Do large software projects run late, or just over budget?

Both, and the budget damage is worse. The McKinsey and Oxford study of more than 5,400 projects found large IT projects ran 45% over budget and 7% over time while delivering 56% less value than predicted. The date survives because scope gets cut.

What client-side delays push a project past its date?

Four recur. Slow sign-off on requirements and content, missing or dirty data, third parties who do not answer, and no single owner with authority to decide. None are the vendor's to fix, yet all sit on the critical path. A credible plan dates your obligations too.

Does data migration belong in the vendor's timeline?

It belongs in somebody's timeline, named and dated. Practitioners who lived through platform moves say migration is what you plan from day one, and the plan covers retraining users as well as moving records. A bid silent on migration has not scoped it.

What platform deadlines affect app timelines in 2026?

Google Play has required new apps and updates to target Android 16, API level 36, since August 31, 2026, with extensions available to November 1, 2026. Existing apps must target Android 15 to stay available to new users on newer devices. This repeats annually, so plan for the next one.

Does the EU Cyber Resilience Act affect my delivery plan?

Yes, if your product reaches the EU market. Since September 11, 2026, makers of products with digital elements must report actively exploited vulnerabilities and severe incidents: early warning within 24 hours, fuller notification within 72 hours, final report within 14 days of a fix. That capability gets built and staffed, not promised.

Can you compress a timeline by adding developers?

Partly, and only in one block. More developers shorten build work. They do not shorten your approvals, a third party's release schedule, a security review, a store submission or a data cleanup. Past a point, headcount raises coordination cost while everything else stays.

Does a fixed-price bid remove timeline risk?

It moves the risk rather than removing it. A fixed price fixes the price of one written scope. Every assumption that fails becomes a change order, and the date slips while both sides argue whose assumption it was. Fixed price rewards precise scope documents, and so does a credible date.

Is paid discovery worth it before committing to a date?

Usually, if the alternative is a date invented from a two-page brief. Discovery converts unknowns into written requirements, and those requirements are what make any number defensible. Paying for one short phase and re-estimating afterwards costs less than committing to a date and finding out later what it was supposed to contain.

How do I compare two vendor bids with different timelines?

Normalise them first. Write one list of work items, then mark each bid in scope, excluded or silent on every line. Price the excluded lines. Add your own obligations with dates. What matters is total time and cost to a live, supported product.