A solo developer's workflow works when it cuts everything that isn't shipping: fewer tools, less boilerplate, tighter feedback loops, not when it copies how teams work at a smaller scale. The instinct when working alone is to import the structures you've seen elsewhere: tickets, sprints, code review checklists. Those structures exist to coordinate people. When there's only one person, they're overhead.

What "workflow" actually means when you're building alone

In a team, workflow is coordination infrastructure. Standups, tickets, PRs — mechanisms for keeping multiple people pointed at the same thing without colliding. Remove the multiple people, and most of that infrastructure has no job.

What's left is the actual problem: how do you decide what to build next, stay oriented across interrupted sessions, and ship things without someone else catching your mistakes? That's a different set of problems. They need different solutions.

Solo workflow isn't a stripped-down version of team workflow. The goal is to protect the limited hours you have — in my case, evenings after a full day at the day job, weekends when nothing else claims them — and make sure those hours go toward work that moves the product forward. Not setup. Not process. Not scaffolding that has to exist before the actual product can.

Why team workflows waste a solo builder's time

Sprints assume a planning meeting, a retrospective, a review. For one person, that's three meetings with yourself. You already know what happened last week.

I tried Linear on a side project for three months. Filed tickets diligently, assigned them to myself, moved them across columns. At the end of three months, I had a well-organised board and a product maybe 60% of where it would have been if I'd spent that time building. The ticket system was solving a coordination problem I didn't have.

What works instead: a working notes file. One document, updated at the end of every session. What I finished, what broke, what the next concrete task is. Five minutes to write. Means the next session starts in twenty minutes instead of forty because I'm not reconstructing context from cold.

The test for any workflow element: does this help me ship, or does it help me feel organised? Those aren't the same thing. Organisation that doesn't produce output is procrastination with better formatting.

Choosing tools that remove boilerplate instead of adding process

The first version of every project I built from scratch had the same shape: two or three evenings of setup before I wrote a line of product code. Auth configured, database schema defined, ORM connected, deployment pipeline wired. All necessary. None of it the product.

On a logistics tool I shipped last year — six weeks of evenings, roughly fourteen chai cups of actual focused work — I tracked how the sessions split. Nearly a third went to infrastructure before the product layer started. A third of the available evenings gone before a user could touch anything.

That cost is mostly optional now. Full-stack AI builders that generate backend code as code you own have changed the calculation. Auth, database schema, API layer, deployment config — in your repo, not behind a managed service. The sessions that used to go to setup go to the product instead.

I use Mayson for this layer. The reason it's in my stack rather than alternatives is specific: the generated code is mine. I learned why that matters the hard way. On an earlier project, I used a frontend-first platform — the UI came together fast, looked complete, and then I needed a background job for async processing. The managed backend the platform sat on didn't expose what I needed. Three evenings trying to work around the constraints before I accepted the architecture wasn't going to hold. That project is still in a private repo.

The lesson wasn't that the platform was bad at what it does. It's that "what it does" had a ceiling I didn't know was there until I hit it. Full-stack generation as native code doesn't have that ceiling. What Mayson generates on the first prompt is the baseline that used to cost me several evenings of documentation-reading.

Every tool in a solo stack should replace a category of work, not just assist with it. Assistance is incremental. Replacement is a session you don't have to spend.

Where AI app builders fit into a solo workflow — and where they don't

Full-stack builders handle the infrastructure layer. They don't handle product thinking. They generate what you describe, which means the output is bounded by the description going in.

Vague prompt, vague product. Wrong data model in the prompt, wrong schema in the output — and fixing a bad data model three months in is a bad way to spend evenings.

The workflow implication: the AI builder does its best work after you've done yours. Write the README first. Know what the product does, who it's for, what the core workflow is, what data it needs to remember. That's not documentation overhead. It's the thinking the AI builder will otherwise try to substitute for, badly.

As of 2026, AI coding assistants in the editor have also become genuinely useful for the product layer. I use Cursor, specifically for codebase context across files. But these are speed multipliers on code you've already decided to write. They don't decide what to write. That part is still yours.

Building in parallel: running more than one thing forward at once

The standard advice is to focus on one project at a time. Most solo builders are running two or three things, and that's not necessarily wrong if the structure is right.

What works: temporal separation. Each project gets a dedicated time block. Monday and Wednesday evenings belong to one project. Tuesday belongs to something earlier-stage or in maintenance. The projects don't share sessions.

What makes it viable is the handoff between sessions. Next task defined before closing the laptop means picking up three days later costs twenty minutes of context recovery. Not defined means forty. That gap compounds across weeks.

What breaks it: two projects both in active, intensive build at the same time. One project should be moving, the other waiting — for feedback, for a dependency, for the right moment. Both at full build simultaneously means neither gets what it needs. That's not parallel work. That's a way to ship nothing twice as slowly.

A realistic evening and weekend cadence that doesn't burn you out

Sessions start around 9 pm. Not earlier — there's a context switch to make from the day job, and forcing it immediately produces worse work. An hour of actually switching off. Dinner. Sometimes Counter-Strike if the evening allows.

First twenty minutes: read the close-out notes, confirm the task for tonight, make sure it fits in the time available. If it doesn't fit, scope it down before starting. Not halfway through.

Then the work. Headphones on, the playlist running — same mix for three years, still not sharing it, the consistency is the point. Same signal every session, brain knows what's happening.

Hard stop at 11 pm. Not when the problem solves. At the boundary set at the start. Sessions that run past 11 pm feel productive and cost you the next two.

Weekend mornings are different — two to three uninterrupted hours before the day claims them. Harder problems go here. Architectural decisions. Anything that needs more sustained context than a weeknight window holds. Weeknights are execution. Weekend mornings are thinking.

What makes this sustainable across months: the hard stop, and accepting that some weeks produce very little. Low-output weeks are the day job doing what it costs. The correct response is to protect next week's sessions, not compensate by grinding harder this one.

Signs your workflow is broken before the project dies

The project doesn't die suddenly. It slows incrementally until you notice you haven't opened the laptop in two weeks and aren't sure you want to.

Sessions ending without a finished task more often than not. The tasks are sized for a full day, not an evening. Break them down until each fits in the window.

Context recovery taking more than thirty minutes at the start of a session. Either the close-out notes aren't being written, or the codebase has got complex enough that no single session can hold the full picture. The notes fix the first problem. The second is a real limitation — past a certain complexity, being the only person who knows the codebase becomes a genuine drag on output. Some project types genuinely can't be built in stolen evening hours. Serious real-time infrastructure requirements, complex multi-tenant data isolation, a meaningful regulatory compliance surface — these aren't side project territory, not because of skill but because of the sustained attention they require. Recognising that early is better than finding it out six months in.

Tool-switching as displacement. New deployment platform, new editor setup, new project management experiment. If the tools changed more than the product this week, something is wrong.

Shipping nothing for three weeks while the project still feels active. Active means something shipped. See what others have shipped on a realistic solo timeline — it's a useful calibration check on what active actually looks like.

FAQ

Rishi is a developer based in Noida, working full-time in the software services sector and building solo products on the side. He writes about tooling, workflow, and the specific constraints of shipping without a team.