From Idea to Linear Plan: How I Scope a Side Project Before Any Code Gets Written
Part 1 of a three-part series on running a one-person product studio. Part 2 covers the agent crew that builds the thing. Part 3 covers the GitHub-and-Coolify loop that ships it.
The single biggest predictor of whether a side project of mine ships or dies is how much work I do before any code gets written.
Not the brainstorming. Brainstorming is fun and cheap and produces nothing. I mean the unglamorous middle step between "I have an idea" and "I'm building it" - turning a vague intuition into a sharp product hypothesis, then turning that hypothesis into an MVP plan with milestones concrete enough that someone other than me could execute against them.
That last clause matters more than it sounds, because in my current setup, "someone other than me" is a small team of agents. But honestly it mattered before that too. The Linear projects I scoped well got finished. The ones I scoped poorly turned into a graveyard of half-built features and a domain I'm still paying renewal on.
This is the part of my workflow that runs entirely between me and a model. No agents yet. No tickets yet. Just me and Claude in a long conversation, going from idea to plan.
Step 1. The product conversation
I open a long-form chat with a strong reasoning model and we chat out the idea.
The point of this conversation is not to get an answer. It's to expose the parts of the idea I haven't actually thought about yet. A good model will push back on weak parts of the pitch the way a good co-founder would, if I'm prompting it to do that, and I am explicitly prompting it to do that. It will ask me tough questions and I just had to scrap an idea I've been wanting to build for years from the feedback it gave me. I was pretty bummed out afterward.
A few things I've learned to insist on:
Direct pushback. Not validation. I tell the model up front that I want it to argue against the weakest parts of the idea, not encourage me. "What's wrong with this?" gets better answers than "what do you think of this?"
Comparable products, named. I make the model name three to five existing products in the space and explain how my idea would beat each one. If the answer is hand-wavy, the idea is hand-wavy. The exercise of naming concrete competitors and writing a one-sentence differentiator against each is the cheapest reality check in the world.
The "why now" question. Why hasn't someone built this already, or if they have, why does it deserve another entrant? Sometimes the answer is honest ("everyone who could build this is busy at a big company"). Sometimes the answer is "they have, and they're doing fine, and you should not build this." I'd rather find out in a Tuesday-afternoon chat than after I've burned a bunch of time (or tokens) on it.
One sharp differentiator, stated as a sentence. Not three differentiators. One. If I can't compress the reason this product is better than the alternatives into a sentence, the product isn't ready to plan yet.
For Encroach, the differentiator went through about four versions before it landed at "a territory-claiming game where the territory is the route you actually ran, not a generic GPS grid." That sentence is now the load-bearing test for every feature decision: does it sharpen this differentiator, or does it dilute it?
This conversation usually takes a couple of hours over a few sittings. I do not rush it. The cost of skipping it is enormous; the cost of doing it is one afternoon.
Step 2. The MVP plan
Once the product hypothesis is sharp, I move to the same model but in a different mode: planning.
The output I want from this step is a list of milestones, ordered, each one shippable on its own. Not a Gantt chart. Not a feature list. Milestones that each represent a usable thing, even if the usable thing is small.
For a typical side product the shape ends up roughly:
Foundation milestone (account creation, the smallest possible end-to-end flow that proves the idea works at all).
The differentiator milestone (the one feature that makes this product distinctive — built early, even if rough).
Polish-the-differentiator milestone.
The first real-user milestone (whatever you need to put it in front of three friends who'll actually use it).
Operational readiness milestone (this is the one most people skip; more on this in a moment).
Launch milestone (landing page live, signup flow real, first external traffic).
The exact list varies. The discipline of milestones-as-shippable-things doesn't.
A couple of patterns I've come to insist on:
The differentiator gets built early, not last. The strongest temptation in MVP planning is to ship the boring stuff first because it's well-understood, and save the "hard" differentiator feature for later. This is exactly backwards. If the differentiator turns out to be harder or duller than expected, you want to find out on day fifteen, not day sixty after you've built a beautiful house around it.
Also, with the use of agents, it's much quicker to work through the hard stuff early.
Operational readiness is its own milestone. Observability, error tracking, basic deploy automation, the smallest possible monitoring you'd want before letting strangers near the thing. Most plans I see treat these as something to tack on at the end. They are not. They are a milestone, and they go before the launch milestone, not after. I have a Paperclip skill specifically for spinning up the observability stack: Prometheus, Grafana, Sentry, OpenObserve, structured logging, because every single project needs the same thing and there's no reason to design it from scratch each time. Same for a few other recurring milestones (the Coolify staging setup, the Cloudflare Pages landing page, the Plausible analytics wiring). Skills, not bespoke planning.
Each milestone has an exit criterion stated as a behavior. "Foundation milestone is done when a user can sign up, log in, perform the core action once, and see it persisted across a logout." Not "auth complete and basic CRUD done." The behavior phrasing is what makes the milestone shippable rather than aspirational.
Step 3. Loading the plan into Linear
This is where the planning leaves the model conversation and becomes a real artifact in a real tool.
The plan goes into a new Linear project. One project per side product. The structure I use:
Linear project = the side product (Encroach, BillMyCommits, HappyClients).
Milestones in Linear = the milestones from the plan. Each one has the behavior-based exit criterion in its description.
Issues = the work to get a milestone to its exit criterion. Each issue is sized to roughly a day of work or less.
Labels = lightweight tags. The most important one, which I'll cover in detail in part two, is
paperclip-ready, a flag that says "this issue is fully specified and an agent can pick it up." Issues without that label are mine, or aren't ready yet.
The skills I use here are workflow shortcuts I've built up over time: a milestone-creation skill that takes the plan output from step 2 and produces Linear milestones with proper descriptions and exit criteria; an observability-setup skill that produces the standard observability milestone with all the issues underneath it pre-filled; similar skills for Coolify staging setup and the launch-readiness checklist. A skill to use the linear terminal client instead of the MCP server (I find it faster and it seems to consume less context). These aren't fancy, they're glorified templates, but they save me an hour each time and, more importantly, they keep my projects structurally consistent. Every project has the same shape, which means every project is legible the same way.
Once the plan is loaded, the Linear project is the source of truth. Not the chat with the model. Not a Notion doc. Linear. Everything that happens from here on out: agent work, my own work, status updates, demo recordings, references Linear issues and milestones.
Why this part matters more than the agents
The strong temptation, especially if you're excited about agents, is to skip ahead and let the agents do the planning too. I've tried this. It doesn't work, for a specific reason.
The planning conversation is where my judgment is highest-leverage. It's where I'm deciding what to build and why, and those are decisions that depend on context I have and the agent doesn't, about my time, my market, my appetite for maintenance, my honest assessment of which competitors I can actually beat. I want the model in that conversation as a sparring partner. I don't want the agent system doing it for me, because the system would optimize for plausible plans rather than plans I'll actually finish.
The work done by the agents later is routine. The upstream planning is judgment. Putting an hour of careful judgment in at the top is the difference between an agent crew building the right thing well and an agent crew building the wrong thing very efficiently.
What's next
Once the Linear project exists with milestones, exit criteria, and a backlog of issues, the agents can come in. That's part two: spinning up a Paperclip subteam: a PM, a marketer, an engineer, with the routines that keep them honest and the boundaries that keep me in control of the parts I should still own.
Part three covers the execution loop itself: how the engineer agent's PRs get reviewed via Coolify previews, how a separate marketing repo lets the agents ship landing-page changes without needing access to my local machine, and how I keep my actual touch points down to two tools: Linear and GitHub, while the rest runs itself.
If you're new here: I'm Aaron, I run Square Bracket, a one-person product and dev consulting studio in Vienna, and I'm building BillMyCommits, Encroach, and HappyClients on the side while doing client work full time. The whole reason I built this workflow is that I don't have time to do it any other way.