How I Manage 10+ Retainer Clients Without a Project Manager

I work four days a week. I manage ongoing retainer clients. I don’t have a project manager, a VA, or a team. It’s just me.

That sounds either impressive or insane depending on your perspective, and honestly some weeks it feels like both.

But it works. Not because I’ve found some perfect system, but because I’ve built a routine that stops things falling through the cracks. Most of the time.

Here’s what that actually looks like, day to day. The good bits and the messy bits.

The morning check (15 minutes)

Every working day starts the same way. Coffee, then dashboard.

Before I open my email, before I open Slack, before I look at anything else, I check my client dashboard. This takes about ten minutes and it gives me the full picture:

• What new requests came in overnight?

• What’s waiting on a client approval?

• What’s in progress and needs my attention today?

• Is anything overdue or stuck?

This is the single most important part of my day. By the time I’ve finished my coffee, I know exactly what I’m working on and in what order. I’m not reacting to my inbox. I’m looking at a prioritised list of actual work.

The difference this makes compared to starting the day in your email is hard to overstate. Your inbox is a firehose of everything. Your dashboard is a filtered view of just the work.

How requests come in

Every client has a portal link. When they need something done, they go to their link and submit a request. It lands in my dashboard alongside everything else.

This is non-negotiable. I don’t accept requests over email (apart from genuine emergencies, which are rare). I don’t accept them over WhatsApp. I politely redirect people to their portal every time.

This took about two weeks to establish with each client. The first couple of times, they emailed me a request and I replied with something like: “Absolutely, happy to do that. Can you pop it into your portal so I’ve got it tracked? Here’s your link.”

After a few repetitions, they just started doing it without being asked.

The reason this matters so much is that it gives me one place to look. I’m not checking email, WhatsApp, Slack, and my notes app to piece together what needs doing. It’s all in one place.

Prioritising across clients

This is the bit that most solo developers struggle with, and I’m not going to pretend I’ve got it perfectly figured out.

When you have ten clients, you’ll typically have 15-25 open requests at any given time. They’re not all urgent. They’re not all the same size. And they definitely don’t all come from clients who are equally patient.

Here’s my rough framework:

Do first: Anything the client is actively blocked by. If their contact form is broken or their site is down, that’s today’s priority regardless of what else is on the list.

Do next: Approved requests in order of when they were approved. If a client approved an estimate three days ago, that comes before one approved yesterday. Simple queue.

Do later: New requests that haven’t been estimated yet. I try to get estimates out within 24 hours, but the estimating itself isn’t urgent work. I batch it. Usually I’ll review all new requests at the end of the day and send estimates in one go.

Flag it: If something has been sitting for more than a week without movement, I flag it and check why. Usually it’s waiting on something from the client (a file, a decision, copy). A quick comment on the task is enough to nudge them.

This isn’t a sophisticated system. It’s a queue with common sense applied on top. But it works because everything is visible. I can see at a glance what’s been waiting longest and what needs attention.

The estimate and approval loop

Every request gets an estimate before I start work. Every single one.

Sometimes the estimate is “30 minutes, covered by your retainer.” Sometimes it’s “£200, here’s what’s involved.” Either way, the client sees it and approves it before I write a line of code.

This protects both sides. The client is never surprised by an invoice. I’m never doing work I can’t bill for. And if there’s a disagreement about scope later, we both have a timestamped record of what was agreed.

The approval step also acts as a natural prioritisation tool for the client. When they see the estimate, they sometimes come back with “actually, let’s hold off on that one” or “can we do a smaller version?” That’s a healthy conversation to have before the work starts, not after.

End of day (10 minutes)

Before I finish for the day, I do a quick sweep:

• Update the status on anything I worked on today.

• Send any estimates for new requests that came in.

• Check if anything needs a nudge (waiting on client input for too long).

This takes ten minutes, max. But it means that when I start the next morning, my dashboard is accurate. And if a client checks their portal in the evening, they can see that things moved forward.

The bits that are still messy

I’m not going to pretend this is all smooth sailing. Here’s what still catches me out:

Context switching. When you’re bouncing between ten different client sites, different tech stacks, and different codebases, the mental overhead is real. I try to batch work by client (morning on one client, afternoon on another) but some days that goes out the window.

Scope conversations. Some clients are great at submitting clear, well-defined requests. Others send you “make the website better” and expect you to figure out the rest. Getting better at asking clarifying questions through comments on the task has helped, but it’s still a time sink.

The quiet clients. Some clients go weeks without submitting anything, then send five requests on a Tuesday afternoon. This is fine in theory, but it messes with your planning. I’ve started checking in with quiet clients proactively once a month to see if there’s anything on their list. It spreads the work out and keeps the relationship warm.

Saying no. When you’re at capacity, new requests from existing clients can feel like a burden rather than an opportunity. Learning to say “I can get to that next week” instead of cramming it in today is something I’m still working on.

What makes it possible

If I had to boil it down, managing ten clients solo comes down to three things.

One system for everything. Not email plus WhatsApp plus a notebook. One place where all requests live, all statuses are visible, and all approvals are recorded.

A routine. The morning check and end-of-day sweep are non-negotiable. They take 25 minutes combined and they’re the reason things don’t fall through the cracks.

Boundaries. Working four days a week means I can’t say yes to everything. That forces me to prioritise properly, estimate accurately, and push back when I need to.

It’s not perfect. But it works. And the clients are happy because they can see what’s happening without having to chase me.

The portal I use for my own clients is TaskClarity. I built it because nothing else quite did what I needed: a simple place for clients to submit requests and a dashboard for me to manage all of them. If you’re a solo developer juggling retainer clients, it might be worth a look.