TL;DR
A request for a real tool on your client’s site is the best revenue an agency can land: high margin, recurring, harder to get swapped out of. But it runs into a real problem: you don’t have a dev, a dev shop bills high and disappears, and building an in-house team is the most expensive, riskiest way to find out it wasn’t going to work. The way out is to deliver with a technical partner under your own brand, without becoming a software company. The risk isn’t in taking the project. It’s in taking it the wrong way.
Why this is an opportunity, not a problem
When a client asks for a tool (not a site, a tool that does something), they’re telling you they trust you to solve a business problem, not just an image one. That’s the kind of work that pays more, lasts longer, and pulls you out of the landing-page price war. It’s exactly where an agency stops being a design vendor and becomes an operations partner.
The problem is the opportunity comes wrapped in a legitimate fear: “what if I say yes and can’t deliver?”. That fear is healthy. It just can’t become the reason you hand money back to the competition.
The three obvious ways out (and where each one breaks)
Turning it down, hiring a dev shop, or building an in-house team are the natural reactions. They all carry a hidden cost: the first makes you lose the account, the second makes you lose margin and control, the third makes you lose money for months before you even know if it was worth it. Worth breaking down.
Turning the request down
Looks prudent. In practice, you teach the client to go look for whoever “does the tech part”, and that person, sooner or later, also does the marketing part. You don’t just lose the project: you open the door to losing the account.
Calling a dev shop
The quote comes back high, the timeline comes back long, and control leaves your hands. Worse: in front of the client, the brand answering for the tool is yours, but the one setting the pace is a vendor you don’t control. When it stalls, you’re stuck in the middle, no team to fix it and no vendor in sight.
Hiring a dev (or a team)
This is the one that feels most “definitive” and it’s the most expensive of all. A senior developer in the US runs $120k to $160k a year in base salary (Glassdoor), and that’s just salary, no benefits, no time-to-productivity, no risk of them quitting in six months. You’re taking on a high, recurring fixed cost for a demand that’s still one-off. And then comes the part nobody at the agency says out loud: you don’t know how to hire a dev, you don’t know how to tell if they’re any good, and you don’t know how to keep them afterward. Judging a professional from a field that isn’t yours is a blind bet with your own money.
The fourth way: deliver under your brand, without becoming a software company
There’s a middle ground between turning it down and building a tech department: outsource the delivery to a technical partner who works under your brand, with fixed scope and timeline. You keep the client, the margin and the relationship; the partner ships the working tool, and vanishes from the client’s radar. It’s the model the market calls white-label: the technical partner delivers under your brand and never shows up in front of your client, and it exists precisely because an in-house senior dev is too expensive for most agencies (Xovak).
The difference between this and a traditional dev shop isn’t just price. It’s how the work gets done: scope defined up front, short timeline, delivery in phases with you approving each step. You’re not buying “development hours” with no end. You’re buying a result, with a date and a price agreed before anything starts.
Where this breaks too (because everything has a trade-off)
The wrong partner is as bad as no partner. The model only works if three things are clear: the scope is fixed (no “we’ll figure it out later”), the code stays with the client (or with you, never hostage to the vendor), and the tool is built well, not a cheap hack that breaks in front of the end client and becomes your headache. A cheap, badly built tool costs more than a dev shop: you pay twice, and the second time in front of your client. If the partner won’t lock scope and timeline before starting, that’s the sign you’re about to become the dev shop, just without the team.
How to decide, in practice
If the demand is one-off and you want to test the client’s appetite without taking on fixed cost: partner, fixed scope. If the demand has become recurring and predictable enough to pay a salary every month with room to spare: then, maybe, it makes sense to think about a team, but only after you’ve delivered a few times with a partner and understood what the work actually takes. Starting with the team is betting before you have the information.
The simple rule: don’t build structure for a demand you haven’t validated yet. Deliver first, learn the real cost, and only then decide whether it becomes an in-house operation.
FAQ
How much does it cost to deliver a tool like this through a partner?
It depends on scope, but the whole point of the model is having the price fixed before starting, not open-ended hours. A simple tool (calculator, smart form, configurator) usually comes out at a fraction of what a dev shop charges for a “from scratch” project, because the scope is lean and the method is standardized.
Will the client know I outsourced it?
In the white-label model, no. The delivery goes out under your brand. The technical partner doesn’t show up in front of your client.
What if the tool breaks down the line?
That’s why “built well” isn’t a luxury, it’s insurance. A tool with solid structure is stable and easy to adjust. The noise comes from cheap hacks that break in front of the end client: exactly what you want to avoid when it’s your brand on the line.
Wouldn’t it be safer to just hire a dev?
Only if the demand is already recurring enough to pay the salary with room to spare. For a one-off or still-uncertain demand, hiring means taking on the highest cost and the biggest risk (evaluating and keeping someone from a field that isn’t yours) before you know it’s worth it.
How long does it take?
Fixed-scope tools usually ship in weeks, not months, because the scope is defined up front and the work is done in phases, with you approving each step.