Skip to content
Lock & Mercer

Venture building

The whole path, taken by people who will still be there when it is running.

What this is

From an idea to a thing with users and a bank account.

Most of what kills an early company is not the product. It is the gap between a product existing and a company existing around it, the entity that can hold a contract, the account that can receive money, the person who answers when something breaks at nine on a Sunday. We build across that gap because we have had to for SpaceYako, which is ours.

A venture build starts with the thing that is actually uncertain. Sometimes that is whether anyone wants it, and the first month is spent finding out cheaply. More often, in the markets we work in, it is whether the thing can be trusted, or licensed, or paid for, questions the product cannot answer on its own and which get considerably more expensive the later they are asked.

We take equity or we take a fee. We will tell you which one before we start, and we will tell you why. Taking equity means we are carrying the same risk you are, which changes what we are willing to argue for; taking a fee means we are not, which changes what we are willing to promise. Neither is the better deal in the abstract.

What’s involved

Company and ownership structure
The entity, who holds what, and how that survives the first outside investor. Decided before the product, because retrofitting it is expensive and occasionally impossible.
Product definition
What the first version does and, more usefully, what it refuses to do. A scope that fits in a quarter is not a compromise; it is the only kind that gets tested.
Payments and billing
Mobile money and card rails, reconciliation, refunds, and the failure paths. In this market that means M-Pesa behaviour is a design input rather than an integration task.
First-customer operations
The inbox, the admin screens, the manual steps you will do by hand for the first hundred customers, and the point at which each one has to stop being manual.

How it usually goes

01Name the constraint
A week or two, before any proposal. What has to be true for this to work, and which of those things is least certain.
02Answer it as cheaply as possible
Often that is not code. It is a conversation with a regulator, a spreadsheet, or thirty phone calls to the people you think will pay.
03Build the first version
Narrow, real, and in front of actual users. Instrumented so the next decision is made on what happened rather than what was hoped.
04Operate it
Someone runs it daily. Either we hand it over to a team you have hired, or we keep carrying it, both are fine, but the choice is made explicitly.

What we won’t do

  • We will not forecast your revenue. We can model what has to be true for a number to happen; we cannot tell you it will.
  • We will not build a marketplace with no supply plan. The build is the easy half and it is not the half that fails.
  • We will not take equity in something we would not operate ourselves.

Where we’ve done it

  • SpaceYako

    A property platform for Kenya, built around a single question: can you believe the listing?

Next

If this is the shape of your problem, describe the part that breaks if it isn’t right.

Get in touch