Skip to main content
The Tabweeb build model

An MVP is not the finish line. It is the beginning of evidence.

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.

Discover

Who lives this problem, what does it cost them, and why does it matter now?

Validate

Is the demand real? Will anyone pay, switch or change behaviour?

Design

What is the smallest product that can produce real evidence — and what must it deliberately not do?

Build

What must be true for this to work in a real production environment?

Operate

What breaks under real load, real users and real money?

Scale

Does the evidence justify more capital, more market and more partners?

Evidence before deeper commitment.

the two cheapest weeks in a venture's life

Every venture starts as a set of assumptions. The job of the build process is to convert those assumptions into evidence in the cheapest possible order — testing the thing most likely to kill the venture before spending money on the things that only matter if it survives.

This is why we spend real time on discovery and validation before writing production code. Not because we are cautious, but because the two cheapest weeks in a venture's life are the two that stop it from becoming eighteen expensive months. A venture that stops at validation is not a failure. It is the process working as designed.

The six stages at a glance

Each row expands into its own section below. Select a stage to jump to the matching anchor.

1 · Discover

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.

2 · Validate

Question

Is the demand real? Will anyone pay, switch or change behaviour?

Evidence produced

An observed behaviour, not a stated intention.

3 · Design

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.

4 · Build

Question

What must be true for this to work in a real production environment?

Evidence produced

A working product in production with trustworthy instrumentation.

5 · Operate

Question

What breaks under real load, real users and real money?

Evidence produced

Operating metrics over a meaningful period, including cost to serve.

6 · Scale

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

Discover

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 glance

What 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

Validate

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 glance

What 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

Design

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 glance

What 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

Build

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 glance

What 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

Operate

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 glance

What 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

Scale

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 glance

What 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.

What sits between the stages.

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

What did we learn?

Forces the team to state findings as observations rather than impressions.

What is still an assumption?

Prevents the most dangerous error in venture building — treating an untested belief as settled because it has been repeated often enough.

What evidence justifies the next commitment?

Ties the size of the next spend to the strength of the evidence, rather than to enthusiasm or sunk cost.

Gate mechanics

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.

The capabilities that execute the model.

Product & Market

Covers

Problem framing, customer research, validation design, product strategy and roadmap decisions.

Leads to

DiscoverValidateDesign

Engineering

Covers

Architecture, front-end and back-end development, integrations, data, quality assurance and release discipline.

Leads to

DesignBuildOperate

Applied AI

Covers

AI and automation applied only where they improve an identifiable decision, workflow or operating outcome.

Leads to

DesignBuildOperate

Enterprise Systems

Covers

ERP, business systems, integrations and the platforms required to fit complex operating environments.

Leads to

BuildOperate

Infrastructure & Operations

Covers

Reliability, security practices, observability, deployment, support and ongoing operation.

Leads to

BuildOperateScale

Partnerships & Capital

Covers

Market access, sector expertise, distribution, co-building capacity and the capital required to expand.

Leads to

Scale

The value is not in having more capabilities. It is in connecting the right ones around the right problem.

Four ways a venture can be built.

Core model

Internal venture

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.

Co-build

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.

Build for

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.

Operating partnership

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.

What we deliberately do not do

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.

If this is how you think a technology company should be run, we should talk.