Research and development has to be paid for by something. For a solo technical founder the realistic options are an investor's money or someone else's infrastructure. I took the second one, and this is what it actually bought — including the three weeks of support tickets nobody mentions.
The decision underneath this one is not about funding mechanics. It is about what sort of thing you are building. A startup, in the venture sense, is an instrument for converting capital into growth rate. A business is an instrument for converting work into income. The two look identical for about six months and then diverge completely, because they optimise for different things: one for the next round, one for being right.
I wanted the second. Which meant the cost structure had to support it.
The cost structure made the choice available
The economics of this particular product are unusual in a way that matters here. Because the system deploys inside the customer's own cloud tenant, the compute that runs an investigation sits on their bill, not mine. Deployment and first-line support belong to the channel partner. What is left on my side is central and fixed: research, the investigation method itself, and the infrastructure required to build and ship the thing.
High fixed central cost, near-zero marginal cost per customer. That is a textbook software shape, and its practical consequence is that break-even is a function of how large you let the fixed cost grow — which is a lever you control — rather than a property of each deal. A solo founder who is also the entire R&D function has a very small fixed cost. Small enough that the infrastructure bill becomes the binding constraint, not salary.
What the startup programme is, in practice
Incorporate the operating entity first — the programme wants a real company, and doing it in the other order creates rework. Then the cloud vendor's startup programme puts $5,000 of infrastructure credit on the table at the entry tier.
Five thousand dollars is not transformative money. It is, however, almost exactly enough to run build infrastructure for the length of time it takes one person to get from architecture to a working system — container registry, a couple of container instances, log analytics workspaces, an AI service deployment, a static site and its edge. That was the only job the money had to do, and it did it.
| What it covered | What it did not |
|---|---|
| Build and test infrastructure end to end | Any salary, for anyone, including me |
| A lab tenant to run the agent against | Paid distribution of any kind |
| Model inference during development | Production inference at customer scale |
| Domain, edge, static hosting | Design, video, or anything that needs a contractor |
The part worth flagging: credits shape architecture
Credit tiers do not unlock on spend alone. They unlock on a combination of distinct active workloads and sustained spend, measured over a rolling window against the enrolled subscription. A workload means a genuinely distinct service in actual use, not a resource deployed once and abandoned.
Which means the infrastructure design is partly downstream of the funding mechanism. Moving the domain and static site into the same cloud, consolidating into a single subscription with resource-group-level separation rather than multiple subscriptions, keeping a demo environment running continuously — each of those has an independent justification, and each of them also happens to help the workload count.
I think that is defensible, and I also think it is worth naming out loud rather than pretending the architecture was decided in a vacuum. Designing around a funding mechanism is a real cost even when every individual decision is sound. The discipline is to check that you would still make each choice if the credits did not exist. In the two cases where the answer was no, I did not make the choice.
Then the wall
The next rung after credits is marketplace access, which runs through the vendor's partner programme. This is the bit that turns free money into distribution, and it is the bit that stalled.
Three consecutive weeks of support tickets, troubleshooting enrolment errors that should not exist, against a process that gives no visible state and no estimate. Anyone who has done it recognises the shape immediately. It is not a hard problem and it is not a decision anyone is making; it is a queue with an error in it.
The practical lesson is narrow but real: if part of your plan depends on being admitted to someone else's ecosystem, budget that in weeks of calendar time, assume it is serial with nothing else you can usefully do, and do not sequence anything urgent behind it. The free infrastructure is genuinely free. The bureaucracy around it is a line item you pay in attention.
What this route actually buys, and what it costs
What it buys is decision quality. There is no board, no clock, and no round to raise, which means a decision can be made because it is correct rather than because it is legible to an investor at the next milestone. Several of the entries in this log — switching off a component that took weeks to build, rewriting a working codebase in another language, publishing a funnel autopsy that says zero conversions — are decisions that are materially harder to make when someone else's capital is in the room.
What it costs is ceiling. Founder time is the constraint, and one person doing research, engineering, and distribution simultaneously has a hard limit that arrives well before the market does. That limit is real and I have not solved it. It is the honest counterargument to everything above, and if this log has a sequel, that is probably what it is about.