Five Roles and a Landing Page

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 I needed to let go of the pixels.

This one was harder.

I have spent my whole career making sure the pixels are right. The craft of aligning every margin and tuning every type ramp is part of what I do, and a meaningful part of why I'm good at what I do. Letting go of it ran against most of my working instincts and, if I'm being honest, against a non-trivial portion of my personality. She was, however, right. The way these tools work — the way the leverage actually flows — depends on the designer becoming closer to an art director than to a pixel-pusher. Describing the voice. Describing the tone. Describing the feel I wanted, the audience I wanted to grab, the emotion I wanted a particular surface to produce. Not the exact margins. Not the exact type scale. The direction, not the deliverable.

I am still learning to do that. It does not come naturally to me. There are days when I close the laptop with twelve open browser tabs of inspiration links and the unshakeable sense that I did not actually do design work — I described design work, which is a different thing that I haven't yet decided how I feel about. The output is good. The output is, in many cases, better than what I would have produced on my own in the time available. But the muscle the designer of 2026 needs is a different muscle than the one I trained for the past quarter-century, and I am training the new one in real time, with the awkwardness that comes from training any new muscle in public.

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 a 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.

By the end of the foundations stretch I had a Product Overview, requirements documents for both the web and mobile apps, technical architecture plans for both, and release plans for both. I had a description of the user the product was for, the problem it was solving, the way it was going to make money, and the order in which the features were going to ship. I had answers to questions I had not realized I had been carrying.

I then took the co-worker's other piece of advice and ran the whole stack of documents past ChatGPT for a critique. 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.

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 last piece of the work-so-far was getting Gearious onto the internet. A web presence. A surface I could point people to. Fellow adventure riders who care about ounces and packing — that's the audience I wanted to start with, and pointing them to a private prototype on my laptop was not going to work.

The landing page was where the let go of the pixels advice got tested hardest. I had, again, a vision in my head of where it needed to land — a specific tone, a specific feel, a specific kind of restraint. I had to set that vision aside. I worked on the voice instead — what I wanted the page to sound like to a rider who didn't know me, what would make them stay past the first scroll, what teasers to include and what to hold back. I worked on the feature messaging — what was worth saying at a landing-page altitude and what was too deep for that surface. And I worked on the question of whether the page should include any actual functioning interface, or just describe what was coming.

It includes a working mini-interface. A small, scoped version of the planning experience, embedded in the page, that lets a visitor drag two or three items between two bags and watch the balance indicator update. Just enough to prove there is something real behind the description. The decision to include it cost me many evenings of work, but I think it does more for the page than any amount of static visual polish would have. The page does not just say the product exists. It shows that, in some small way, it already does.

The landing page is live! Gearious is, as of the publication of this post, A Thing On The Internet — which is, in 2026, the minimum threshold for officially existing.

The folder is on a shelf, but it has nothing in it that isn't also on the internet now.

This is where the work stands today.

A foundations layer of product, requirements, architecture, and release documents. A working prototype that runs the core planning loop end to end. A published landing page that introduces the product to the world. Two mentors I am still learning from. And a slowly-growing sense of what it means to be a designer who builds — really builds — in 2026.

In future posts I'll share some of the artifacts. The documents. The prompts that worked and the ones that didn't. The landing page in detail. The architecture decisions I'm second-guessing. The mistakes I'm sure I'm about to make, in real time, where you can watch me make them.

My aim is to design and build out in the open. The reason ideas sit in folders for fourteen years is partly because the tools aren't there yet, and partly because nobody else is showing the work. The tools are here now. The least I can do is show the work.