In this article (7)
The question behind the question
Nobody asks about timelines out of curiosity. They ask because something depends on it: a season, a contract, a system being switched off. Say that out loud at the first conversation, because a fixed external date changes what should be built, not just how fast. An honest answer to "how long" always begins with questions rather than a number, and a supplier who gives you a figure before understanding the deadline is guessing at both.
What actually drives the schedule
Four things, in roughly this order. How many external systems it has to talk to, because every integration is a dependency on someone else's documentation and goodwill. How clear the rules are, because undefined logic gets defined during the build. How many people have to approve, since a decision routed through a committee costs days each time. And how clean the existing data is, which is the one clients consistently underestimate. Feature count matters far less than any of these.
Discovery is not the slow part, it is the fast part
Two to four weeks spent mapping the process, the data and the rules before anyone writes code looks like delay and reliably saves more than it costs. The alternative is discovering in month three that the approval process has an exception nobody mentioned, which means rework rather than progress. Teams who skipped this are the ones who end up recreating a bad process faithfully in software and wondering why nobody uses it.
Ship the first version smaller than you want
The fastest route to something working is to cut the scope of the first release hard and add to it once real people are using it. This is not a compromise, it is how you find out which half of the specification nobody needed. Deciding what goes in that first version is the whole skill, and scoping an MVP properly is a different exercise from writing a wish list and removing items until it fits.
Talk to us about a build on WhatsAppBudget for the part after it works
Most plans stop at the point the software functions, which is roughly two-thirds of the way through. What remains is testing against real data, migrating what exists, training the people who will use it, and running the old and new systems together for a period. Skipping the parallel run is how companies discover a gap on the day they can least afford it, which is the central risk when replacing a legacy system.
Reading an estimate honestly
A single number with no assumptions attached is a sales figure. A real estimate states what it assumes, names what could move it, and breaks the work into stages that can be reassessed. Ask what would make this take twice as long; a partner will answer immediately and specifically, because they have been there. Silence or reassurance to that question is the most reliable warning sign available, and it matters more than any credential when choosing who builds it.
Where clients cost themselves weeks
The delays inside your control are predictable. Slow answers to questions that block work. Feedback arriving as five separate opinions with no decision. New requirements described as clarifications. Data promised in week two and delivered in week seven. Name one decision-maker, agree a response time, and route changes through a written note rather than a conversation. That discipline shortens a project more reliably than any tooling, and it is worth agreeing before the platform work starts rather than after it slips.
Written by
Idennex
Strategy-first agency, Istanbul