What the buyer actually bought
In short: I sold my startup and its technology, and I do not think the buyer was paying for clever code. They were paying for the parts that keep the product working without me: the pipeline that…
- published
- read time
- 4 min
- words
- 826
- lang
- en
- filed under
- Product
In short: I sold my startup and its technology, and I do not think the buyer was paying for clever code. They were paying for the parts that keep the product working without me: the pipeline that rebuilds the data, the checks that say whether answers got worse, and a deploy that runs in one command.
The startup was an AI product that I built alone. It has now been sold, along with the technology underneath it. I am not going to describe the product, the buyer or the terms. I want to talk about what changed hands, because it was not what I expected when I started.
Nobody gives you a line-by-line breakdown of what they valued. What follows is my read of it, as the person who built every piece and then had to explain each one to someone else.
The code is the cheap part
Anyone competent can build an AI demo in a weekend. Call a model, feed it some data, put a chat box on top. It will even answer most questions well. That weekend demo and a product someone will pay for look almost the same in a screen recording.
The difference is everything around the code. Can you rebuild the data from scratch? Do you know when a change made answers worse? Can someone who is not you deploy it on a Tuesday? A buyer cannot see any of that in a demo, so those are the questions that matter when they look closer.
A demo shows what the code can do. A buyer pays for proof it will keep doing it.
Asset by asset
Here is how I would rank what was handed over, from the buyer's side of the table.
| Asset | What it is | Why it is worth paying for |
|---|---|---|
| The data pipeline | Code that fetches, cleans and prepares the data the product runs on | The data can be rebuilt, fixed or extended without me in the room |
| The processed data | The data itself, already cleaned and indexed | Weeks of fetching and cleaning they do not have to repeat |
| The evaluation checks | Inputs with known good outputs, run before every change | A new team can change prompts or models and know if they made it worse |
| The deploy path | One command from repository to running service | The product keeps running on the first day under a new owner |
| Written-down decisions | Prompts and logic with the reasons for them next to the code | Many small decisions about the domain, readable by someone new |
| App and interface code | The screens and the glue behind them | Necessary, but the easiest part to rebuild |
Notice what sits at the bottom. The part that looks best in a demo, the interface, is the part a capable team could redo fastest. The most boring part, a list of inputs and expected outputs, is the part that lets anyone else touch the system with confidence.
The handover is the product
Once a sale is agreed, the job changes. You stop building features and start making yourself unnecessary. For me that meant:
- A README per service that says what it does, what it needs, and how to run it.
- An example environment file with every variable named and nothing secret in it.
- One command to deploy, and one to run the evaluation checks.
- A short note per pipeline on where its data comes from and what breaks first.
Every hour spent on that list raises the value of everything else. Code that only its author can run is worth very little to anyone but its author.
If you might sell what you are building
You do not need to be planning an exit for this to pay off. The same things make a product easier to run alone. Here is what I would do from week one next time:
- Keep the data pipeline in the repository, not in a notebook. If the data cannot be rebuilt from code, it is a pile of files, not an asset.
- Start the evaluation checks on day one, even with ten cases. Add one every time a user finds a bad answer.
- Make deploy one command before you have users. It only gets harder later.
- Write down the domain decisions where they live. A prompt with a comment explaining why is worth more than a prompt alone.
- Once a month, pretend you are the buyer. Clone the repository on a clean machine and try to run it. Fix whatever stops you.
The last one takes an afternoon. It is the closest thing I know to seeing your product the way someone with a chequebook will.
related