The budget committee wants a go-live date before it signs. The data sits in four systems, two of them without API documentation. Nobody has yet decided who can see which region's records.
Across more than 200 internal tools, our median time to ship is 5 weeks. The median hides a wide spread, and the spread has little to do with how fast the code gets written. It comes from four things that are mostly settled before the first screen exists: the data, the integrations, the permissions, and the review process.
What sets the timeline
Data readiness
Documented APIs and stable database schemas let a connection go live in hours. Undocumented endpoints, or two older systems that disagree about what a customer is, take days of mapping before any interface work starts. When several systems are being brought into one tool, the data has to be mapped in full before design begins.
Integrations
Each integration adds connection work, authentication, error handling, and testing. The effort also compounds, because every new source multiplies the failure cases the tool must handle.
On an edtech fraud scoring system, the tool pulled from five external sources every day. Batching 10,000 schools into runs of 1,000, so the daily job would not saturate the queries, took a full week of engineering on its own.
Permissions
Standard role-based access is a modest piece of work. Visibility split by region, or many distinct user roles, takes considerably longer to configure and validate. Access shapes the data model, so it costs far less to settle first than to retrofit.
Review and sign-off
IT security approvals, compliance reviews, and access requests run on their own calendars. A tool can be finished and still wait for a review slot. The teams that hold their dates book those reviews at the start.
The shape of a build
The phases are the same at every size. Only their length changes.
Mapping. Who uses the tool, where each piece of data lives, which systems it touches, and who may see and change what.
Build in weekly cycles. A working surface every Friday, shown to the people who will use it, so their corrections arrive while they are cheap.
Permission testing and rollout. Every role tested against real records, then a staged release to the first team.
A single dashboard on one clean data source sits at the short end. A platform that joins several systems, with weekly playbacks across teams, sits in the middle. A platform spanning several regions and regulators, with phased delivery market by market, sits at the long end. The pre-build checklist in what to settle before the first query is the mapping phase written down.
Where regulation adds time
Builds for regulated teams in the UK and EU carry more structured mapping before the build. GDPR, local data residency rules, and workflows in several languages cannot be added after launch. They shape the data model and the row-level security from the first week.
A regulated financial institution operating in 13 markets needed approvals run centrally, while each market's creative data stayed local. Setting those permission boundaries up front added two weeks to the first phase. It also avoided about a month of compliance rework later. The security and compliance checklist covers the controls reviewers ask for.
New build or migration
Replacing an existing tool usually takes longer than starting fresh, and the reason is inherited decisions. Undocumented logic, inconsistent data, and habits built around manual workarounds all need mapping before anything is replaced.
We treat a migration as a new build informed by what the old one revealed. Patching logic nobody can explain tends to carry its problems forward. The old tool still has value: it shows, in working screens, what the team actually relies on.
Why an estimate needs the mapping first
A range is possible before mapping. A committed week count is not. A team with documented APIs, clean schemas, and simple permissions moves faster than one with six older systems and regional compliance rules. Only the mapping shows which one you are.
The delays that surprise people are almost always data access: an undocumented API, schemas that disagree, an IT approval nobody requested. Mapping in the first week surfaces them while they are still small. Found in week eight, the same problem moves the date.
Who builds affects the timeline too. A team that has shipped many Retool tools starts from proven patterns for queries, concurrent users, and permission models. A team new to the platform learns those patterns on the first build. Build in-house or hire a Retool agency weighs that choice.
Our view
Ask for the committed date after the mapping, because what moves a date only shows once the data, integrations, and permissions are on paper. Then hold the build to a working surface every Friday, so the product owner sees progress and makes the trade-offs in real time. A date set that way is one the team can defend.
