Discover
Who lives this problem, what does it cost them, and why does it matter now?
Every Tabweeb venture moves through the same six stages. Each one answers a specific question, produces specific evidence, and ends at a gate where we decide whether the venture has earned the next level of commitment.
Who lives this problem, what does it cost them, and why does it matter now?
Is the demand real? Will anyone pay, switch or change behaviour?
What is the smallest product that can produce real evidence — and what must it deliberately not do?
What must be true for this to work in a real production environment?
What breaks under real load, real users and real money?
Does the evidence justify more capital, more market and more partners?
The build model
Each row expands into its own section below. Select a stage to jump to the matching anchor.
Question
Who lives this problem, what does it cost them, and why does it matter now?
Evidence produced
A problem brief written in the words of the people who have the problem.
Question
Is the demand real? Will anyone pay, switch or change behaviour?
Evidence produced
An observed behaviour, not a stated intention.
Question
What is the smallest product that can produce real evidence — and what must it deliberately not do?
Evidence produced
A scoped product definition with one agreed success metric.
Question
What must be true for this to work in a real production environment?
Evidence produced
A working product in production with trustworthy instrumentation.
Question
What breaks under real load, real users and real money?
Evidence produced
Operating metrics over a meaningful period, including cost to serve.
Question
Does the evidence justify more capital, more market and more partners?
Evidence produced
A growth plan tied to observed metrics and a specific capital requirement.
Stage 1
Before anything is designed, we go and sit with the problem. Discovery is not desk research. It is time spent with the people who currently absorb the cost of the problem, understanding what they already do to work around it.
Back to six stages at a glanceWhat we actually do
Interview the people living the problem, not their managers. Map the workaround they use today and what it costs them in time or money. Study existing alternatives and why they fall short. Identify the constraint that keeps the problem unsolved. Size and locate the affected segment.
Evidence produced
A problem brief and a market map of alternatives — both written in plain language, without product vocabulary.
Gate to advance
We can state the problem in one sentence without describing our solution, and we can name a specific, reachable segment that has it.
Typical duration
Two to four weeks.
Why a venture stops here
The problem turns out to be an irritation rather than a cost. People complain about it, but they have already absorbed it and have no intention of changing anything.
Stage 2
The cheapest test is the one that could stop the venture. Validation is where we deliberately try to kill our own idea, and where most of the value of the whole process is created.
Back to six stages at a glanceWhat we actually do
Write down the single assumption most likely to kill the venture. Define in advance the result that would count as a failure. Run the cheapest test that could produce that result — a concierge test, a paid pilot, a letter of intent, a prototype walkthrough. Check technical and regulatory feasibility in parallel.
Evidence produced
A validation report stating the assumption, the test, the observed result, and a clear go or no-go recommendation.
Gate to advance
Observed behaviour, not stated intent. Someone paid, committed in writing, switched provider, or did the work manually because they wanted the outcome badly enough.
Typical duration
Three to six weeks.
Why a venture stops here
Enthusiastic feedback with no behaviour behind it. This is the most common stopping point and the most valuable one — it is where we avoid spending a year on something nobody needed.
Stage 3
Deciding what not to build is the harder half of design. By this point we know the problem is real. The design stage decides how little we can build and still learn something decisive.
Back to six stages at a glanceWhat we actually do
Define the scope and, just as importantly, publish an explicit out-of-scope list. Map the customer journey end to end. Design the core flow. Choose an architecture with the operating cost in mind, not just the build cost. Decide which metrics the product will be instrumented to capture.
Evidence produced
A product definition: scope, out-of-scope list, customer journey, architecture, one agreed success metric, and a build plan with estimates.
Gate to advance
Everyone on the team can name the one metric that will tell us whether the build worked, and the scope fits inside the agreed budget and timeline without removing the core value.
Typical duration
Two to four weeks.
Why a venture stops here
The scope cannot be reduced to something affordable without destroying the value. That is a signal about the business model, not about the design work.
Stage 4
We ship evidence, not applause. The build produces the smallest credible product, built to production quality in the places where production quality actually matters — data handling, security, reliability.
Back to six stages at a glanceWhat we actually do
Build the smallest credible product, with real engineering quality where it counts. Instrument it before launch rather than after. Keep a live list of the assumptions the build itself is testing. Release in short cycles so a wrong assumption surfaces in weeks, not quarters.
Evidence produced
A working product in production, with analytics in place and a baseline reading of the agreed success metric.
Gate to advance
Real users complete the core flow unassisted, and the instrumentation is producing numbers we trust enough to make a decision on.
Typical duration
Six to sixteen weeks depending on complexity and integration surface.
Why a venture stops here
The technical cost of delivering the core value turns out to be structurally higher than the value itself — usually discovered in integration, not in the core build.
Stage 5
Launch is where the real information starts. Most companies stop paying attention here. Operating is where a product either proves it can be run profitably or reveals that it cannot.
Back to six stages at a glanceWhat we actually do
Run the product in real conditions. Support real users and log every issue. Measure retention, cost to serve and unit economics. Fix what breaks, and record what keeps breaking. Establish the operating rhythm and name an owner for each part of the system.
Evidence produced
Operating metrics over a meaningful period: retention, cost to serve, support load and unit economics.
Gate to advance
The product holds up under real conditions, the economics work at the current scale, and we can name what would break first at ten times the volume.
Typical duration
Three to six months minimum — shorter than that and the retention numbers mean nothing.
Why a venture stops here
Usage is genuine but the economics do not work: the cost to serve refuses to fall as volume rises.
Stage 6
We scale what has earned it. Scale is the only stage where we deliberately spend ahead of certainty, and it is available only to ventures that produced the evidence in the five stages before it.
Back to six stages at a glanceWhat we actually do
Expand distribution and capacity deliberately rather than all at once. Bring in partners for market access or a specific capability. Allocate or raise capital against a specific, evidenced plan. Strengthen the operating team ahead of the load, not behind it.
Evidence produced
A growth plan tied to observed metrics, a partnership structure and a specific capital requirement with a stated use.
Gate to advance
Growth is repeatable rather than campaign-driven, and the constraint on growth is capacity rather than demand.
Typical duration
Continuous — scale is a state, not a phase with an end date.
Why a venture stops here
Growth appears only when spend appears. That is a distribution problem to be solved before scaling, not during it.
At the end of every stage the same three questions are answered in writing, and the answers are kept. Over time they become the venture's decision history — which is also the fastest way to bring a new investor or partner up to speed on why the venture is where it is.
Gate questions
Forces the team to state findings as observations rather than impressions.
Prevents the most dangerous error in venture building — treating an untested belief as settled because it has been repeated often enough.
Ties the size of the next spend to the strength of the evidence, rather than to enthusiasm or sunk cost.
Possible outcomes
Advance · Iterate within the current stage · Pause · Stop. Four options, and three of them are not "advance".
Who decides
The venture lead presents; the decision is made with the founder. One named person owns the outcome of every gate.
What is recorded
The three answers, the decision, the date and the reasoning. Kept whether the venture advanced or stopped.
What is not allowed
Advancing because of the effort already spent. Sunk cost is not evidence.
Execution layer
Covers
Problem framing, customer research, validation design, product strategy and roadmap decisions.
Leads to
Covers
Architecture, front-end and back-end development, integrations, data, quality assurance and release discipline.
Leads to
Covers
AI and automation applied only where they improve an identifiable decision, workflow or operating outcome.
Leads to
Covers
ERP, business systems, integrations and the platforms required to fit complex operating environments.
Leads to
Covers
Reliability, security practices, observability, deployment, support and ongoing operation.
Leads to
Covers
Market access, sector expertise, distribution, co-building capacity and the capital required to expand.
Leads to
The value is not in having more capabilities. It is in connecting the right ones around the right problem.
Build models
Core model
Tabweeb originates the opportunity, funds the build and coordinates the full path from discovery to scale.
Ownership
Tabweeb owns the resulting asset.
When it fits
The opportunity was found internally and no external capability is required to prove it.
Tabweeb and a strategic party combine complementary assets and responsibilities around a validated opportunity.
Ownership
Shared, agreed in writing before the build starts.
When it fits
A partner brings market access, sector depth or distribution that would take us years to build.
A client owns the outcome; Tabweeb supplies product thinking, engineering and operating capability.
Ownership
The client owns the product and the IP.
When it fits
The problem is real and specific to one organisation rather than a market.
An existing product needs a team accountable for running, supporting and improving it.
Ownership
Ownership stays with the original party; Tabweeb is accountable for operation.
When it fits
The product works but nobody inside the organisation owns keeping it working.
Non-negotiables
We do not skip validation because a client or a partner is confident. Confidence is not evidence.
We do not treat a launch as a result. A launch is a question we have finally made it possible to answer.
We do not carry a venture forward because of the effort already spent on it.
We do not describe a venture as being at a stage the evidence does not support.
We do not add AI to a product because it is expected. It goes in where it changes a decision, or it stays out.