What we will not build.

The most useful sentence I've found in two years of running this company starts with "we won't build."

A young company is most legible to a careful reader in the things it has chosen not to do. Roadmaps and launch posts show what's being built, which, by definition, is half-finished and partly aspirational. The list of refusals — what the founder has put on the record as off-limits — is the part of the answer the roadmap can't carry.

This letter is that list, signed and dated. It's the part of the product I want a fund partner reading us in the middle of diligence to find first, and the part I want a partner at a House to be able to point to in a partnership-committee meeting when they're arguing for the spend. None of the six below are refusals of things we haven't had the chance to build. Each one is the answer to a real request from a real customer, partner, or investor in the past six months. The requests were good. The answer is still no.

What we will not build

Refusals · v 2026 · signed

1. 01

   A consumer chat surface for memoranda.

   The artefact is the signed document, not the conversation that produced it.

2. 02

   A share-to-social surface.

   Memoranda are confidential by default. Sharing is token-gated and audit-logged.

3. 03

   A free or self-serve tier.

   The unit economics of a House do not meet at zero. Diligence is hand-in-hand.

4. 04

   Comments, ratings, social proof on memoranda.

   A House does not need an audience. A memorandum has a reader, not a feed.

5. 05

   Training on customer data.

   Structural, not contractual — training_eligible is forced to false at the DB.

6. 06

   Customer-selected model swaps mid-engagement.

   The chamber is single-purpose. The model is resolved by the chamber kind.

We get asked for this version of the product more than any of the others. A House would like a chat surface they can drop a folder of PDFs into and walk away with an answer. We won't ship it.

The reason is the one I'll repeat across most of these refusals: a chat transcript isn't a document a partner can sign. It has the question and the answer, and that's all it has. The memorandum has the question, the answer, the citation, the refusal, the reviewer, the version, the timestamp, the audit log. The committee, the auditor, the regulator, and the LP read memoranda. The chat is what the partner uses on the way to the memorandum, not what comes out at the end.

There's a softer version of the chat surface I should address, because it confuses the conversation otherwise. Inside the chamber, a reviewer can ask the engine a clarifying question about a section and get a cited answer back. We ship that. It's a tool the reviewer uses while drafting, not the artefact the House signs at the end. The thing we won't ship is the surface where the conversation is itself the product.

A memorandum is a confidential document with a small named audience: a few partners, an investment committee, counsel, maybe an auditor. Its value isn't in being seen widely. Its value is in being defensible when the people entitled to read it open it.

A product manager will eventually ask for the share-to-LinkedIn surface. The answer is no. When a House shares a memorandum it happens through the share-link route, which is token-gated and audit-logged: every read recorded, every revocation recorded, every download hashed against the original blob. The discipline of a confidential workflow is what the House is buying. Trading that discipline for a vanity metric we don't need would be giving the customer back something they came to us to get rid of.

There's no free tier. There's no fourteen-day trial that converts into one. There's no "give us your email and we'll send you a sample memorandum." Self-serve doesn't exist for a Diligence OS engagement and the architecture of the product is the reason.

An engagement isn't a SaaS unit. It's a partnership: a chamber resolved against the House's data-residency policy, a reviewer trained on the House's vocabulary, an audit log built to survive a regulator. The first ten Houses we onboard, we onboard hand-in-hand. The eleventh, the same way. There's no flow in any of our plans that lets a stranger drop a folder of PDFs in and walk away with a memorandum, and no customer for that flow in the market we serve.

The objection is usually a marketing one: "easy to try" sells. I know. The trade we'd be making is the customer-service problem of engagements running unattended against materials nobody licensed, producing memoranda no partner will sign. The cost of producing those artefacts is higher than the cost of refusing the flow.

A memorandum is a private document. It isn't content. It doesn't need a comment section, a star rating, a "1.2K likes" counter, a "shared by 17 colleagues" line, or anything else whose function is to convert a private document into a public one.

The same goes for the letters on this site. There's no comment section, no sign-up form, no "subscribe and we'll send you a PDF" composer that captures a name in exchange for a download. The RSS feed is the only mechanism by which a reader can subscribe to these, and that's deliberate. A House that wants to talk to me about a letter sends a note through the contact form. I write back. The number of subscribers we have isn't a number I want to report quarterly, so we don't collect it.

What we're building is a memorandum a House can sign. What we're not building is an audience for that memorandum. The asymmetry is closer to the point of the whole thing than any of the other refusals on this page.

This refusal is the only one of the six enforced at the database, not in policy. Every chamber row carries a column called training_eligible. A check constraint on the column refuses any value except false. A trigger refuses any UPDATE that would set it true, including from the service role. The default is false, and no production route writes anything else.

The contractual half of the same commitment lives on our principles page and in the DPA. The reason the database half exists in addition to the contractual half is that policies can be revisited and contracts can be renegotiated and postures can be walked back over a quarter without anyone noticing. A check constraint can be removed, too, but removing it is visible: a migration in version control, a pull request someone has to approve, a row in the audit log of the schema itself. Walking the refusal back would take a signature.

What we won't build is a code path that lets the engineering team — or me — quietly use a customer's data to improve a fine-tuned model that benefits a different customer. The technical refusal is what makes the contractual one credible.

The chamber is single-purpose. The chamber kind — atelier, House, sovereign — is fixed at engagement creation. The model is resolved from the chamber kind and the data-residency policy. A customer picks the chamber. The chamber picks the model.

If a customer were allowed to swap the model halfway through an engagement — "rerun this section against a different family, the first answer felt off" — three things would break at once. The workflow stops being reproducible. The audit log stops being replayable. The harness's score on the previous model becomes irrelevant to the memorandum the customer is actually getting.

We won't ship that toggle. The customer picks the chamber kind. The chamber resolves the model. The audit log records the resolution. The next time the same chamber runs against the same fixture, the same resolution gets recorded again. Reproducibility is the floor. A customer-facing model toggle would cut through it.

A reader may be wondering why a list of refusals belongs on a marketing surface at all. The honest answer is that the refusals are the part of the product I'm least confident a careful reader will infer from the rest of the marketing. The chamber diagrams, the memorandum specimens, the workflow registry, the audit ledger — those show what the product is. The list above is what the product isn't, and saying it out loud is harder than showing it.

The other reason — the one a reader doing diligence on me as a company will care about — is that publishing the list is a forcing function. A refusal written down in public is harder for me to walk back than one I've only said out loud in a meeting. Three years from now, when a future colleague proposes shipping a free tier because the growth team needs a top-of-funnel surface, they'll be arguing against a written commitment, not just my preference. The page is what protects the next quarter's product from the next quarter's pressure.

There will be more refusals as the work asks for them. The next ones I expect to write down are around generated marketing content (no LLM copy on these surfaces, no synthesised testimonials, no generated case studies) and around third-party plugins (no Chrome extension, no Slack bot, no LP-portal embed). I'd rather write each refusal as it becomes a real refusal, with a real cost, than ship a vague "we promise to be thoughtful." A vague promise isn't a refusal. It's an aspiration with better PR.

— A.O.