Leaving a job to build: the first two weeks

In short: I've left my job at a medical AI company to build my own product, alone. I gave myself two weeks of setup before any product code: a one-page brief, accounts with budget alarms, a deploy path that works on day three, tracing, and a small test set. One week in, I'd make the same plan again.

The temptation on day one is obvious. You finally have all your hours, the idea is in your head, and you want to open an editor and start building the interesting part. I've watched projects go that way, and I've done it myself on weekend builds. It works for a weekend. It does not work for something you plan to put in front of paying users, maintained by one person.

So I wrote down what the first two weeks would be, and I'm holding myself to it.

What I'm building, roughly

I won't name it yet. It is a full-stack AI product: a web app, a voice and audio side, and a retrieval pipeline that answers questions over a large pile of documents and cites where each answer came from. That last part is the core. An answer without a source is useless to the people I'm building for.

That shape decided most of the setup. Three parts that talk to each other, model calls that cost money on every request, and a quality bar that is about evidence, not vibes.

The plan

1. Days 1 to 2: one pageWho it is for, the one job it does, and a list of things it will not do in the first version.
2. Day 3: accounts and alarmsSeparate cloud projects for development and production, budget alerts on every provider, keys in a secret manager.
3. Days 3 to 4: deploy nothing, properlyA repo, a container, CI that runs tests, and a hello-world endpoint that ships to production on every merge.
4. Days 5 to 7: the plumbingPostgres, auth, a vector index, and tracing on every model call before there are many model calls.
5. Days 8 to 10: the test setA small set of real questions, each with the passages a correct answer has to cite.
6. Days 11 to 14: one thin sliceOne question in, one cited answer out, through the real stack, deployed. Ugly on purpose.

Why each piece is there

The one page

When you work alone, nobody asks "why are we building this?" in a meeting. The page asks it for me. The most useful part is the "will not do" list. Every time I want to add something, I check whether it's on that list. It has already talked me out of more than one feature.

Budget alarms on day three

An AI product spends money by itself. A loop that retries a model call, a test that hits a paid API, an index rebuilt by mistake. At a company, someone else watches the bill. Now it comes out of my own pocket. Alerts on every account take an hour to set up and remove a whole category of bad mornings.

Deploy on day three, before there is anything to deploy

This is the one I'd tell anyone to copy.

I've deployed services on GCP Cloud Run and AWS EC2 at work before, and it still took longer than I expected to get the container, the build, the secrets and the health check right for a brand new project. I would much rather spend that time now than the night before a demo.

Tracing before there's much to trace

A retrieval pipeline fails quietly. The answer looks fine, it just cites the wrong passage. The only way to see why is to look at what was retrieved, what went into the prompt, and what came out. Adding tracing later means going back through every call. Adding it on day five means it's there when the first strange answer shows up.

The test set before the pipeline

This is the part I'd have skipped in the past. Before I write the retrieval code, I want a small set of questions, each paired with the passages that a correct answer must cite. Without that, every change to the pipeline is judged by me reading a few answers and feeling good or bad about them. With it, I can tell whether a change made things better or just different.

What the first week taught me

• The days are shorter than they look. Without meetings I expected endless time. In practice, accounts, paperwork and setup ate more of the week than code did.
• CI is my code reviewer now. There is no one to catch my mistakes in a pull request. Tests and a linter that block the merge are the closest thing I have.
• Writing things down is not overhead. I keep a short decision log: what I chose, what I didn't, and why. When I come back to a choice in a month, I won't have to rebuild the argument.
• Saying no is the job. The list of things the product won't do is already longer than the list of things it will.

If you're about to do the same

Before you quit, or on your first morning after, write the one page and the "will not do" list. Then set up budget alarms on every account you'll use, and get a hello-world endpoint into production through the pipeline you'll keep. If those three are done by the end of your first week, the second week can go to the plumbing and the test set, and the product code you write after that will have somewhere solid to land.