Your problem getsone senior builder.

Barael started in Cupertino in 2026 with one builder and a thesis: with the right models and the right process, one senior person can ship what used to take a department a year. The founder had spent a decade as a product manager at a SaaS company, writing PRDs, running discovery, and watching good engineers build the wrong thing because the question was never asked in writing.

So Barael asks it in writing. Nineteen questions before any code. A plan the next morning. Then a senior builder with the best available models turns the answer into a product in weeks. Barael is one builder, on purpose. Every line of code handed over was written by the person you talked to.

Started as a product manager at a SaaS company. Ten years of shipping features, running discovery, and writing the documents that decide what gets built. Left to find out whether AI-native tooling could collapse the distance between the question and the shipped answer. It could.

Eddie still scopes every plan and writes code on every build. That is the point of staying small.

“The PM background means every project starts with the right question. The tooling means the answer ships in weeks, not quarters.”

The question comes first, in writing.

Nineteen questions before any code. If the problem cannot be written down, it is not ready to be built.

Working software every week.

No slide decks, no status theatre. You see the real thing running on your real data from the first week.

A human wherever confidence is low.

Every agent we ship routes uncertain decisions to a person. Automation earns trust by knowing what it does not know.

You own everything we make.

The product, the repo, the prompts, the docs. No platform fee, no retainer, nothing to renew.

Say no early.

Some plans end with a referral. The written read is useful either way, and a wrong fit costs everyone.

A real prompt, lightly redacted.

This parser opens the Speakeasy pipeline. It is what AI-native means in practice: a contract with a model, written like code, versioned like code, tested like code. Every build you own ships with its prompts in the repo.

You are a parser. Input: a raw interview
transcript. Output: JSON matching the schema
below. Never invent a question that was not
asked. If a line is ambiguous, set
"confidence" below 0.6 and leave "answer" null.

schema: { question: string, answer: string|null,
          speaker: "host"|"guest", confidence: 0..1 }

Return only JSON. No prose. No markdown.