One person,
four projects.

Solo developers do not fail because they cannot build things. They fail because they say yes four times in one month and then spend the next month apologising.

I know roughly what a week contains now. The numbers are unglamorous and they are the most useful thing I have learned.

01Where the week actually goes

A 40-hour week is not 40 hours of building. For a project in active development, mine looks like this:

• 18 hours — code. Actual typing, testing, fixing. Less than half.
• 8 hours — communication. Updates, questions, calls, the message that becomes a 40-minute thread because a requirement was ambiguous.
• 6 hours — environment. Deploys, certificates, backups, the thing that broke at 2am. This never reaches zero.
• 4 hours — reading and deciding. Docs, APIs, "should this be a job queue or a cron".
• 4 hours — admin. Quotes, invoices, the client who has not paid.

That leaves about 18 hours of real production per week, per person. Which is a useful number, because it means a four-week project consumes roughly 72 hours of actual building — and most quotes are written as if it consumes 160.

02Why the second project costs more than the second project

Two projects is not 2× the work of one. It is closer to 1.4×, because context switching has a tax: you lose the mental model of the codebase when you leave it, and rebuilding that model takes twenty minutes to an hour.

Three projects is where it breaks. Not because 3 × 18 is impossible, but because all three will need something urgent in the same week, and you can only answer one.

So my real capacity is:

• One project in active build — the one that gets the good hours
• One small project or retainer — the predictable, low-context work
• Nothing else, except reading and quoting

That feels like under-selling. It is the only reason deadlines hold.

03The scheduling rule that saved me

Every project gets a start date, not just an end date. The start date is the promise; the end date is the estimate.

When someone says "can you start Monday", the honest answer is often "I can start on the 18th". That sentence is uncomfortable for about three seconds and saves a month of bad work. Clients respect a queue far more than they respect enthusiasm.

And the queue has a second benefit: it makes the work visible. "Two people ahead of you, starting the 18th" is a stronger signal of quality than any testimonial.

04What I do with the 4 hours of admin

Batch it. Quotes on Monday morning, invoices on the first of the month, updates drafted in one sitting and sent at intervals. Interrupting a build to write an invoice costs more than the invoice.

Email is checked twice a day, not continuously. I tell clients that on day one, in writing, so it never reads as neglect.

05The math for saying no

When a project arrives and the queue is full, there are three options, ranked:

1. A later start date. Costs the client waiting, costs you nothing.
2. A smaller first phase. Costs the client scope, keeps the relationship.
3. A no. Costs the client nothing but a day, costs you nothing at all — and occasionally they come back in six months.

What is never on the list is "squeeze it in". That is borrowing against a week that does not have the hours, and the interest is paid by whoever is already in the queue.