Why we discount our fees for a share of the product

There are two ways to work with Handee. The ordinary one is a project: you have a product to build, we scope it by outcome, prototype it in days, build it and run it, and you pay a fee. The less ordinary one is co-creation. You bring the market and the problem. We discount our fees, sometimes heavily, and take a share in what the product becomes. We win when the product does, and until then we carry part of the risk alongside you. Africam, Sherpa and Crest were all built this way, and this article is the explanation we give when someone asks why.

Why a builder would ever do this

The honest answer has three parts. The first is that a fee-for-service builder is paid the same whether the product succeeds or dies, and that shapes behaviour in ways clients can feel. Scope gets protected rather than challenged. The question "should we build this at all?" is rarely asked by the people being paid to build it. A share of the upside changes what we argue for in the room.

The second is that we are good at a specific thing, which is turning an idea for a connected product into a working one quickly, and that skill is worth more applied to a product we partly own than sold by the hour. A share in three products that work is a better business than fees from ten that do not.

The third is that we like it. Five of us started Handee by building our own product under lockdown, and the loop of owning the outcome, not just the delivery, is what we are built for.

What changes for the client

The obvious change is the price: the build costs less than it would as a straight project, which for a founder or an operator with a good idea and a thin budget is often the difference between starting and not starting.

The less obvious change is the behaviour. Because we share in the outcome, we challenge scope rather than protect it. We will argue to cut a feature that costs three weeks and earns nothing, and we will argue to add one that the market will pay for even if it was not in the brief. After launch we keep improving the product, because our return depends on it, rather than waiting for the next change request. In practice a co-creation partner gets a builder who behaves like an owner, because that is what we are.

What it looked like three times

Africam had the cameras and the audience but not the platform to bring people back every day. We rebuilt it as a business as much as a product: live streams running around the clock, instant sighting alerts on iOS and Android, games, a community, a field guide and the shop that funds the whole thing. The product decisions and the revenue decisions were made at the same table, which is exactly what co-creation is for.

Sherpa took on a problem farms know well: many standards asking the same questions in different words. The platform collapses them into one master set, records every audit and scores the whole farm across 45 subjects, with the data owned by the farm and shared by choice. That last design decision was a commercial one as much as an ethical one, and it was easier to make as partners than as a supplier being told what to build.

Crest needed a control room for parking and access, where a misread plate or a quiet lane used to surface at month end. Now operators see every lane, ticket and payment live, faults are flagged within the hour and the money reconciles. The thresholds that drive the number-plate recognition are tunable per site, a feature that came from running the product, not from the original brief.

When it works, and when it does not

Co-creation works when the partner brings something we cannot build: a market, a customer base, distribution, domain knowledge or a regulatory position. It works when there is a real product at the end rather than a one-off project, and when the partner wants a builder who will argue with them. It works best when both sides expect the relationship to last years.

It does not work for a product that is only a cost centre, however worthy, because there is no upside to share. It does not work when the partner needs full control of every decision, because we will have views and we will press them. And it does not work when the economics only close if we work for free; a discount still has to leave us paid. We say no to more co-creation proposals than we say yes to, and the ones we decline are usually missing one of those three things.

The paperwork is the point

Shared upside goes wrong when it is vague, so we write it down before we start, every time. Four things in particular. The fees: what is discounted, by how much, and what is still paid in cash. The share: what we hold, in what, and how it changes if either side puts more in later. The IP: who owns the code, the hardware design and the data, and what happens to each if the venture ends. And the exit: how either party gets out, how the product is valued if they do, and who keeps running it in the meantime.

None of this is exotic; it is the same conversation any two partners should have on day one, and the willingness to have it is a good test of whether the partnership will survive contact with reality. If a prospective partner would rather leave it loose, that tells us something too.

If you have the market

If you have a market and a problem that a connected product would solve, and you would rather have a partner than a supplier, talk to us before you talk to a dev shop. We will tell you quickly whether it is a co-creation fit, and if it is not, a plain project is still on the table. Either way the first step is the same: a brief, and a working slice in days.

Send us a brief, or write to hello@handee.co.za.