B3N Labs

Turn an idea into a product people can find, pay for and use.

Labs is where B3N builds products and ventures: our own, with founders, and for companies launching something new. We cover the whole job, from customer research and the build to pricing, onboarding, launch and what happens after.

Discuss a product build See the products we run

Our products, shared ventures and paid builds

The relationship decides who pays, who owns the result and who makes which calls. We agree it before any work starts.

How B3N products, co-built ventures and builds for organisations differ
Question	B3N product	Co-built venture	Built for your organisation
Suits	A problem we see across many businesses, where we can build and sell the answer ourselves.	A founder or partner with deep knowledge of a market, and an opportunity big enough for both of us to commit to.	A company launching a new product, business line or major change to an existing product.
B3N does	Everything: research, design, engineering, launch, sales and running it.	Product, engineering and launch, plus operating roles we agree, such as growth or finance tooling.	The scope we agree: assessment, the build, launch preparation and handover to your team.
You bring	Nothing. You can become a customer.	Domain knowledge, customer access, time and a committed lead on your side. Sometimes capital.	A sponsor who can make decisions, people who know the domain, and access to customers and systems.
Paid for by	B3N.	Agreed for each venture: cash, time, or a mix of both.	You, under a written scope.
Owned by	B3N.	Set out in a written agreement before work starts, covering equity, decision rights and roles.	Normally you, for what you paid for. The contract spells it out.

B3N products

We build our own products where one answer can serve many businesses, then run them as businesses ourselves: Dispatch for car hire operators, Repeatable for repeat customers and Shey for founders.

Examples

Co-building with founders and partners

A shared venture is a different decision from a paid build. It makes sense when you hold something hard to copy, such as customers, a licence, distribution or years in the market, and we can carry the product and engineering. Equity does not replace the cost of a build by default; each venture is agreed on its own terms.

Ventures we help build

Building for organisations

We work with a sponsor inside your company and the people who know the customers and the systems. Decisions on scope, budget and launch stay with you. We plan the handover from day one so your team can run the product after we step back, or we stay on to support it.

Examples

Products B3N builds and runs

We own and run these products, so we deal with their hosting, bugs and support ourselves. That experience goes straight into the products we build for clients.

B3N product
Dispatch
Dispatch is B3N's software for car rental and hire companies. Each operator gets a booking site, a customer portal and one dashboard for the fleet, bookings, documents and money.
LiveMobility software · 2026 to now
B3N product
Repeatable
Repeatable turns a business's customer history into repeat purchases, referrals, loyalty rewards and win-back campaigns, and shows which of them brought customers back.
LiveCustomer retention software · 2026 to now
B3N product
Shey
Shey is a notebook for founders. You write rough, unfinished thoughts and it adds short, specific notes in the margin, the way a good adviser marks up a draft.
LiveAI writing tools · 2026 to now

Several of our products run on the hosting and deployment tools we built for ourselves.

Building it and getting it to customers

Software is the visible part. Whether a product succeeds often depends on the work around it: what it costs, how people start using it and who helps them when they get stuck. Labs covers both.

Building it

Customers and buyers: Who has the problem, who pays to solve it, and what they use today.
Demand and commercial assumptions: What has to be true for the product to earn money, written down so it can be tested.
Scope: The smallest product that solves the problem well, and what waits for later.
Design and prototypes: User journeys, interface design and clickable prototypes tested with real users.
Engineering: Web, mobile and backend software, built with tests and reviewed before release.
Integrations and deployment: Payments, messaging, identity and data connections, plus hosting and release pipelines.

Getting it to customers

Pricing: What to charge, how to bill and what is free.
Onboarding: The first minutes after sign-up, until a customer gets what they came for.
Distribution: The first channels and partners that reach the right customers.
Measurement: Events and dashboards that show sign-ups, use, payments and errors.
Support: Help content, a support channel and someone who owns replies.
Iteration: A routine for reviewing what customers do and deciding what changes next.

What you might receive

Which of these you need depends on where you start and what we agree. An assessment ends at the brief; a full build runs to the ownership plan.

1Product briefThe problem, the customer, the riskiest assumptions and the plan to test them.
2Tested assumptionsWhat interviews, prototypes or pilots showed, and what is still unknown.
3PrototypeSomething customers can click through before engineering starts.
4Build backlogThe first release broken into pieces with acceptance criteria.
5Working productDeployed software customers can use.
6Integration documentationHow the product connects to payments, data and other systems.
7Release criteriaThe agreed checks a release must pass, including the market-ready list below.
8Launch planPricing, onboarding, first channels and support, with owners and dates.
9Post-launch ownership planWho runs, supports and improves the product after launch, and how.

What market-ready means

A working demo is not yet a product customers can buy. Market-ready means customers can reach it, use it, pay for it and get help, and your team can run it. We agree which of these checks apply to your product before the build starts, and treat them as release criteria.

An internal tool needs fewer of them than a consumer app. A pilot with five customers needs fewer than a public launch.

The right customers can find it.
A new visitor understands what it does within a minute.
People can sign up and get started without calling you.
Customers can pay, if it is a paid product, and receive what they paid for.
Someone answers when customers get stuck.
The team can see usage, payments and errors.
A named person owns fixing problems and shipping improvements.

How an engagement runs

There are three ways in. You do not have to start with an assessment: if you already have customer evidence and a clear scope, we go straight to a build plan.

Assessment

When it fits: You have an idea or opportunity, but customers, demand or scope are still uncertain.
What happens: A short, fixed piece of work: customer interviews, competitor and alternative review, the commercial case and a first scope.
What you get: A decision brief recommending whether to build, change direction or stop, and a build plan if it is a go.

Scoped build

When it fits: The problem and customer are clear and you have evidence that people want it.
What happens: Design, engineering and launch preparation for an agreed first release, with weekly demos.
What you get: A working product that meets the agreed release criteria, documentation and a launch plan.

Embedded product leadership

When it fits: You have a team or a product in market, but nobody owns product decisions full time.
What happens: A B3N product lead works inside your team on a regular schedule, adding engineers and designers when the work needs them.
What you get: A product plan, a working routine for deciding priorities, and a team that ships against it.

B3N leads

The product plan and scope
Design and engineering
Release process and quality checks
Launch preparation
Weekly progress and decision log

Stays with you

The final call on scope, budget and launch
Your brand and customer relationships
Legal and regulatory sign-off
Who runs the product after launch

We need from you

A decision-maker who replies within days
Access to customers, or people who know them
Domain knowledge and constraints up front
Access to the systems and data we integrate with

How scope and price are agreed

After a first conversation we write the scope down: the problem, who the product is for, what is in the first release and what is not, the release criteria, the team and the cost. You see the whole thing before you commit. If the plan needs to change once work starts, we agree the change in writing first.

Price depends on the size of the first release, the integrations involved and how much launch and operating work you want from us. We quote each project rather than publishing a rate card.

What a product decision brief looks like

This is an illustrative example written for this page, not a client document. It shows the level of detail an assessment ends with.

Illustrative example

Payment reminders for wholesale distributors

Problem: Distributors give shops goods on credit and chase payment by phone. Owners spend hours each week calling, and overdue balances tie up the cash they need to restock.
Customer and buyer: Users: finance clerks at distributors with a few hundred shop accounts. Buyer: the owner, who feels the cash shortfall.
What they use today: Phone calls, WhatsApp messages and an ageing report exported from accounting software into a spreadsheet.
What has to be true: Distributors will share account balances weekly.
Shops pay after a clear reminder with payment details as reliably as after a call.
Owners will pay a monthly fee to cut overdue days.
Smallest useful product: Upload balances from a spreadsheet, send scheduled reminders by SMS and WhatsApp with mobile money payment details, and show who has paid.
Not in the first release: Accounting software integrations, credit scoring and an app for shops.
Launch requirements: Monthly price by number of accounts, an upload template and a setup call, support over WhatsApp, and tracking of reminders sent and payments received.
Recommendation: Run a four-week pilot with two distributors using their real balances before building any integration. Continue if reminded accounts pay at least as fast as called accounts; stop or rethink if they do not.

Code, accounts and ownership

Paid builds. We plan for you to own what you pay for: code in your repository, accounts with providers in your company's name, and design files and documentation your next team can use. We keep our general tools and know-how. The contract sets out the details, including third-party licences and who maintains the product after launch.

Shared ventures. Ownership, decision rights, capital and each side's responsibilities are written into an agreement for that venture before work starts. We do not have standard equity terms.

B3N products. We own them and offer them by subscription.

After launch. We hand over with documentation and a walkthrough, or keep running and improving the product under a support agreement. Either way, it is agreed before launch.

Describe the product and what you need to decide next.

Discuss a product build Propose a shared venture