If you are paying an agency for a "dedicated" developer, you should be getting most of one person's working week on your product. Often you are not. Developers at agencies are commonly split across two or three clients, and "dedicated" in a proposal can mean anything from a full-time assignment to "this person is your main contact." The way to find out is simple: put an allocation percentage in the contract, ask to see it, and compare it with what shows up in your repository each week.
This comes up often when founders ask me why progress feels slow even though the invoice says one full-time developer. Sometimes the developer is fine and the work is just hard. But often enough, the developer is quietly working on other projects for part of the week.
Why it happens
Agencies run on utilization: the share of each person's time that gets billed. Splitting a developer across clients is a normal way to keep everyone billable, especially when one client's work is waiting on feedback or designs. That is not inherently dishonest. The problem is when the arrangement is sold as dedicated and billed as full time.
Common patterns:
- Shared from the start. The proposal says "dedicated team," but the developers are also staffed on other accounts at 50 to 70 percent.
- Drift. The developer starts full time on your project, then a bigger client needs help, and your share of their week shrinks without anyone telling you.
- Hidden backfill. The named developer does the client calls and reviews, while more junior people do much of the actual work.
What it costs you
Splitting attention is more expensive than the hours suggest. Every switch between projects costs time to reload context. A developer who spends half the week on your product does not produce half the output of a full-time developer. They usually produce less, because they lose time every time they come back to your code.
You also pay in responsiveness. Questions wait a day for an answer, bugs wait for "their day on your project," and small fixes take a week.
And you pay in quality. A developer who knows your product only partly is more likely to make changes that break things elsewhere.
How to tell what you are getting
You do not need to accuse anyone. You need a few signals.
Look at the commits. If you have access to the repository during the build, look at when the named developer commits. A full-time developer usually commits on most working days. Commits clustered on two or three days a week, or long gaps, suggest a split. This is not perfect evidence, since some people commit in batches, but it is a useful first look.
Compare the invoice with the output. If you are billed 160 hours a month but see a few small changes per week, ask what the hours were spent on. I wrote about reading invoices in what to look for in an agency invoice.
Ask directly. "What percentage of this developer's time is on our project, and who else are they working on?" A good agency will answer plainly. Evasion tells you something too.
Watch responsiveness. If simple questions regularly take a day or more, the person is probably busy elsewhere.
What to put in the contract
The fix is clarity. These terms are reasonable and easy to check.
Define "dedicated" as a number
Write the allocation as a percentage of a full working week, for example "the lead developer is allocated at 100 percent to this project" or "at least 80 percent." Then it is a commitment, not a marketing word.
Bill for allocation, not for a title
If the developer is allocated at 60 percent, you pay for 60 percent. If the agency wants to bill a full-time rate, the person must be full time on your work.
Require notice of changes
Any change to the allocation needs your written agreement or advance notice, so a shift in staffing never shows up as a surprise in your velocity.
Ask for time reports
A weekly breakdown of hours by task, even a simple one, makes most of these problems visible. It also gives you the data to have a calm conversation if output looks thin.
Name the people doing the work
If juniors will do part of the work, that is fine, but it should be stated and priced accordingly. See the senior team that pitched you is not building your product for the related problem.
These belong next to the terms in SOW red flags and should be part of choosing an agency engagement model in the first place.
Is a shared developer ever the right choice?
Yes. Early on, you may not have a full week of work for one developer. Paying for 50 percent of a strong, experienced developer can be a better deal than a full-time junior one. The key is that it is a deliberate, priced choice, not something you discover months later.
A rough guide:
- Shared is fine when the work is maintenance, small features, or waiting on design and customer feedback.
- Full time matters when you are building the core of the product, under a deadline, or when the system is complex enough that context switching causes mistakes.
If you are unsure how much engineering time your roadmap actually needs, that is the kind of question a fractional CTO can help answer before you sign a large agency contract. Our pricing is set up for exactly that kind of short, focused engagement.
FAQ
Is it normal for agency developers to work on multiple clients?
Yes, it is common. The issue is not the practice but whether it matches what you are paying for and what you were told.
How do I raise this without damaging the relationship?
Ask for facts, not confessions. Request the allocation in writing and a weekly hours breakdown. Most agencies will respond well to a clear, unemotional request.
What if the agency says the developer is full time but the output says otherwise?
Ask to review the time reports together and walk through what was built. If the hours and the work do not match, that is a conversation about the invoice, not just about pace.
Should I ask for a discount if I find out the developer was shared?
If you were billed full time for a part-time allocation, yes. Ask for a credit for the difference and put the allocation in writing going forward.