Your actual numbers
Delivered volume from your CDN logs rather than an estimate, catalogue size, peak concurrency, and what you run today. Discovery cannot produce an architecture from adjectives.
From signature to live, and what we need from you each week
Stage by stage, with the week count on each one and the thing your side has to produce before it can start. Every week figure is indicative; there is no total headline number on this page, because the total is decided by the two stages that depend on you.
Why there is no single number at the top of this page
Every vendor timeline you have read opens with a total — eight weeks, twelve weeks, ninety days. It is the most quoted and least reliable figure in this industry, because the two stages that decide it are the two the vendor does not control: how fast hardware or cloud accounts appear, and how fast content and rights information arrive.
So the stages are listed with their own indicative durations and their own dependency, and the total is whatever your side of that table adds up to. An operator with hardware racked and a catalogue already described moves through this quickly. One waiting on procurement does not, and no amount of engineering changes that.
What is genuinely fixed is the order. Nothing downstream of infrastructure can start before it exists, and nothing downstream of the pipeline can be tested before content flows through it. A plan that runs these in parallel is a plan that discovers the dependency later.
The stages
Durations are per stage, and several overlap. Read the dependency column first — it is the one that moves dates.
| Stage | Duration | What has to be true before it starts | Status |
|---|---|---|---|
| Discovery and architecture | 1–2 weeks | Signature, and access to whoever knows your current numbers | Indicative — confirmed in the agreement |
| Infrastructure stand-up | 2–4 weeks | Hardware racked and reachable, or cloud accounts and quotas granted | Indicative — confirmed in the agreement |
| Pipeline and delivery | 2–3 weeks | Infrastructure live; transit or peering arranged | Indicative — confirmed in the agreement |
| Catalogue and CMS | 2–4 weeks | Content accessible and its metadata in a form somebody can describe | Indicative — confirmed in the agreement |
| Applications and stores | 3–5 weeks | Brand assets, and your own developer accounts opened | Indicative — confirmed in the agreement |
| Billing and payments | 1–2 weeks | Merchant credentials issued to you by the gateway | Indicative — confirmed in the agreement |
| Migration, where there is one | 2–6 weeks | An export from the incumbent, and a decision on what moves | Indicative — confirmed in the agreement |
| Hardening and launch rehearsal | 1–2 weeks | Everything above, running together, with real content | Indicative — confirmed in the agreement |
What we need from you, in the order we need it
None of it is unusual. All of it is on the critical path, which is the part worth knowing in week one rather than week five.
Infrastructure or accounts
Hardware racked, powered and reachable, or cloud accounts with the quotas already raised. This is the single most common cause of a date moving, and it moves before anybody writes code.
Content and its metadata
Access to the masters and to whatever describes them. A catalogue whose metadata lives in one person's memory is a real risk to a launch date and it is better named early.
Brand and store accounts
Identity assets, and developer accounts opened in your own name on each store. Yours, not ours — which is the point, and it takes your legal entity to do.
Merchant credentials
Issued to you by the gateway. The integration is built and waiting; what it waits on is an account only you can hold.
One person who can decide
The most valuable input on this list. A deployment with a single empowered decision-maker moves at the pace of the work; one that routes every choice through a committee moves at the pace of the committee.
The four things that actually move the date
Procurement. Hardware that has not been ordered by the time discovery ends is the most common reason a launch slips, and it is invisible in a plan that starts counting at signature. If the estate is on your own metal, the order is placed in week one or the date is fiction.
Metadata. Encoding a catalogue is fast and describing one is not. Titles, synopses, artwork, categories, rights windows and language tracks are a content operation, and where that operation does not exist yet it is the longest pole on this page.
Store review. Publishing under your own developer account is the right structure and it means your submission sits in the same queue as everyone else's. It is not estimable and it is not ours; the mitigation is submitting early with a placeholder build, not promising a date.
Scope arriving late. A capability discovered in week six — a payment rail, a DRM requirement, an app platform — does not slot into the remaining weeks. The spec sheet exists so those are found in week zero, and reading it before signature is worth more than any clause in the agreement.
Questions
So how long does it take in total?
The stages above add up, several overlap, and the answer depends on procurement and metadata rather than on engineering. That is why no total is printed here. Discovery produces a dated plan against your actual constraints in the first fortnight, and that plan is the one worth holding us to.
Can we launch on web first and add apps later?
Yes, and it is often the right sequencing, because web has no store review in front of it. It gets a real service in front of an audience while the applications are still in a queue.
What is the earliest we could see it working?
The platform is already running a live consumer service, so the demonstration does not wait on your deployment at all. What waits on your deployment is your catalogue on your infrastructure.
Why is 'one person who can decide' on the list of inputs?
Because it is the input that most reliably separates deployments that hold their date from those that do not, and leaving it off would be polite rather than useful.
Have a launch date already?
Then the useful conversation is backwards from it. Tell us the date and what you have in place, and we will tell you honestly whether it holds.