COBOXEvery stage exists to reduce uncertainty, not to start development faster.
Cobox runs one continuous process for every idea and every business — eight stages, each answering a specific set of questions before the next one begins. Below is what actually happens at each one.
Idea
Understand what problem or opportunity is actually being pursued, before anything is assumed about the solution.
Questions being answered
- —What's the problem, specifically?
- —Who feels it, and how often?
- —Why does this matter now rather than at any other time?
Activities
- —An unstructured conversation about the idea as it exists today
- —Writing the problem down in plain language, tested against your own explanation of it
Expected output
A clear statement of the problem, the customer and why now.
Decision before moving forward
Is there a clear enough problem statement to justify spending time on research?
Discover
Ground the idea in the real market, customer and economics it will have to operate inside.
Questions being answered
- —Who else already serves this problem, directly or indirectly?
- —What do real customers in this segment actually do today?
- —What would the unit economics need to look like to work?
Activities
- —Competitor and adjacent-market review
- —Early customer conversations
- —A first pass at rough unit economics
Expected output
A short research brief: market, customer and unit economics.
Decision before moving forward
Does the research support the idea as described, or does the idea need to change first?
Blueprint
Turn a validated direction into one structured, shared reference — model, MVP, technology direction, roadmap — before design or engineering starts.
Questions being answered
- —What's the business model, specifically — who pays, how much, how often?
- —What belongs in a first version, and what doesn't?
- —What's the realistic technology direction and timeline?
Activities
- —Business model definition
- —MVP scope drafted against the validated problem
- —Technology direction and a stage-by-stage roadmap
Expected output
The Business Blueprint: model, MVP, technology direction and roadmap.
Decision before moving forward
Is this worth building as scoped, or does the Blueprint need another pass before moving to validation?
Validate
Test the riskiest assumptions in the Blueprint with real signal, while that's still cheap to do.
Questions being answered
- —Which assumptions, if wrong, would break the whole idea?
- —What's the fastest, lowest-cost way to get a real answer on each one?
- —Do early users actually behave the way the plan assumes?
Activities
- —Ranking assumptions by risk and how untested each one is
- —Lightweight prototypes or a manual version of the service
- —Structured early-user or early-customer feedback
Expected output
Evidence for or against your riskiest assumptions, and a go / adjust / stop call.
Decision before moving forward
Go, adjust, or stop — made from evidence, before serious build investment.
Build
Bring product, brand and technology together as one working system, not a set of disconnected deliverables handed between teams.
Questions being answered
- —What does the MVP scope actually require, end to end?
- —Where do design and engineering decisions depend on each other?
- —What does 'done enough to launch' mean for this specific product?
Activities
- —Parallel design and engineering against the scoped plan
- —Regular, visible progress rather than a black box until 'finished'
- —Admin tooling and the operational basics, not just the customer-facing product
Expected output
A working product with its brand, platform and admin tooling.
Decision before moving forward
Is the product ready for real customers, or does it need another cycle before launch?
Launch
Take the business live on infrastructure built to support real customers, as a planned event rather than a deployment.
Questions being answered
- —Who sees this first, and how is their feedback captured?
- —What does 'working' look like in the first 24 hours?
- —Is the infrastructure monitored and ready for real load?
Activities
- —Production infrastructure and monitoring set up in advance
- —A defined first audience and launch sequence
- —Instrumentation, so usage — not guesses — informs what happens next
Expected output
A live business on production infrastructure, monitored and supported.
Decision before moving forward
Has launch gone to plan, and what does day-one usage say about what to prioritise first?
Operate
Keep the business running on systems and automation, not manual firefighting by whoever's available.
Questions being answered
- —Which day-to-day tasks are still manual and repetitive?
- —Where is support or operations depending on one person?
- —What needs to be automated first for the biggest return?
Activities
- —Workflow and operational tooling put in place
- —Automation applied to the highest-frequency manual tasks
- —Support processes defined and handed off properly
Expected output
Day-to-day workflows, automation and support running without firefighting.
Decision before moving forward
Is the business running smoothly enough to shift attention from operating it to growing it?
Grow
Use real data and iteration to decide what the business needs next, rather than opinion or whoever asked most recently.
Questions being answered
- —What does usage actually show, versus what was assumed at launch?
- —Where is the biggest lever for growth right now?
- —What capability needs to be added next, and why?
Activities
- —Analytics review on a regular cadence
- —A prioritised improvement backlog, ranked by evidence
- —New capability scoped and added deliberately, not reactively
Expected output
Reporting, a prioritised improvement backlog and the next capabilities to add.
Decision before moving forward
What's next on the roadmap, and does it need its own Blueprint and Validate pass first?
Where you are decides what happens next
The process is the same — where it starts for you depends on whether you’re starting something new, fixing how an existing business runs, or scaling one that already works.