The question I get most often on a first call isn't "how much?" It's "how long?" And the honest answer — "it depends" — is useless to someone trying to plan a launch, a funding round, or a trade show demo.
So let me give you something better. Below is how a software project timeline estimate actually gets built, what each phase really costs in calendar weeks, and the parts almost everyone forgets to budget for. I've written this for the business owner who has been burned before, or who is about to sign their first development contract and wants to know if the number in front of them is sane.
Why most timeline estimates are wrong
Estimates don't fail because engineers can't count. They fail for three boring reasons:
- The scope wasn't actually defined. "A booking app" can mean six weeks or nine months. Nobody pinned it down before the number was given.
- Only coding was counted. Design, QA, revisions, deployment, client review cycles, and the inevitable "can we also..." all live outside the dev estimate in a lot of proposals.
- The client's own availability wasn't included. This is the big one. If approvals take five days instead of one, the project stretches. That's not a vendor problem or a client problem — it's a planning problem.
A good estimate accounts for all three. A bad one gives you a confident single number with no assumptions attached. If a quote has no assumptions listed, treat the timeline as fiction.
What the phases actually look like
Here are realistic calendar ranges for a small-to-mid-sized custom product — think a web app with user accounts, a dashboard, payments, and an admin panel. These are typical, not guaranteed, and they assume a team of two to four people working on it consistently.
1. Discovery and scoping — 1 to 3 weeks
Workshops, user flows, a written feature list, a technical approach, and a rough architecture. This is where you decide what version one actually is. Skipping it feels fast. It isn't — you pay it back later with interest in rework.
If you already have a detailed spec and wireframes, this compresses to a few days of review. If you're starting from a conversation and a competitor's website, budget the full three weeks.
2. UI/UX design — 2 to 5 weeks
Wireframes, then high-fidelity screens, then a design system so the build is consistent. The variable here is almost entirely review speed. Two rounds of feedback is normal. Five rounds means the discovery phase was too thin.
3. Core development — 6 to 16 weeks
This is the chunk everyone thinks of as "the project." It runs in sprints, usually two weeks each, with something demoable at the end of every sprint. If your development partner can't show you working software every two weeks, that's a red flag worth asking about before you sign.
Rough mental model: a well-understood feature with no third-party integration takes a few days. A feature that touches payments, external APIs, or complex permissions takes a week or more — not because the code is harder, but because the edge cases and error states multiply.
4. Integrations — the wildcard
I pull this out separately because it ruins more timelines than anything else. Connecting to a modern, well-documented API (Stripe, Twilio, Google) is predictable. Connecting to a bank's legacy system, a client's 2011 ERP, or a partner whose sandbox credentials take three weeks to arrive is not.
Always ask: who owns each integration, and have they confirmed access? If the answer is vague, add buffer.
5. QA and bug fixing — 2 to 4 weeks
Real testing runs alongside development, but you still need a dedicated hardening window at the end. Functional testing, cross-browser, mobile responsiveness, load behaviour, security basics. Anyone who quotes you a project with zero QA time is quoting you a prototype.
6. Deployment, handover, and the first two weeks live — 1 to 2 weeks
Production setup, monitoring, documentation, training your team. Then the shakeout period where real users find the things no test suite caught. Budget for it. It always happens.
Putting it together
Add those up and a straightforward custom web application typically lands at three to six months from kickoff to live. A simple internal tool or a focused MVP can be six to ten weeks. A multi-role platform with heavy integrations and compliance requirements comfortably runs nine to twelve months.
AI and ML work has its own shape. A project that uses existing models through an API — document extraction, a support assistant, classification — can move quickly, often in the same range as regular development. But anything involving your own data, custom training, or accuracy thresholds needs an experimentation phase where the honest answer is "we'll know in three weeks whether this approach works." I'd rather tell you that up front than pretend it's a fixed-scope build. We talk through this openly on AI & ML development engagements.
How to make your software project timeline estimate more accurate
You have more control over this than you think.
- Name one decision-maker. Committee approvals are the single biggest source of silent delay. One person with authority to say yes keeps the clock moving.
- Agree what version one is — in writing. Then put everything else in a "phase two" list. Having that list visible makes it much easier to say "yes, phase two" instead of quietly bolting features onto the current build.
- Give feedback in batches, fast. Consolidated feedback within 48 hours beats a trickle over two weeks.
- Sort out access early. Domains, hosting, API keys, third-party accounts, brand assets. These are tiny tasks that block big ones.
- Ask for the assumptions. A timeline without assumptions is a guess with good posture.
When you shouldn't commission custom software at all
Worth saying plainly, because it saves people money. If your requirement is genuinely standard — a basic online store, a brochure site, a simple booking page — off-the-shelf tools will beat custom development on both cost and time, and it isn't close. Use them.
The same goes for internal tools. Before you commission a bespoke sales system, check whether a configured product does the job. That's part of why we built Orbis Lead CRM — a lot of companies came to us wanting custom lead management, and for most of them a solid, configurable product was the faster and cheaper answer. Custom makes sense when your process is genuinely your edge, or when no existing tool fits without painful workarounds.
A word on fixed-price versus time-and-materials
Fixed price works when scope is tight and well understood — a defined integration, a migration, a redesign with agreed screens. You get certainty, and we price in the risk, so you pay a little more for that certainty. That's a fair trade.
For discovery-heavy or evolving products, sprint-based billing is usually better value. You can change direction after seeing working software, which is exactly when the best product decisions get made. The thing to avoid is fixed price on vague scope. That arrangement makes both sides defensive, and the software suffers.
The short version
A realistic software project timeline estimate includes discovery, design, build, integrations, QA, deployment, and your own review time. It comes with written assumptions. It has a buffer of roughly 15–20% for the unknowns, because there are always unknowns. And it gets revisited at the end of every sprint rather than defended to the death.
If you want a straight answer on how long your specific idea would take, send us the rough outline and we'll walk you through the phases and where the risk sits — including telling you if a cheaper off-the-shelf route would serve you better. You can see the kind of projects we take on in our work, or just get in touch and we'll set up a call.