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.

For device and healthcare products, the inputs that make these rows priceable are listed in our checklist of what a vendor needs before an estimate.

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.

In regulated builds the client side share grows, and our breakdown of healthcare software project delays names the four dependencies that move the date most often.

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.

These eight cover the timeline. The full list of questions to ask a development agency before signing also covers the contract and post-launch support.

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.