Ask three vendors how long a project will take and you will get three different answers, usually expressed as a range wide enough to be useless: “three to nine months”. That range is not wrong, but it is not a plan either. If you are the one signing off the budget and the launch date, you need to know which variables push a project towards the short end or the long end, and which parts of a vendor’s estimate are guesses dressed up as numbers.
We are not going to give you a table of “simple app: 8 weeks, complex app: 12 months” and call it advice. Those tables exist everywhere and they do not transfer to your project, because the thing that actually moves a timeline is rarely the feature list. It is a handful of structural factors that are easy to miss when you are looking at a proposal.
What actually drives the schedule
The number of systems you need to talk to
Every external integration adds time that has nothing to do with how good your development team is: getting API access, waiting for the other vendor’s sandbox environment, discovering their documentation is out of date, handling rate limits you did not know existed, and testing failure modes for a system you do not control. A project with no integrations and one with three integrations are not the same project scaled up a bit; they carry different risk profiles entirely. If your software needs to connect to accounting software, a payment provider, an existing CRM, or hardware in the field, ask early who owns access to each of those systems and how quickly they respond.
How firm the requirements actually are
“We know roughly what we want” is the single biggest source of timeline slippage we see, and it is rarely anyone’s fault. Requirements that change after development has started do not just cost the time to rebuild the changed part; they cost the time to figure out what else depends on it. A short, deliberate discovery phase before a single line of code is written is what converts “roughly” into something a team can actually build against. Skipping it feels like it saves time. It usually spends more of it later, in a less predictable way.
Who has to say yes, and how often
A review cycle that needs sign-off from one product owner takes days. One that needs sign-off from a product owner, a compliance team, and an external stakeholder who is only in the office two days a week takes weeks, and it repeats at every milestone. This is not a development cost, but it sits directly on the critical path, and it is almost never included in a vendor’s estimate because the vendor does not control your organisation’s decision-making speed. Map out who needs to approve what before the project starts, not during it.
What “done” is required to mean
A feature that works on a developer’s laptop and a feature that has been tested against real data volumes, checked for accessibility, reviewed for security, and verified to behave correctly when a third-party API times out are different amounts of work, even though they produce the same demo. If your product touches personal data, financial transactions, or regulated processes, the testing and compliance work is not an add-on at the end; it needs to be built into the estimate from the start, and it is one of the most common reasons a “finished” project takes another six weeks to actually ship.
Team size, and the limit on adding more people
A vendor can sometimes compress a timeline by adding people, but only up to a point, and only for work that genuinely splits into independent pieces. Architecture decisions, data model design, and anything with a single point of integration do not get faster with more people on them; they get slower, because more people now need to agree and stay in sync. If a vendor’s response to “can we go faster” is simply “we will add two more developers”, ask which specific parts of the work that actually helps.
Where the estimate is most likely to be wrong
Two phases get underestimated more often than any others, in our experience: the beginning and the end.
At the start, getting access sorted — cloud accounts, domain control, existing codebases, third-party credentials, a working local environment — regularly takes longer than anyone expects, particularly when the client side involves IT policies or procurement processes that were not designed with a software project in mind. At the end, the gap between “the features work” and “this is ready to put in front of real users” absorbs testing, bug fixes, data migration, deployment pipeline work, and the inevitable small things that only show up once real data hits the system. A timeline that allocates almost nothing to either end is optimistic by construction.
Fixed price and time and materials answer different questions
A fixed-price quote gives you a confident-sounding date, but that confidence is only as good as how well the requirements were nailed down before the quote was written. If they were not nailed down, the date holds only until the first change request, at which point you are negotiating a new date and a new price at the same time. Time and materials does not pretend to give you certainty it does not have, but it puts more of the schedule risk on you, which means it only works if you have someone tracking progress against the plan regularly enough to catch drift early. Neither approach removes the underlying uncertainty; they just decide who carries it and when it becomes visible.
Questions worth asking before you accept a date
- Does the estimate include time for testing and deployment, or does it stop at “development complete”?
- How many external systems or teams does this project depend on, and has anyone confirmed their response times?
- Who on your side needs to approve what, and have you scheduled that capacity, not just theirs?
- Is there a discovery phase, and does it produce something concrete — a specification, wireframes, a data model — that the build phase is estimated against?
- What happens to the date if requirements change after week two? Is that handled by contract, or only by conversation?
- If the project touches regulated data, has compliance and security review been costed as its own line, not folded into “testing”?
A vendor who can answer these without hesitation has probably built the estimate on something more solid than experience with similar-sounding projects. A vendor who cannot is not necessarily being dishonest, but their date is a guess, and you should budget and communicate internally as if it were one.