The honest answer is a range, and the range depends on what you are building. Here is what it looks like across the kinds of projects we take on, what moves a project toward the short or long end, and the one decision that matters more than any estimate.
Typical timelines by type of project
These are the ranges we plan against. They cover a strong first release, not everything you could ever want.
- A narrow internal tool or utility, the kind that replaces a spreadsheet: one to two months.
- A prototype or demo real enough to put in front of users or a board: one to three months.
- An AI assistant or automation wired into systems you already run: six to twelve weeks.
- A mobile app that complements a web system you already have: three to six months.
- An integration and reporting layer across systems that do not talk: two to five months.
- A basic new application or a rewrite of an existing product: three to seven months.
- A customer-facing product with a polished interface and a complete first release: four to nine months.
- Modernizing or taking over a system you already run: three to nine months for the first meaningful release, then ongoing.
- A complex, multi-phase application or a custom ERP: a first phase in six to twelve months, with the full system delivered in phases over one to two years.
The pricing page shows these alongside typical budgets, because schedule and budget move together.
What actually drives the schedule
Size matters less than people expect. These matter more.
- How many systems it touches. Every integration is a conversation with someone else’s software, and the older the system, the longer the conversation.
- How many kinds of users it has. A tool for one team is one set of screens. A product for customers, staff, and partners is three.
- How clean the data is. If the first month is spent finding out what the numbers actually mean, the schedule moves.
- How fast decisions get made. A team that can get a yes or no inside a day moves twice as fast as one waiting a week for a committee.
- Compliance scope. If an auditor will read the system, the controls and the testing are a real share of the schedule and need to be planned, not bolted on.
Why we plan for a first release, not the whole thing
The most reliable way to blow a schedule is to try to ship everything at once. The first release should solve the most valuable part of the problem, be in use, and be earning before the next phase starts. It is cheaper, it is faster, and what you learn from real users changes what the second phase should be.
This is also why we do not quote a timeline on the first call. The planning step that starts every new build, a VDP Sprint, takes three to four weeks and produces the scope, the cost, and the schedule for the first release. For a system you already run, a System Evaluation does the same in one to four weeks. The schedule we give you after that step is one we can stand behind.
How to shorten it
Adding people rarely helps, and past a point it slows things down. What does help:
- Decide fast. Name one person who can say yes.
- Give access on day one: systems, data, and the people who use them.
- Cut the first release to what matters. Everything else goes in the next phase.
- Keep the people who know the work in the room. Requirements discovered in month four cost the most.
If you want to know where your project falls, here is how getting started works. The first conversation is thirty minutes, and you will leave it with a better sense of the range than any article can give you.