gen-z-developers.sgit.ai → The second edition → Hands on, 2026 → Your first price and your first ten customers

Hands on, 2026 · chapter 39 of 41 · release candidate v2.0.0-rc2 · 1,107 words · read and review

Your first price and your first ten customers

By the end of this chapter you will have a price on the thing you built, a one-sentence offer sent to the people who already know you, a stop rule written before the first message went out, and a file of counts that tells you whether you have a product. The argument is in Price it, then give it away and Ship it, and see if they miss it; this is the workflow, as the newsroom wrote it for the agents running RiskMandate's early access programme, and as I would run it for a company of one.

Price it first

Define the product. Not the technology: the thing somebody receives. For RiskMandate the sentence is an Agent Behaviour Policy for one agent, as an encrypted vault the customer holds the keys to, with the mandate corrected for their deployment. It took weeks to get to that sentence, and it is the product. Write yours before anything else in this chapter. If you have spent twenty years inside the problem, you will know when the sentence is wrong faster than any developer you ever briefed.

Price it, at a number that makes sense to you. Not a number from a competitor's page: a number you would be content to be paid. A price is a statement of what you think the thing is worth. RiskMandate's ladder, as published on 2 October 2026, is four tiers: ten pounds for the pack downloaded, fifty for a working vault, five hundred for the vault corrected for your situation, fifteen hundred for two sessions and a professional's signature. Yours will have different numbers and should have the same shape: the cheap tiers automated, the dear ones with people's time in them.

Deliver it at a cost that grows a step at a time. This is the move that was not available a year ago. The vault is provisioned by an agent, the policy drafted by an agent from the customer's prompts, a person corrects it, so the twentieth customer costs close to what the second did. That is linear, not exponential, and it is the condition under which you can afford to give some away. If your tenth customer would break you, go back to Ship a serverless product in a weekend first.

Then give it away, properly

Offer it, free, to the people who already know you. Early adopters, power users, the people who paid for something before it was finished. If you built the folders in An agentic workflow from zero, the list is already in them. They get the first round, and the offer says that is why: a thank-you that is also the best possible test group, because they know enough to say where it is wrong, and their silence means the most.

Do not make them apply. "Apply for a chance to be considered" asks for work before there is anything in hand, and it inverts the relationship: they are doing you a favour by using the thing. The message says what it is in one sentence, that there are twenty in this round, that they are being offered one because they were early, and asks yes or no. It does not carry the price; the price is for the people who come after. This chapter's title says ten and the programme said twenty; the number is yours, fixed before the first message goes out.

Free is never free for the other side. They still have to read the message, decide whether it applies to them, find twenty minutes for the prompts and half an hour for a call, and fit a new thing into a team that has a way of working. The first thing to measure is that cost: how long from message to first reply, how many never replied, how many started and stopped, how many asked a question the message should have answered. Then cut it. No second tool to install, no account to create, no overhead on deployment.

Count, then decide

Set the stop rule first, before anything is sent: if, after the first twenty, fewer than a handful have run the prompts and sent a correction, the programme stops and the drawing board starts.

Then count, daily, into one file: how many were created, how many customised, how many used, how many runs. A thing created and never customised is a download. Customised and never used is a document. The commercial value is in the third number. Add corrections received, because a correction is the strongest sign somebody read it. And for every person, the minutes each step cost them and where they stopped, as timestamps and steps only, no message content. Every stop is a finding: not why they did not care, but what cost them more than it should have, written down as a product change to make.

Then the test. Take it away, and see whether they miss it. If they shrug, you have something people accept when it is free, which is a weaker signal than it feels from the inside. If they come back for it, you have a product, and the question becomes price: would they buy more, is five hundred too low for what they got, does the next tier sell itself once someone has had this one free. Neither answer is a marketing problem. If friendlies will not take it free, a bigger audience will not take it either.

Apply it to yourself as well. In I miss it, so it is working I wrote that the people who decide the roadmap have to be users, and that my earlier startups failed that test: good ideas, and I was not using them. If you have access, can change it, and still do not use it, something is missing, and it is not the code.

Last, when the money moves. Where the cost of serving is close to zero, let people pay after the value rather than before it. The newsroom's meter starts every reader with £5 of credit, charges 10p for a new article read to the end, lets the balance go below zero and blocks nothing; the request to pay arrives after dozens of articles, with what they were in view. The research on paying first is not kind: gym members on a monthly contract paid more than $17 a visit when $10 a visit was on offer. A price seen after the value is one people are glad to pay, and a model that only works where serving is nearly free is one more reason to build so that it is.