The most common lie in software development is the timeline.
Not malicious lying. Optimistic lying. The kind where everyone involved genuinely believes the 8-week estimate on the day it's given, and genuinely doesn't understand why they're on Week 22 with no launch in sight.
I've been building web applications in Singapore for over a decade. Here's the honest version of how long things take.
Real Timelines by Project Type
Landing page / marketing site (up to 10 pages)
Quote: 2–3 weeks. Reality: 2–3 weeks — if content is ready.
The wildcard: content. Most clients underestimate how long it takes to write and approve copy, source images, and get internal sign-off. Content delays extend landing page projects more than technical delays.
Business brochure site (10–30 pages)
Quote: 4–6 weeks. Reality: 6–10 weeks.
Extended by: content gathering, stakeholder feedback rounds, brand asset issues (low-res logos, inconsistent colours), and late-breaking page requests.
Simple web application (auth, database, 1 core workflow)
Quote: 6–8 weeks. Reality: 8–14 weeks.
Extended by: unclear requirements discovered during build, integration delays with third-party services, QA finding more issues than expected.
Medium complexity web app (auth, multiple workflows, 2–4 integrations)
Quote: 10–14 weeks. Reality: 14–22 weeks.
Extended by: third-party API issues (documentation inaccurate, sandbox behaving differently from production), scope additions, design feedback requiring significant rework.
Complex platform (multi-role, multiple integrations, real-time features)
Quote: 16–24 weeks. Reality: 24–40 weeks.
Extended by: all of the above, plus organisational complexity (multiple approvers, conflicting requirements from different departments), performance issues discovered under load testing.
A pattern is visible: actual duration is typically 1.3–1.8x the quoted duration. This isn't fraud — it's the consistent underestimation of unknowns in software development.
What Actually Extends Timelines
In order of frequency:
1. Content not ready
The single most common project delay. The development team is waiting for copy, images, data, or decisions. Content delays development without any technical problem at all. Budget the same time for content production as you budget for development.
2. Requirements discovered during build
"Oh, I forgot — we also need it to do X." Every major feature added after sign-off extends the timeline proportionally and disrupts work in progress. Incomplete requirements discovery is a planning failure, not a development failure.
3. Third-party integration surprises
The payment gateway sandbox behaves differently from production. The API documentation is outdated. The webhook doesn't fire in the expected format. Third-party integrations consistently take 1.5–2x their estimated time. Build this buffer in at the planning stage.
4. Feedback and approval delays
Design presented Monday. Feedback received the following Thursday. One round of revisions, presented the following Monday. Two more days for approval. That's 2 weeks for one feedback cycle. Multiply across 4–6 rounds and the project slips by weeks.
5. Scope additions
Feature creep. New requests mid-build that seem small but disrupt the architecture. "Can we just add X?" is the most expensive sentence in software development.
How to Scope for Realistic Delivery
Add a content buffer — Add 2–4 weeks to any project timeline for content preparation if you don't have content ready at the time of signing. This is not negotiable padding; it's realistic planning.
Define the scope with negative space — Describe not only what's in scope but what's explicitly out of scope. "Version 1 will not include: reporting module, API for third-party access, mobile app." Write it down. Sign it.
Build third-party integration buffers — Add 100% time buffer to every third-party integration estimate. If the integration estimate is 2 weeks, budget 4 weeks. If you finish in 2 weeks, you've saved time. If it takes 4, you haven't broken the project.
Agree on a feedback turnaround SLA — "All feedback to be provided within 3 business days of presentation." This is not bureaucratic; it's the mechanism for keeping the project on schedule.
Freeze scope after Week 2 — After requirements are locked and confirmed, no new features enter the current sprint. New ideas go into a backlog for the next phase. The only exceptions are critical bug fixes or blocking issues.
Fixed Price vs Time and Materials
This choice affects how schedule risk is allocated:
Fixed price — The developer takes schedule risk. They quote a date and a cost; anything over budget is their problem. Works well when requirements are very well-defined and stable. Works poorly when requirements are uncertain — either the quote is padded massively to cover unknowns, or the project ends in a dispute when the scope turns out larger than expected.
Time and materials (T&M) — The client takes schedule risk. You pay for time spent. Works well when requirements will evolve (almost all complex projects). Works poorly when the client has a fixed budget and no ceiling — the project can run without bound.
Capped T&M — Hybrid. T&M with a ceiling. The developer tracks hours, the client pays for actual time, but the project is capped at a maximum. Scope changes are discussed before being executed, with impact on the cap agreed upfront. This is the model NICKTUNG uses for most projects — it aligns incentives and handles reality better than pure fixed-price on complex work.
The Question Every Client Should Ask
When any developer quotes your project, ask: "What are the top 3 assumptions in this timeline that could prove wrong, and what happens to the timeline if they do?"
A developer who can answer that question clearly — who has thought through the risks and is honest about uncertainty — is far more likely to deliver than one who gives you a clean timeline with no caveats.
Uncertainties don't disappear when they're not mentioned in the proposal. They become surprises on Week 14.
Planning a web app build and want an honest timeline estimate? We'll tell you what we actually think, including the risks, not just the number that wins the project.