Software project timelines are famously unreliable. Projects that were supposed to take three months take nine. Projects that seemed simple turn into multi-year efforts. Understanding why timelines go wrong is the first step to setting expectations that hold.
Here’s how I think about timelines and what drives them.
The Honest Baseline
For a meaningful business application — say, a custom order management system with reporting and third-party integrations — here’s a realistic timeline:
- Discovery and architecture: 2-3 weeks
- Core build: 4-8 weeks (depends heavily on complexity)
- Integrations and edge cases: 2-4 weeks
- Staging, testing, review: 1-2 weeks
- Deployment: 1 week
Total: 10-18 weeks for something substantive. Call it 3-4 months.
This assumes full client availability for questions, reviews, and acceptance testing. Delays in client responsiveness extend every phase.
What Actually Takes Time
Discovery. This phase is chronically underestimated. Understanding a business process deeply enough to model it in software takes time. The time is worth it — every hour in discovery saves multiple hours in rework — but it can’t be rushed.
Common mistake: starting development before requirements are fully understood. The result is building the wrong thing, discovering it late, and paying to rebuild.
Third-party integrations. External APIs are unpredictable. Documentation is often wrong. Authentication is frequently underdocumented. Rate limits and error handling are frequently learned through experience rather than documentation.
Budget 50-100% more time than you think for integrations. I always do.
Business logic edge cases. The first 80% of business logic is usually clear and fast to implement. The remaining 20% — the edge cases, the exceptions, the “but what about when X and Y are both true” scenarios — takes as much time as the first 80%.
This is the part of projects that’s hardest to estimate. How many edge cases are there? You often don’t know until you’re working through them.
Client review and approval. Every review cycle has a waiting period. Every feedback cycle requires a round of changes. For projects with multiple stakeholders, getting aligned takes time.
Testing and QA. Real testing takes time. If you want software that works reliably in production, testing is not optional and not fast. Cutting testing time means cutting reliability.
What Can Be Accelerated
Standard features. Authentication, basic CRUD, standard navigation — these are faster with experienced developers and AI tooling. Don’t let developers charge large amounts for work that should be fast.
Projects with clear requirements. The clearer the requirements at the start, the faster development goes. Every hour spent on good discovery saves time in development.
Well-defined scope. Feature creep is a timeline killer. Scope that’s defined clearly and changes go through a formal change process allows better estimation and delivery.
What Can’t Be Accelerated
Learning your business. The time it takes to understand your domain deeply enough to build software for it scales with complexity. This can’t be rushed without accepting worse software.
Database migration testing. When your software is working with real production data, migrations need careful testing. Rushing database changes in production is how you lose data.
Security review. Security can be done faster with experience, but it can’t be skipped. A security review that didn’t happen is a liability, not a time savings.
Production hardening. Error handling, logging, monitoring, graceful degradation — the work that makes software reliable in production. This takes time and isn’t optional.
How I Set Timeline Expectations
I use three numbers:
Optimistic: Everything goes smoothly, requirements are clear, client is responsive, no significant unexpected technical problems.
Realistic: Some discovery surprises, a couple of integration edge cases, normal client review cycles.
Conservative: Significant integration complexity discovered late, scope creep managed but with some rework, extended review cycles.
I give clients the realistic number as the project plan and the conservative number as the contingency budget. I’ve never delivered a project on the optimistic number, so I don’t use it.
The “Can You Do It Faster?” Question
Sometimes clients have hard deadlines. Launch before a trade show. Replacement of a system that’s being retired. Regulatory compliance deadline.
For genuine hard deadlines, the answer is usually: yes, but something gives. Either scope narrows, quality floor drops (which I’m reluctant to do), or cost goes up (more hours per day, week-long sprints at higher rates).
I’d rather have the conversation about what that trade-off looks like than promise something unrealistic and deliver late.
If you have a project with a specific timeline in mind, let’s talk about what’s realistic before committing to a schedule.