Four Ways to Buy Development Capacity
Say you sold a marketing site with a booking flow, promised a launch date, and then learned your best developer is booked through the end of next month. Outsourcing is the obvious move. It comes in four shapes, and the ones that disappoint are usually chosen for how this month's cash looks, not for where the risk in the work actually sits.
This is for the person who runs the agency, not the client buying the site. It covers the arithmetic, the ways each model fails, and the cases where turning the project down is the better call. How partner arrangements are commonly structured is on the partner side of what we do.
Hiring Someone In-House
A salaried developer is the one option that leaves you with capability you keep. It is also the one where a slow month costs exactly what a busy month does. Compare utilization, not hourly rates. Setting a salary next to a contractor's day rate is how agencies talk themselves into a hire they cannot feed.
A fair test: can you point to six months of work that is already sold? If not, the salary is a bet on sales you have not closed. Two costs also miss the spreadsheet. Recruiting eats months of a senior person's evenings, and when the developer leaves, the context leaves too unless the work was written down as it went. Most agency work is not.
Freelancers, One Project at a Time
Freelancers show the lowest sticker price and the widest range of results. They shine on self-contained work with a tight spec. They struggle when the spec will shift, since a fixed-price freelancer has one defense against changed scope, and it is an argument with you.
The hidden line item is your own time. Saving two thousand dollars on a build while an account manager burns twenty hours chasing it is a loss, and nobody notices until someone counts. Concentration matters as well: one freelancer means one phone, one vacation, and one better offer waiting in the inbox.
A Development Shop on a per-Project Basis
With a shop you are buying a team and a process instead of an individual. Delivery tends to be steadier and the price is higher. The engagement is also designed to end at launch, which is exactly when a live website begins producing small requests that never stop. Before signing, decide who picks up the phone in month four.
Two contract checks sound paranoid and are not. First, does the shop also sell directly to clients like the one you are about to introduce? Get a non-solicitation clause in writing. Second, will the shop's name, staging domain, or support address show up anywhere in the handover? Ask what the theme author string will say. A shop used to working behind other agencies will not be offended by either question.
White Label on a Monthly Retainer
A retainer buys capacity, not a project. Work goes into a queue instead of a quote, the monthly bill is predictable, and the estimating conversation goes away, which for many owners is the whole appeal. The cost is simple to state, so state it before you sign: a quiet month bills the same as a busy one.
Providers tend to offer three commercial shapes, and what separates them is who owns the client relationship. The lightest is a referral. You introduce the client, the provider bills them, and you carry none of the delivery risk and none of the control. That is what a referral or affiliate arrangement amounts to.
Reselling sits in the middle. You buy at a discount and invoice the client yourself, so you hold the relationship and the margin, and you also take the first call when something breaks. The trade is laid out in buying services at a discount and selling them on. White label goes furthest. The provider disappears from the client's view, and it is the only one of the three that puts your brand on the work.
Match the Model to What You Cannot Predict
Ask which variable moves. If the work is similar each time but the volume swings, buy capacity on a retainer. If every project is a different puzzle, buy expertise per project and accept that you are paying for the estimate. If neither swings and the pipeline is visible, hire. The common mistake runs one way: an agency needs capacity, buys expertise, and pays a project premium every single month.
Where Outsourced Builds Break
Bad developers are rarely the cause. Nearly every failure below was set up weeks earlier, in the conversation where the work was agreed, and it shows itself in launch week, when nobody has time left to fix it.
Scope That Lived Only in a Conversation
If the sole written record is the proposal you used to win the job, a sales document is doing work it was never built for. Proposals are warm by design. They promise "a clean, modern booking experience," a phrase two people can read two ways while both feel sure.
A build spec lists every page, every state a form can be in (failures included), who supplies content and by what date, and what is out of scope. The out-of-scope list carries more weight than everything else together, because scope fights are rarely about what was promised. They are about what someone assumed was obviously included. Before you send it, ask whether a developer who has never spoken to you could build from it and be wrong in fewer than five places.
No One Owns the Environment
Staging, production, backups, and who holds the keys to each. Agencies hand subcontractors production credentials because staging never got built, then discover at handover that the plugin licenses sit under an email address at a company no longer involved. Settle four things before the first commit: whose hosting, whose backups, whose certificates, and which account buys the licenses. If everything runs on hosting you control instead of the builder, most of this evaporates.
The launch cutover has no natural owner on most project plans. The developer assumes the agency will do it, and the agency assumes the developer will. It happens in DNS, and it stays irreversible for as long as the old records are cached. Spend an hour on what the individual records do before you touch them, then write down a name and a date.
Handover Without a Definition of Done
Done needs to be a list someone can tick off, not a mood on a Friday afternoon. A workable one: each form submitted to a real inbox and confirmed received, the 404 page tested, admin accounts moved over and subcontractor accounts removed, backups running with one restore actually tried, license keys in the client's name, and old URLs mapped to new ones.
That final item gets skipped most often, and its absence takes months to show. Change a site's URL structure without redirects and every page that moved forfeits the ranking it built up. By the time the dip is noticed, the developer has been paid and gone. Any site with search visibility worth protecting needs the redirect map as a deliverable.
Put performance on the checklist with a number beside it. "Fast" is not a requirement, and every developer thinks their build is quick. Agree a target up front and test on the real content, not three paragraphs of lorem ipsum. The usual culprit is the photo gallery the client uploads next quarter, not the theme. For where to set the bar, see what the site is actually being measured on.
Your Client Can See Your Subcontractor
If you sell under your own brand, check the mechanics rather than assume them. Look at the theme author string, a plugin license registered to another company, commit messages and the addresses attached to them, a staging URL on somebody else's domain still linked from a shared document, the support address in an automated notification, and a footer credit that returns after a plugin update.
Clients do look. Rarely out of suspicion; someone on their team views page source or reads an email header and wonders who this other company is. Ask your provider in writing what will and will not carry their name, then verify it yourself on staging before the client sees anything. A provider who bristles at the request has told you something.
The Margin Covered the Build and Not the Year
A website outlives its build by years and generates small tasks the whole time: new copy for a page, one more form field, a plugin that broke on update, an image swapped before a trade show. Each task is easy. Each one also pulls somebody off what they were doing.
Price the build keenly and leave the aftermath to ad hoc handling, and your margin drains on the work that repeats forever. Work out what ongoing care of the site costs you before you quote the client, and quote it alongside the build instead of raising it awkwardly six weeks after launch.
Post-Launch Support Is Where Money Leaks
No named channel and no agreed response time means requests show up as Saturday text messages to whichever person the client liked best. That is a missing process, not a difficult client, and it reliably turns a profitable project into an unprofitable relationship.
Many of those messages are really side effects of updates: a plugin changed its markup, a vulnerability disclosure needs patching this week, a certificate failed to renew. Someone has to be watching, and if your agreement with the builder ended at launch, that someone is you. Choose whether to own patching and vulnerability monitoring or buy it, then tell the client which they are paying for.
When to Say No to Outsourcing
Three situations call for keeping the work. If clients hire you for how you build, subcontracting the build hollows out the reason they chose you, and they will notice. If the project is small enough that supervising a subcontractor costs more than doing it, do it. And if the client bought time with a specific person on your team, that was the promise, whatever the contract says.
The mirror image is when outsourcing fits: demand spikes and you would rather not carry a salary through a slow quarter, the work is standard enough that a good process beats a particular individual, or you want your own people on strategy, design, and the client relationship, the parts a client still remembers a year on. In that case, look at delivery that runs under your brand rather than alongside it, priced monthly so the cost is predictable and the estimating conversation goes away.
