Investigating timelines
How long does an internal tool take to build?
A focused internal tool—one workflow, a handful of integrations, a clear owner—moves through four phases: discovery, design, build, and refine. How long each phase takes depends less on the engineering than on scope, integration readiness, data quality, and how available your people are. Anyone who quotes you a firm number of weeks before looking at those things is quoting a brochure, not your project.
What we can give you honestly is the shape of the work, what speeds it up, what slows it down, and where a real schedule comes from: the Workflow Opportunity Review, which turns “it depends” into a defined scope with dates attached.
The four phases
- 01
Discovery
Map the workflow as it actually runs: who touches it, where it breaks, what the edge cases are, which systems it must talk to. Discovery is short by design and is where scope—and therefore timeline—is really set.
- 02
Design
The screens, the rules, the permission model, and the integration approach, reviewed with the people who will use them. Catching a wrong assumption here costs a meeting; catching it in the build costs weeks.
- 03
Build
Working software in stages, not a months-long blackout followed by a reveal. Your team sees and reacts to real slices of the system as they are finished, which keeps the build honest.
- 04
Refine
Real users, real orders, real exceptions. The first weeks of use always teach something the map missed, and this phase exists to absorb that—adjusting the workflow until it fits the operation instead of the other way around.
Skipping phases does not shorten this list—it renames the delays. A project that skips discovery discovers its scope during the build. A project that skips refine discovers its misfits in production, in front of customers.
What actually decides the timeline
Scope discipline
One workflow beats three, every time. The fastest projects are the ones that resist “while we are at it.” A second phase decided with evidence ships sooner than a first phase bloated with speculation—this is the same discipline that controls cost.
Integration readiness
Does your ERP have a real API, and can we get credentials this month? Is there documentation, or one consultant who answers email on Thursdays? Integration is the most common source of timeline variance, and most of it is discoverable before the build starts.
Data quality
Clean customer and item data keeps the build about features. Migrating inconsistent history or reverse-engineering logic from spreadsheet formulas adds real work—worth doing, but it has to be scheduled, not discovered.
Your team’s availability
The builds that stall are waiting on decisions, not code. An owner who can answer “should a credit hold block shipment?” in a day keeps the project moving; routing that question through a monthly committee does not. Budget a few hours a week from the people who know the work.
Process readiness
If the underlying process is still disputed, that conversation happens in discovery or it happens mid-build, at triple the price. Redesign first, automate second applies to timelines as much as to quality.
Common mistakes that stretch timelines
- Waiting for the perfect spec before starting. Specs written without software to react to are fiction; start with a good map and let the staged build correct it.
- Disappearing during the build, then rejecting the result at the end. The weekly hour is the cheapest insurance in the whole project.
- Adding scope mid-build. Every “quick addition” is a scope conversation; batch them into phase two instead.
- Underestimating access lead time. API credentials, VPN access, and vendor approvals have their own calendars—start those requests in week one.
- Treating the refine phase as optional polish. It is where the system becomes something your operation actually trusts.
Frequently asked questions
- Somewhat, by narrowing scope—not by skipping phases. A smaller first release with one workflow and one integration moves fast. Compressing discovery and design does not save time; it moves the unanswered questions into the build, where they are more expensive to answer.
- Because the honest range depends on your systems and your data, not just our work. An integration that takes days against a modern API takes much longer against a legacy system with no documentation. Anyone quoting a firm timeline before seeing those things is quoting their marketing, not your project. The Workflow Opportunity Review turns the range into a real schedule.
- The total, sometimes slightly. The time to first value, much shorter. A phased approach gets one workflow into daily use while the rest is still being scoped, so the operation starts benefiting early and every later phase is planned with evidence from a running system. One giant build delivers everything at once—at the end, if nothing slipped.
- One empowered decision-maker and access to the people who do the work—an hour or two a week from the right ops person is usually enough. The builds that run long are almost never waiting on engineering; they are waiting on decisions and access.
- Early. The build phase delivers working software in stages, and the refine phase assumes real users with real orders. You should never wait months for a big reveal—the first working slice should be in front of your team while the rest is still being built.
- The system runs, your team owns the daily operation, and further changes are handled as small follow-on work. Some clients keep Praxyt on for maintenance and iteration; others take the system in-house. Either way, handover includes documentation, not just code.
Keep investigating
- How Much Does Custom Internal Software Cost?The four factors that drive cost—and how a fixed proposal works.
- How It WorksPraxyt’s engagement model, from first conversation to running system.
- How to Find the Workflow Worth Automating FirstChoosing a tight first build is the biggest timeline control there is.
- Workflow Automation vs. Process RedesignWhy redesign belongs in discovery, not mid-build.
- Build vs. BuyWhen buying a product beats waiting for any build.
- Workflow ReviewWhere a real schedule with dates actually comes from.
Want dates instead of ranges?
A Workflow Review ends with a defined scope and a build schedule you can plan around.