I am writing this on a Tuesday in the last week of January, twenty weeks and roughly two hundred and thirty-five commits into building DuranteOS. Studio has been live for eighteen days. The reference customer has not signed. The conversations are starting to land in my inbox; none of them have crossed the line into a contract.
I am writing the GTM essay before the customer signs because once the contract is in place, I will be writing about something concrete, and the reasoning that produced the strategy will be invisible to the operators reading it next year. The reasoning is the part I want on the record now. If I get the strategy wrong, I want the receipts visible. If I get it right, I want next year's founders to be able to read the version that did not yet know if it would work.
There is a well-meaning piece of go-to-market advice you have probably heard. It goes like this:
"You need ten paying customers before you know if the product works."
The advice is wrong for the kind of product I am building. For a personal AI operating system — the kind of thing that has to be installed, configured, integrated with the operator's actual work, and run for weeks before it is fairly evaluated — ten shallow customers is worse than one deep one. Worse for the customer (no one gets enough attention), worse for the founder (the signal is averaged across noise), and worse for the product (you optimize for the surface that all ten share rather than the depth any one of them actually wants).
So I am ignoring the advice. The DOS GTM target for the first phase is one paying customer by July 2026. One. Singular. With a year-long depth contract at a founding rate, and a structured collaboration that gives me the patterns, the case study, and — if it works — the second through tenth customers as referrals.
This essay is the strategy. It is also, more honestly, the version of the strategy I have rewritten three times in the last six months, which means it is probably wrong in some way I have not yet noticed. I will write the corrected version when I find out.
The strategy in one sentence
One paying reference customer by July 2026, on a one-year commitment, with the founder doing white-glove integration and the customer agreeing to be a public case study, at a founding rate.
Why one customer beats ten
I want to defend this carefully because it goes against most early-stage SaaS playbooks.
A new product has two scarce resources in its first six months: founder attention and product specificity. Founder attention is finite (~50 hours per week sustainable). Product specificity is fragile (every customer pulls the product in their direction; ten customers pull in ten directions, none of which are necessarily the founder's vision).
| Resource | Ten shallow customers | One deep customer |
|---|---|---|
| Founder attention/customer | 5 hours/week | 50 hours/week |
| Product feature pull | 10 directions | 1 direction (and the founder's intention) |
| Quality of feedback | Diluted, surface-level | Concentrated, deep |
| Case study material | Anecdotal slices | Full year, full context |
| Risk profile | Spread thin | Concentrated |
The risk profile is the legitimate concern: lose the one customer, lose the revenue. I think this is the right risk to take in phase one, because the alternative (ten shallow customers, none of whom can be a meaningful case study) carries a different and worse risk: never reaching the depth of evidence that lets you sell to the eleventh customer at any rate. The asymmetry is my whole bet.
The selection criteria I am hunting against
Not every prospective customer is the right reference customer. The hunt is for a specific operator with a specific shape, because the case study only generalizes if the customer is recognizable to other operators.
The five criteria the founding customer has to satisfy
- Technical operator running their own work. They write code, ship product, or run technical operations themselves. Not a delegator. The product's affordances are designed for an operator with hands on the keyboard, and a non-technical buyer cannot give the depth of feedback the relationship needs.
- Solo or very small team (<5 people). The product's value proposition is "your personal AI OS." It does not yet handle team-shared memory, role-based access, or multi-operator coordination. A larger team would surface gaps the product is not yet ready to fill.
- Currently using AI assistance heavily but informally. They already use Claude/ChatGPT/Cursor multiple hours per day. The bar for "this is meaningfully better than what I have" is high; that high bar is what the case study needs to clear.
- Willing to be a public case study. The whole point of a reference customer is that the customer becomes the proof. If they cannot or will not have their experience documented and named, they are not the right reference even if they are the right customer.
- Located in a market I can serve well. PT-BR or English. Time zone within ±4 hours of America/Sao_Paulo. Local-enough that I can do an in-person onboarding session if needed.
The five criteria narrow the addressable pool from "everyone using an LLM" to perhaps a few hundred operators globally. That is fine. I do not need a thousand prospects; I need one match.
Where I am hunting
The acquisition channels are deliberately narrow. Each one is high-touch and slow.
Channels I am using vs. channels I am explicitly not
- Cold outbound to lists. A personal-AI-OS sales cycle requires trust the operator does not yet have for an unknown sender; cold conversion would be brutal even if I could build the right list.
- Paid ads (LinkedIn, Twitter, Google). Paid acquisition for a founding-rate product to a solo operator is unit-economically bad until LTV is proven, which it is not yet.
- Marketplace / app store listings. No marketplace exists for personal AI OS products today; building presence on adjacent ones (Vercel, Anthropic) attracts the wrong shape of operator.
- Conference talks. Useful eventually, costly now (preparation time, travel time, and the audience is not yet the right operator profile).
- Builder's Compass newsletter. ~3,800 senior-engineer / technical-founder readers, weekly architectural content for two years and a quarter. The trust capital is already built; the product is the natural extension.
- Direct conversations with people who reply to BC. ~20-30 replies per issue; ~3-5 per month from someone matching the founding-customer profile. These get a personal reply and an invitation to a conversation.
- Referrals from early pilot users. A small number of operators have run early DOS builds without paying as part of the pre-launch design loop. Each has been asked to introduce me to one operator they trust. A handful of intros so far; a couple in early conversation.
- Public writing about DOS itself. Posts like this one. Operators self-select by reading. The conversion rate is low; the conversation quality is extremely high.
What I am offering — and what I am asking
The founding offer is structured with both sides made explicit. I want operators to opt in with full knowledge of what they are getting and what they are giving.
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
| Price | founding rate | yes | locked for 24 months | Below market for the depth of access. Locked at this rate while I build out the next nine customers; standard tier will be meaningfully higher. |
| Commitment | 12 months | yes | month-to-month after | The depth requires time. Six months is too short for the patterns to compound; eighteen overcommits the customer. |
| Founder access | ~50 hours/month | yes | weekly working session + async | What the customer is buying — direct collaboration with me on their use of DOS. |
| Customization | Custom skills and packs included | yes | two new packs per quarter, customer-prioritized | The customer's specific workflow gets built into DOS as a permanent capability. |
| Case study commitment | public retrospective at month 12 | yes | customer-approved | What the customer is giving — public attribution and a documented retrospective. Customer approves all content before publication. |
| Exit terms | any time, any reason, full data export | yes | 30-day notice | Customer can leave whenever, with everything they put in. No lock-in via friction. |
The case study commitment is the part where I have already lost two prospective customers. Some operators want the value but not the public exposure. That is a legitimate position; it just disqualifies them from the founding cohort. The founding rate is priced for the case study contribution; without it, the unit economics of the relationship change.
What graduates the strategy from "founding" to "next phase"
The end of the founding phase is not "we hit ten customers." It is "we have a customer running DOS for twelve continuous months, with documented results, a willingness to talk publicly about what worked and what did not, and a referral network of three to five operators who have asked to be next."
When that happens, the next phase opens — likely standard pricing (a meaningful step up from the founding rate), less founder time per customer, more product polish per release. The founding tier closes; the next ten customers come in at standard pricing on the strength of the case study.
If it does not happen by July 2027, I will know something different. The thesis was wrong, or the rate was wrong, or the customer profile was wrong, or my execution was. Each diagnosis leads to a different next move; I will write that retrospective when it is the right one to write.
The trust constraint
A founding-rate commitment from a solo operator to an indie founder is not just a financial transaction; it is a trust transaction. The trust is built through Builder's Compass and through public writing like this post. Operators who commit will already have read my work for months. The first conversation will not be a sales pitch; it will be a continuation of a conversation the operator has been having one-sided with me for two years.
What I have learned in the hunt so far
Three observations from the first six months of looking, in order of how much they have changed my strategy.
One. The right operator self-identifies. The match-quality of an inbound conversation from a Builder's Compass reader is dramatically higher than any outbound I have attempted. The lesson: spend the time on the writing, let the writing do the qualifying. I tried twenty-three pieces of cold outbound across the first three months. Three replied. Zero matched the criteria. Meanwhile two inbounds from Builder's Compass replies scored as high-fit on first read.
Two. "Personal AI OS" as a category description does not land yet. Operators understand the components (knowledge graph, hooks, packs, gateway) more easily than the category. I have stopped leading with the category and started leading with the components, then assembling the category as the natural conclusion. This was a meaningful conversion improvement in conversation pacing.
Three. The founding rate is correct but feels wrong to the operator at first. It is below market for what is offered, but it is above the operator's reflexive ceiling for "tools I personally pay for." The conversation that resolves this — the one that walks through what the operator currently spends on a portfolio of inferior tools — takes about 40 minutes. The 40 minutes are well spent; the operators who do not want to have that conversation were not going to be the founding cohort anyway.
Why I am writing this in public before the customer signs
There is a temptation, in early GTM, to keep the strategy private until you have the proof. The argument is that publishing the strategy without the proof undermines credibility — anyone can have a strategy.
I think the temptation is wrong for this product, in this moment. The product I am selling depends on the operator trusting that I have thought carefully about who they are, what they need, and what I am asking them to give in exchange. The cheapest way to demonstrate that thinking is to publish it, with all the uncertainty intact, before I have the proof.
The version of this essay I will write in 2027 will say "this worked" or "this did not work, here is what I changed." Either version will be more useful to next year's founders if the unedited 2026 version exists alongside it. The unedited version is this one.
The customer who signs the founding contract will have read this essay. They will know exactly what they are walking into, on what terms, with what I expect of them. The deal will not be a negotiation; it will be a confirmation. That is the kind of trust that gets built by writing the strategy down before you need it.
The runway context
The financial decision behind the strategy.
The product thesis
What the customer is being asked to bet on.
The acquisition channel
How the trust capital was built.
The other product
Different GTM for a different shape of customer.
The hunt continues. The right operator is somewhere in the Builder's Compass list, or in someone's referral, or reading this post and wondering whether to reach out. If you think you might be them, the answer is: yes, write to me. The first conversation is free, structured, and short — 30 minutes to figure out whether the fit is real on both sides.
If we are right, we will know within a month. If we are wrong, we will both have used the time well to find out.
July 2026. One reference customer. Locked in.
The clock is running.
Was this page helpful?