Help for founders and product teams building something new
Situations we help with when you are building something new. Your product, constraints and evidence decide the next step. We do not apply a generic template.
These are patterns to recognise, not a script. Your context, constraints and evidence decide what we actually do together.
Discuss your situationAI-native product works for a few users, not at scale
Early success does not yet prove the foundation will hold under real use.
Design and build
Explore situation →02AI and infrastructure cost grows faster than revenue
Cost climbs with every user or model call, without a clear plan for where it stops.
Design and build
Explore situation →03Founder or investor needs a reliability and cost plan
The idea is clear enough to fund discovery; the foundation for real use is not.
Design and build
Explore situation →04Proof of concept needs a path to production
The PoC worked. Production readiness, ownership and cost are still open.
Design and build
Explore situation →Illustrative situations
Move from symptoms to a clear next step.
AI-native product works for a few users, not at scale
A new or AI-native product works in a demo or for early users, but it is not clear whether it will stay reliable, fast and available when demand grows.
Typically fits: Design and build
The product impresses a small group. Growth, investor review or a first enterprise customer raises questions about reliability and performance.
Which parts of the design will break first, and what "ready to grow" means for this product and audience.
Critical journeys, architecture assumptions, data and AI usage paths, cost trajectory and what a production-ready foundation must include.
What to strengthen first so the product can grow without becoming a fragile demo at larger scale.
Name the journeys that must hold, the risks that matter first, and a lean plan the founder or investor can decide on.
Technical view
- Demo success often hides capacity, data and integration assumptions that only appear when concurrent use and real workloads arrive.
- Define the foundation pillars for reliability and cost before rushing a "perfect full product".
AI and infrastructure cost grows faster than revenue
Usage cost for infrastructure or AI rises quickly, while revenue or product value does not keep pace. It is unclear what is necessary and what is waste.
Typically fits: Design and build
Bills rise with usage. Leadership cannot see which features or paths drive the cost, or what a sustainable unit economics picture looks like.
Whether the architecture forces expensive paths by default, and which choices are still reversible.
Cost drivers across infrastructure and AI usage, hot paths, alternatives that preserve the product value, and trade-offs over time.
What to retain, simplify, defer or redesign so cost stays aligned with growth.
Map the few paths that dominate cost and agree what must stay versus what can change before the next spend commitment.
Technical view
- Cost design belongs in the foundation: where spend will go, whether AI is needed everywhere, and what a database or service choice costs later.
- Separate must-have paths from expensive defaults before locking the next architecture or vendor commitment.
Founder or investor needs a reliability and cost plan
A founder or private investor has a product idea, often AI-native, and needs a plan for reliability, performance and cost before committing serious build spend.
Typically fits: Design and build
Pressure to build quickly. Unclear what "good enough for production" means for this audience and business model.
Which foundation decisions matter now, and which can wait without locking in fragile or expensive paths.
Target users, critical journeys, reliability and availability needs, cost design, and how proof of concept should inform the next stage.
Whether to fund a lean foundation, narrow the idea, or pause until criteria are clearer.
Write the decision criteria and a short foundation plan before a larger build commitment.
Technical view
- Enterprise-grade thinking early prevents a demo that cannot survive first real customers. Lean scope still needs clear reliability and cost pillars.
- Leave with a plan a founder or investor can decide on, not a catalogue of engineer hours.
Proof of concept needs a path to production
A proof of concept showed promise, but the path to a reliable, cost-aware production service is still a set of assumptions rather than a plan.
Typically fits: Design and build
Stakeholders want to "go live". Engineering sees gaps in reliability, observability, cost control or integration that the PoC never faced.
What must be true before production, who owns each gap, and which PoC shortcuts become expensive debt.
PoC assumptions, production risks, cost trajectory, vendor or team capacity, and a lean sequence from foundation to first real users.
What to build, rewrite or defer before the first production commitment.
Agree production criteria and a short path from the PoC, with ownership for each open risk.
Technical view
- PoC success rarely proves operational readiness. Workload, data, failure modes and ownership need an explicit path, not a hopeful rewrite later.
- Technical leadership beside the team or vendor can define pillars without taking over day-to-day build as a billable bench.