The Solo Developer's AI Grid Setup: Ship a Feature a Day
An opinionated solo developer workflow using a four-pane AI coding grid to plan, execute, test, and ship a small feature every working day.
April 18, 2026 · 6 min read
The problem
Solo developers — indie hackers, freelancers, technical founders — live under a particular pressure. There is no pair to bounce ideas off, no code reviewer to catch mistakes, no QA team to test before release. Every hour not spent shipping is an hour of runway burning. The temptation is to work longer hours, which stops working after about week three. The real answer is to get the workflow so tight that a full feature — planning, code, tests, a deploy — fits into a single focused work block, and then do that every day.
AI coding tools should help with this, and in theory they do. In practice, a solo dev with a single terminal and one agent ends up spending half their day supervising the agent and the other half context-switching to other tools — linters, docs, the API of their own half-forgotten module from last month. A grid fixes this by putting all the repeated tools in visible panes. You stop Alt-Tabbing. The day compresses.
This page is opinionated. It describes the setup I use and why. You will want to modify it. That is expected.
The grid setup
2x2 grid on a single monitor. I have used this on both a 27" desktop and a 16" laptop; it scales down painfully at laptop size but works. Pane assignments:
- Top-left, the biggest mental pane: Claude Code, rooted at the current project. This is where the day's main work happens.
- Top-right: a second Claude Code pane, rooted at the same project, for side errands — writing docs, dashing off a commit message, checking "how does this library work again" without polluting the main pane's context.
- Bottom-left: a shell pane.
git,npm run dev,curl, log tailing. This is my main verification surface. - Bottom-right: a scratch pane running
nvimon a daily notes file. Every day I open the space, I scroll to the top of this file and type three things I want to ship today. At the end of the day I write one paragraph about what happened.
One space per project. I have maybe six spaces in SpaceSpider across active projects. Opening a space means opening the full context of that project — same four panes, same folder, same mental mode.
Step by step
- Morning. Open the space for whatever I'm working on today. The four panes come back to their last layout. I don't start agents yet.
- In the bottom-right notes pane, write the three things I want to ship today. They should be small. "Add email confirmation to signup" is a good one. "Rewrite auth" is not.
- In the bottom-left shell pane,
git pull,git checkout -b day/apr17-email-confirm,npm installif anything changed. Confirm the build works before I touch it. - In the top-left pane, start Claude Code. Paste the first task: "Read
src/auth/signup.ts. Add an email confirmation flow: after signup, send a token, block login until the token is confirmed. Use the existingsendgridclient insrc/lib/email.ts. Write tests." - While Claude works, in the top-right pane I start a second Claude instance and paste the second task: "Update
README.mdanddocs/auth.mdto mention the new email confirmation step. Don't touch code." - When Claude finishes the main task, the shell pane is where I verify:
npm test, thennpm run dev, then actually click through the signup flow in a browser. If it works, commit. If it doesn't, I paste the failure back into the top-left pane and ask for a fix. - Repeat steps 4-6 for the second and third things on today's list. If I finish early, I use the extra time for a small refactor or to knock out a lingering TODO, not to start something new. Finish early, stop early.
- Deploy. In the shell pane:
git push, then whatever my deploy command is. For me that's usuallyfly deployorvercel --proddepending on the project. - End of day. In the notes pane, one paragraph: what I shipped, what I learned, what's blocked. This paragraph is the cheapest, most useful habit I've built in two years of solo work.
- Close the laptop. The space is persisted. Tomorrow it all comes back.
What this unlocks
Consistency. Shipping one small feature a day — even on bad days — compounds. A year of this is 200+ features, which for a one-person product is more than enough to build something real.
Less decision fatigue. The grid makes "what do I do next" answerable: look at the notes pane. The shell is for verifying. The Claude panes are for executing. No open-ended questions about which tool to reach for.
A built-in daily log. The scratch pane's notes file is a honest-to-god engineering journal. I have four years of these for my main project now; when a bug appears that "I swear we fixed before," I grep the journal and usually find the fix.
Faster context-recovery after breaks. Taking a week off and coming back to one terminal is disorienting. Coming back to a saved space with four panes that literally show you where you left off is not.
Variations
Single-pane minimalism. Some solo devs find a grid too busy. They run one big Claude Code pane and keep a separate tmux session for shell. This works if you have the discipline to not start a second project in parallel; many don't.
3-pane for aesthetic reasons. Skip the top-right side-errands pane. You get more room for the main pane and a cleaner grid. The tradeoff is that you end up polluting the main pane with "help me write this commit message" requests, which sometimes derails its context.
The 1+3 consulting layout. If you're freelancing on multiple client repos in the same day, use a 4-pane layout where each pane is a different client. Cheap context-switching — clicking a pane shows that client's working tree. Not great for deep work; good for inbox-driven days.
Caveats
This is my workflow. I have seen engineers bounce off it because they prefer vim in full-screen mode, or because they hate monitoring two Claude panes at once, or because their work is fundamentally not "small features" but long research sessions. All valid. The grid is a tool, not a religion.
"A feature a day" is aspirational. Some days the feature is tiny — fix a typo, update a dep. Some days it's ambitious and doesn't ship. The metric matters over weeks, not days.
Solo dev plus AI agents is a lonely combination that some people find unexpectedly bleak. The agents are useful but they are not colleagues. Join a community, attend a meetup, get a rubber duck. Grid discipline does not fix that.
FAQ
Do I need four panes? Isn't that too many? Start with two. Add the third when you notice yourself Alt-Tabbing frequently. Add the fourth when you realize you've been mentally juggling your day's goals instead of writing them down.
What if my project needs more than one CLI? Add panes. SpaceSpider supports up to 9. I personally top out at 4 before the cognitive load exceeds the benefit, but that's a personal limit.
Can I use this setup on a laptop screen? Yes, but expect to squint. The scratch notes pane gets too small to be useful. I've used a 3-pane (1 big Claude, 1 shell, 1 scratch) variant on laptop trips and it works passably.
Related reading:
Keep reading
- Run Claude, Codex, and Qwen in Parallel on the Same CodebaseA workflow guide for running three AI coding agents at once in a SpaceSpider grid, with each pane working on a different slice of the same repository.
- Multi-Model Code Review: Catch What Any Single AI MissesA review workflow that pipes the same diff through three AI coding CLIs side by side, surfacing bugs and smells that any one model would overlook.
- Agentic Refactoring: Break a Big Refactor Into Parallel PanesA tutorial for splitting a large refactor across multiple AI panes, coordinating through directory-scoped tickets, and merging results without breaking the build.
- Debugging With AI: Three Hypotheses in Three PanesA debugging workflow that runs three parallel AI agents on the same bug, each exploring a different hypothesis, with a shared shell for log inspection.
- Frontend and Backend AI Pair on the Same Feature, Side by SideA full-stack development workflow with dedicated AI panes for the frontend, the backend, and a live API tester, all sharing the same repo and feature branch.
- Cost-Optimized AI Coding: Cheap Model for Grunt Work, Smart Model for Hard CallsA cost-aware development workflow that routes routine edits to cheaper AI CLIs and reserves premium models for architecture decisions and hard debugging.