The short version. How long does custom software take to go live? Anyone who gives you a single number before understanding your operation is guessing. What actually decides the timeline is how much of your current process the software has to represent, how many other systems it has to talk to, and how much of your existing data has to move over cleanly. The one date worth asking for is not the finish date — it is the date of your first working demo, built on your own data.
This question matters because a vague timeline is exactly how a project doubles in cost and drags on for months while your team still runs the old way on the side. You are not being unreasonable for wanting a number. You are being unreasonable if you expect an honest one on day one, before anyone has looked at how your business actually runs.
There is no single number, and that is not evasion
A basic internal tool that replaces one spreadsheet is a different job from a dispatch and delivery system that has to talk to your accounting software, run on your drivers' phones, and survive a busy Monday morning without falling over. Both get called "custom software." Both take completely different amounts of time, need a different amount of testing, and carry a different amount of risk if something is missed. A developer who quotes you the same number for either one has not actually looked at your operation — they have looked at your budget.
What actually decides how long it takes
Three things move the timeline more than anything else, and none of them are about how fast anyone can type code.
How much of your current process the software has to represent. If your dispatch clerk currently makes ten small judgment calls a day that live only in her head, someone has to sit with her and turn those into rules the software can follow. That conversation takes as long as it takes — rushing it is how you end up with software nobody trusts.
How many other systems it has to talk to. A tool that stands alone is faster to build than one that has to stay in sync with your accounting software or a courier's tracking system. Every additional connection is a real piece of engineering, not a checkbox — see our system integration and API development work for what that actually involves. If your project needs three integrations, expect it to take meaningfully longer than one that needs none.
How much existing data has to move over cleanly. Years of stock records in a format nobody remembers the logic of, or customer data spread across three phones and a notebook, take real time to clean up before any software can use them. This step is invisible from the outside and is where timelines quietly slip.
The milestone that matters more than the finish date
Here is the honest fix: stop asking for the finish date, and ask for the first one instead. A working demo, built with your own data, is provided before you pay for the full build — not a mockup, not slides, an actual piece of the system doing something real with your actual stock list or your actual customer records. For a distributor, that might be your inventory reconciling against a real stock sheet. For a sales team, it might be your CRM holding your actual leads instead of a sample dataset.
That first milestone tells you more than any total-weeks estimate ever could. It tells you whether the developer actually understood your process, whether your team can look at it and recognise their own work in it, and whether the rest of the build is likely to go the same way. A vendor who cannot show you something real in a reasonable first stretch is not going to suddenly speed up later.
What to ask instead of "how long will this take?"
Ask what the first milestone is, and what it will actually do with your data — not what it will look like. Ask what happens to the schedule if that first milestone needs changes, because it usually does, and a vendor who has no answer for that has not planned past the pitch. Ask which of your systems the software has to connect to, because that is the single biggest lever on the total time, more than any other factor. And ask how the vendor handles it when someone on your side asks for a change mid-build, because that is when a vague plan turns into a slipped one.
None of this gets you a date you can put in a calendar today, and anyone who offers you one anyway is telling you what you want to hear, not what is true. What it gets you is a way to tell, within the first few weeks, whether the project is actually on track — instead of finding out three months in that it was never going to make the date you were quoted at the start.
If you are having this conversation with a vendor right now, the question is not "when will this be done." It is "what will I be able to see, with my own data, before I have paid for all of it — and how soon." That answer, unlike a finish date, is one an honest vendor can actually give you.