The Foundations Week

I found two. A co-worker who is a product owner and who has been using AI tools to architect complex commercial software, and a fellow designer who is building a substantial product of her own with them. Over a long series of conversations with both of them — at lunches, in DMs, on long calls that ran past their scheduled end — I picked up the two pieces of advice that have shaped the project more than anything else I've done with it.

The co-worker told me to think about foundations. The more background and context I could give the model up front, he said, the better the output for everything that came after. He told me to spend a week — maybe more — building out the kind of documentation a real company would build before writing a line of code. Product Overview. Requirements documents. Technical architecture. Release plans. The tools, he said, are extraordinary at filling in detail. They are equally extraordinary at not filling in detail when you give them a strong frame to work inside. The frame is the work.

He also told me, almost as a footnote, to keep ChatGPT in the loop as a checking tool — to ask one model to find weaknesses and gaps in another's output, then go back and fix what came up. I had not thought of using the tools that way. It had not occurred to me that you could put two of them in a room together and let them argue.

The other mentor — the designer — told me something harder. Hard enough that it's the entire subject of post 04, which is the next one in the series, and which I'm not going to spoil here. For now: she told me something I needed to hear about how the design work itself was about to change, and I am still working through what to do about it.

I took the co-worker's advice. I sat down with Claude — which was the tool my company was adopting at the time, so working with it on Gearious was also helping me adopt it for my day job, which is the kind of efficiency I will take wherever I can find it — and spent a long stretch of evenings building exactly the documents he had described.

It was unlike any design work I had ever done. Most of the activity was conversation. The model would ask questions. I would answer them, and in answering would discover I had not actually thought about whether a Pro tier should include unlimited bike profiles or merely many of them, and would need to think for a while before answering properly. The model would then summarize back what I had said in a way that made my answer sound a little more coherent than I felt it had been, and would ask the next question. Some nights I'd come back to a draft from the previous evening and read my own answers and think who is this person, this person sounds like they know what they are talking about, and then I'd remember it was me, and that the writing had simply been organized by something with more patience for organization than I had at eleven o'clock at night.

Halfway through, I started a second thread with ChatGPT and ran what I'd written so far past it for a critique. The co-worker's other advice. What came back was substantive. It found gaps. It found places where I had been vague. It found one place where I had explicitly contradicted myself between two documents written a few days apart, which I would have shipped without noticing. I fixed what came up. Then I went back to Claude with the fixes and kept going.

By the end of the foundations stretch, what I had was this:

A Product Overview. The thirty-thousand-foot version of Gearious — what it is, who it's for, what the core experience is, why it matters now. The document I would hand to a designer or PM joining the project to get them up to speed in twenty minutes.

Two Product Requirements Documents. One for the web application, one for the iOS companion. Each one a feature-by-feature, screen-by-screen walkthrough of what the product needs to do at v1.0 — what's in scope, what's out of scope, what the acceptance criteria look like for each feature, what the edge cases are.

Two Technical Architecture Plans. One for the web, one for iOS. Stack decisions, data model, the boundaries between client and server, the offline-first architecture for the iOS app, the API surface that bridges the two products. Not the level of detail a senior engineer would write for themselves, but the level of detail a senior engineer would need to start writing for themselves.

Two Release Plans. A phased roadmap for each platform — Alpha, Beta, v1.0, v1.1, future. What ships when, what gets deferred, what the gating decisions are for moving from one phase to the next.

A Notification Strategy. The document I didn't realize I needed until I needed it. A unified plan for every kind of message Gearious would send a user — push notifications, in-app, transactional email, marketing email — covering when each one fires, what it says, what it doesn't say (the rules for not notifying are more important than the rules for notifying), and how the iOS app's Ride Mode interacts with the whole system.

Eight documents, six categories. Maybe four hundred pages of writing if you printed it all out, which I won't, because the printer ran out of toner a year ago and I've made my peace with that.

The set is the kind of thing a small startup might pay a consultant fifty or a hundred thousand dollars to produce. I produced it over a few weeks of evenings, by myself, with two AI tools and the patience to actually answer the questions they asked me. The writing-it part was hard. The deciding part — what Gearious is, who it's for, what it isn't — was the actual work, and the writing was the surface where the deciding became real.

Looking back, the foundations week was the moment the project stopped being a side project and started being a real one. The prototype on my laptop had been a great proof-of-concept. The documents were the thing that turned a proof-of-concept into something that could actually be built.

Somewhere in the middle of the foundations week, I noticed I had quietly started playing every role of a small product team.

I had started as a designer. Then I had become a developer, working with Cursor to ship code. Then a product owner, writing the requirements documents and the feature specifications. Then something like a director, working on the high-level roadmap and the release plan. Then something like a head of engineering, working on the technical architecture and the stack decisions.

The sequence wasn't intentional. It was what the work asked for, one role at a time. The tools made each role possible in a way they wouldn't have been on my own a few years ago. The discipline was knowing when to step into each role and when to step back out of it — and when to admit I was the wrong role for a particular question and needed to call a mentor.

The five-role pattern is the part of this experience I am most certain will generalize. Solo designers building products with these tools, and small teams using them to punch above their weight, are going to spend more time switching between roles than they used to. Knowing which role you're in at any given moment is a meta-skill the tools surface. Most of the trouble I've gotten into on the project has been the result of being in one role when the work needed me in another.

It is, also, a slightly funny way to spend an evening. Tonight I will be the head of engineering. Tomorrow night I will be the product owner. The night after I might just go ride the bike. The work has a project-team shape to it that nothing I've done solo has had before.

The foundations were done. The documents existed. The prototype worked. The next thing the project needed was a public face — a place I could send people, a surface that would tell a rider who'd never heard of Gearious what it was and why they should care.

This is where the second mentor's advice — the one I didn't spoil earlier in this post — came back to claim its pound of flesh. Post 04 is about the landing page, and about the advice that made building the landing page substantially harder than I expected it to be.

It is the post I learned the most from writing. It is also the post I would have most resisted writing, ten years ago, before I had the tools to find out it was true.