How we scope a platform build in 72 hours.
First call Monday. Signed SoW Thursday. Here is the exact process we run for platform engagements, what we need from the operator, and what ships with the proposal.
Platform engagements are the hardest to scope well. They are long, expensive, and the cost of a bad scope compounds through every milestone. Our commitment to operators who apply for a platform build: 72 hours from first call to signed SoW, or we refund the scoping fee. We have missed the window twice in 2026, both times because the operator needed more time on their end. We have never missed it because of our process.
The 72-hour window is not a marketing move. It is an operating constraint. Platform scopes rot fast. The operator's context, the team's alignment, the urgency that made them apply in the first place, all decay after a week. A scope produced in 72 hours lands while the operator still remembers why they called us. A scope produced in three weeks lands after the priority has shifted.
Day zero, before the call. We send a 12-question intake form. Nothing exotic. Company, revenue, team size, current stack, the workflow that hurts most, the three things the operator would ship first if money and time were not constraints, the three failure modes they already know about, and a budget range. We read it before the call. Operators who fill it out with specifics get a faster, sharper scope. Operators who write 'we will explain on the call' get a discovery call instead of a scoping call, and the 72-hour clock resets.
Hour zero to two. First call. 90 minutes, one builder and one operator-side decision maker minimum. No slides on our end. We map the current workflow on a shared whiteboard, mark the arrows where work transfers hands, and circle the arrows that take the longest. The builder asks the questions. The account layer stays out. By the end of the call, we have an operator intent statement, a workflow map, and a first pass at the failure modes the build has to survive.
Hour two to twenty-four. The architecture pass. We produce three artifacts. A workflow diagram showing the before state and the after state, with explicit arrows for every data handoff. A system architecture sketch naming the services we would use, the integrations we would write, and the custom logic we would own. A risk register listing the top five things that could go wrong, ranked by probability and severity. This is the 24-hour artifact dump. Operators get it in email by end of day one.
Hour twenty-four to forty-eight. The operator has 24 hours to respond. In practice most come back inside 8 hours with a handful of corrections, usually around integrations we did not know existed or constraints we did not catch. We fold them in. If the operator goes quiet for more than 24 hours, the clock pauses. We have learned not to push. Platform scopes die when the operator feels rushed.
Hour forty-eight to sixty. Scope doc and SoW draft. The scope doc is the load-bearing artifact. It specifies exactly what ships, what does not, what counts as 'done' for each milestone, what the acceptance criteria look like, and what the change request process is. Our platform scope docs run 12 to 20 pages, never longer. If a scope needs more than 20 pages to be clear, it is not clear enough. The SoW draft references the scope doc and adds terms, milestones, payment schedule, IP, and termination.
Hour sixty to seventy-two. Review call. One hour, both sides walk through the scope doc page by page. We red-line it live. The operator leaves the call with a scope they wrote as much as we did. Signed SoW goes out within 90 minutes of that call ending. Most operators sign inside the first 24 hours after the call. The ones who need board approval or a partner sign-off sign within the week.
What we ship with the proposal. The workflow diagram. The architecture sketch. The risk register. The scope doc. The SoW. A milestone map with specific dates. A payment schedule. A list of what we need from the operator at each milestone, so the engagement does not stall on 'we are waiting on access.' A single point of contact on our end, named, with their calendar link.
What we ask for upfront. API credentials or sandbox access for every integration we named in the architecture. A Slack channel or equivalent so we are not living in email. A decision maker who can sign off on scope changes inside 48 hours. A point person on the operator's team who owns the build from their side, not a committee. If the operator cannot produce a single owner, the build will miss its dates. Every time.
What we price. Platform builds run $80,000 to $450,000 at Michai, scoped in phases. Phase one is discovery and architecture, usually $15,000 to $25,000 and two to three weeks. Phase two is the core build, usually 8 to 16 weeks depending on complexity. Phase three is rollout, integrations, and operator enablement, usually two to four weeks. Each phase has its own scope doc, its own acceptance criteria, and a sign-off gate before the next phase starts.
Why the 72-hour commitment matters. Platform engagements are decisions that lock the operator's team for a quarter or longer. The scoping process needs to be as crisp as the build is going to be. If we cannot scope a platform in 72 hours, we are not ready to build it in a quarter. The scoping window is our own first acceptance test. We fail it, we do not take the work.
If you are weighing a platform build in 2026, apply on Monday and plan your week around the scope being ready Thursday. We will either have an SoW in your inbox or a written explanation of why we are not the right team. Either outcome saves you the three months most operators lose to a bad scope.