Solo dev routine: how I organize my day without burnout

The problem of being everything at once

An independent dev isn’t just a dev. They’re salesperson, customer service, finance, marketing, and project manager. All in the same person, on the same day, at the same desk.

When I started working solo, I did everything at the same time. Coded in the morning, answered a lead mid-code, stopped to post on Instagram, went back to code without remembering where I left off, and at the end of the day felt like I worked 10 hours without delivering anything concrete.

The problem wasn’t lack of effort. It was lack of structure. Without a defined routine, every task competes with all the others for attention. And context switching is the biggest productivity killer for anyone who programs.

After months of adjusting, I landed on a routine that works. It’s not rigid. It’s not perfect. But it lets me deliver projects with quality, prospect clients, and still have a life outside of work.

Time blocks: the foundation of everything

I divide the day into 2-3 hour blocks with a defined function. I don’t mix blocks. When I’m coding, I don’t answer lead messages. When I’m prospecting, I don’t open the editor.

My typical split:

Morning (8am-12pm): code. The 4 most productive hours of the day go to development. No meetings, no WhatsApp, no email. The phone goes on focus mode. If the client needs something urgent, they’ll see my response at noon.

This block is sacred. It’s where the work that pays the bills happens. Each interruption in this period costs 15-20 minutes to regain the mental context of the code. In a morning with 3 interruptions, I lose almost 1 hour just getting back into the reasoning. With zero interruptions, I deliver in 4 hours what used to take 6.

Lunch (12pm-1:30pm): real rest. I don’t eat at the computer. I don’t “rest” watching tech reels on Instagram. I leave the desk, eat, and do something that doesn’t involve a screen. It seems unproductive, but the quality of the afternoon code depends directly on this break.

Afternoon (1:30pm-4pm): light tasks and communication. I respond to clients, review copy, adjust CSS, deploy, update documentation. Tasks that need attention but not deep concentration. This is the block where meetings happen (when unavoidable).

Late afternoon (4pm-5:30pm): prospecting and content. I send messages to leads on Instagram and WhatsApp, write blog posts, update the portfolio. This block is the investment in the future of the business. If I skip it every week, in 2 months I have no client pipeline.

The mistake of working until “it’s done”

Solo devs have a dangerous tendency: working until the project is finished. “Just one more feature.” “Let me just fix this bug.” “I’ll finish this page and stop.” And before they know it, it’s 10pm and they’ve been at the computer since 8am with a 30-minute lunch.

This works for 2-3 weeks. Then quality drops, bugs increase, creativity disappears, and you start hating the work you chose to do. Burnout is the mathematical consequence of spending more energy than you recover.

My rule: at 5:30pm, the computer closes. It doesn’t matter if the feature is 90% done. Tomorrow it’ll be easier to finish because I’ll be rested. Code written while tired generates bugs that take longer to fix than the time you “saved” by staying late.

Exceptions exist. Tight deadlines, production bugs, next-day deliveries. But an exception that becomes routine is a planning problem.

Prospecting isn’t optional

The most common trap for a solo dev: has a project, stops prospecting. The project ends, there’s no pipeline, goes without income for 2-3 weeks until closing the next one. Repeats the cycle.

Prospecting needs to happen every day, even when you’re busy with a project. 30 minutes per day is enough. 5 Instagram messages, 3 WhatsApp follow-ups, 1 blog post per week.

In my prospecting model for aesthetic dentistry clinics, the cycle works like this: I identify dentists who post aesthetic cases on Instagram, send a personalized DM, follow up on WhatsApp, and use my prospecting LP as supporting material.

This daily 30-minute effort ensures that when the current project ends, I already have 2-3 conversations in progress. No gap between projects, no desperation to close anything. I detailed the full solo operation model in the post about working as an independent dev without becoming an agency.

Tools that organize without overcomplicating

I don’t use Notion with 15 databases, or Trello with 8 columns, or a complex productivity system. The simpler the tool, the higher the chance I actually use it.

What I use daily to accelerate development with AI is detailed in the post about delivering projects faster with AI. But even with AI, structure matters more than speed.

An .md file per project. Each project has a markdown with spec, delivery checklist, meeting notes, and backlog. It lives in the project repository. When I open the code, the context is right there.

Google Calendar. Time blocks marked as events. The morning code block appears as “DEV [project name].” The prospecting block appears as “PROSPECTING.” It seems silly, but seeing the blocks on the calendar prevents me from scheduling a meeting at 9am.

Lead list in .md. Each lead is a markdown file with name, contact, conversation status, and message history. Simple, searchable, no extra tool. My leads are organized in ~/Desktop/leads/ with Claude Code’s sales skill managing the format.

Timer. I don’t use strict Pomodoro (25 minutes is too short for coding), but I use a 90-minute timer to ensure breaks. When the timer goes off, I stand up, drink water, come back. Without a timer, I go 3 hours without standing and my back complains later.

Meetings: less is more

Meetings are the biggest time theft for a solo dev. A 1-hour meeting in the middle of the morning doesn’t cost 1 hour. It costs 1 hour + 30 minutes of preparation + 20 minutes to regain code context. That’s 2 hours for a 60-minute meeting.

My meeting rules:

Afternoons only. Never during the morning code block. If the client can only do mornings, I negotiate this exception knowing I’ll lose the productive morning.

30 minutes maximum. Most meetings can be resolved in 30 minutes with a defined agenda. “Let’s align on the project” isn’t an agenda. “Approve the homepage layout and define hero copy” is an agenda.

If it can be a message, it doesn’t become a meeting. “Did you approve the layout?” is a message, not a 15-minute call. I reserve meetings for decisions that need live conversation: project kickoff, proposal presentation, delivery review.

With AutoPars, communication with the client was primarily asynchronous. Updates via message, questions via voice notes, biweekly 30-minute meetings to align priorities. The project moved faster with fewer meetings, not more.

Physical health isn’t extra

It seems out of context in a post about dev routine, but physical health directly impacts work capacity. A dev who doesn’t sleep well, doesn’t exercise, and eats poorly produces less, makes more mistakes, and burns out faster.

What I incorporated into my routine that made a difference:

• Sleeping 7-8 hours (not 5-6 thinking it’s productive)
• Exercise 3-4 times per week (doesn’t need to be a gym, walking counts)
• Breaks every 90 minutes (stand up, water, movement)
• Lunch away from the computer

I’m not being preachy here. I noticed a direct correlation. In weeks when I sleep poorly, my code output drops visibly. Bugs I wouldn’t make while rested appear. Architecture decisions that seemed good at midnight turn out to be bad the next morning.

The day that doesn’t work

Not every day follows the routine. Some days the client sends an urgency at 9am and the morning code block is gone. Some days energy doesn’t show up and the prospecting block becomes scrolling the phone. Some days everything goes wrong.

The routine isn’t to eliminate bad days. It’s to ensure most days are productive. If 4 out of 5 weekdays follow the structure, the fifth can be chaos without compromising results.

What can’t happen is 5 out of 5 days being chaos. If that becomes the pattern, the problem isn’t the day. It’s the routine that needs adjustment.

• Is your morning code block protected from interruptions?
• Do you prospect at least 30 minutes per day, every day?
• Do your meetings have a defined agenda and maximum duration?
• Do you stop working at a fixed time?
• Do you take breaks every 90 minutes?
• Do you sleep 7-8 hours per night?
• Is your organization system simple enough to use every day?

The solo dev who lasts organizes the hours they work, not adds more of them. Simple structure, executed with consistency, beats any elaborate system you abandon in 2 weeks.