There is no single answer to "how long", but there are dependable ranges. This page breaks a platform build into six stages, with numbers aggregated from roughly twenty projects. Builds that fall outside the ranges almost always hit trouble in requirements or data — rarely in code.

The headline numbers

Standard package: 6-8 weeks from signature to launch. Custom build: 13-22 weeks. Most of the difference sits in the development stage; the rest differ only marginally.

Six stages, and how long each takes

Which stage slips first

Integration, every single time. The plan says two weeks; the average reality is five. The blockers are boringly consistent: the partner's API documentation is two revisions stale, the sandbox cannot reproduce edge cases, the named counterpart answers in days. The fix is equally boring and it works — lock the document version and the counterpart's name before the schedule is signed, and buffer every dependency-heavy stage at twice its estimate. The full preparation checklist lives in the API integration guide.

Second place goes to requirements. The week on paper quietly becomes weeks of mid-build changes, and each change is debt collected with interest during development. A requirements freeze written into the contract outperforms any project-management tooling we have seen.

Converting timeline into platform build cost

Person-months make it concrete. A mid-sized custom platform lands between 12 and 20 person-months. Multiply by your blended rate: every month of slip costs a full month of team, before you count the market window you missed. There are only three honest ways to compress a schedule. Freeze requirements. Replace custom features with standard modules wherever the flow is not truly different. Prepare content and data before development ends, not after. None of these is clever; all of them are hard to execute — which is exactly why they work. For where the custom line actually sits, read the selection boundary.

Two patterns worth copying

First, parallel content tracks. While engineering builds the skeleton, the content team prepares data and materials on a staging environment. Projects that did this cut two to three weeks with zero engineering change. Second, weekly demos. A two-week acceptance rhythm at the end always stretches; a weekly demo forces problems to surface while they are still cheap to fix.

A word on where the standard package's speed actually comes from: mature modular foundations. Accounts, content and the operations console are ready-made and run on install. Its two slow spots are brand work — the deeper the interface changes, the closer the timeline moves toward a custom build — and data migration, where a heavy legacy dataset can consume a week on its own. When you evaluate a standard package, sort your requirements into two piles: covered by standard modules, and must be custom. Past about 30% in the second pile, the timeline advantage is gone — the same logic as the boundary criteria in the selection page.

One scheduling rule

Add a 25% buffer across the whole plan. A buffer is not permission to drift — it absorbs integration surprises, data cleanup and public holidays. Schedules have tightened this year: clients ask for weeks, not months. The background is in this note on changing demand. The rest of the solutions track starts at the solution overview.