On Page Navigation
On Page Navigation
August 19, 2026
You have more work than people, and it is the third time this quarter. The build is a marketing site with a booking flow, the client has already been given a date, and the developer who would normally take it is booked until the end of next month. So you start looking outside. That decision has four common shapes, and most of the disappointment with outsourcing comes from picking the shape that suits this month cash flow rather than the one that suits where the risk actually sits.
This is written for the person running the agency, not the client buying the site. It is the arithmetic and the failure modes, including the cases where the honest answer is to turn the project down. The commercial side of it, meaning how partner arrangements are usually structured, sits on the partner side of what we do.
This is the only option that builds capability you keep. It is also the only one where a slow month costs you the same as a busy one. The decision is about utilisation, not about the hourly rate, and comparing a salary against a contractor day rate is the arithmetic that gets agencies into trouble.
If you cannot see six months of work already sold, a salary is a bet on sales you have not made yet. There is a second cost that rarely reaches the spreadsheet: recruiting takes months of somebody senior reading resumes, and a developer who leaves takes the context with them unless the work was documented as it went. Very little agency work is documented as it goes.
The cheapest headline number and the widest spread of outcomes. Freelancers are excellent for work that is genuinely self-contained and properly specified, and they are a poor fit for anything where the specification is going to move, because a fixed-price freelancer has exactly one defence against scope change, which is to argue with you about it.
The real cost is your own project management time, and it stays invisible until somebody counts it. A freelance build that saves you two thousand dollars and consumes twenty hours of an account manager has not saved you anything. The other thing to price in is concentration. One freelancer is one person with one phone, one holiday and one better offer.
Here you are buying a team and a process rather than a person. Delivery is more reliable, the price is higher, and the relationship is built to end at launch, which is precisely the moment a website starts generating small requests forever. If you buy this way, decide in advance who is answering the phone in month four.
Two things to check in the contract before you sign, both of which sound paranoid and are not. Whether the shop also sells direct to the kind of client you have just introduced them to, and whether their name, their staging domain or their support address will appear anywhere in what they hand over. Ask for a non-solicitation clause in writing. Ask what the theme author string will say. Neither question offends a shop that is used to doing development work behind another agency.
On a retainer you are buying capacity rather than a project. Work is queued instead of quoted, the monthly cost is predictable, and the estimating conversation disappears, which for most agency owners is the actual benefit. The trade is straightforward and you should say it out loud before signing: a quiet month is billed at the same rate as a busy one.
Three commercial shapes are in common use across the industry and they differ mainly in who holds the client relationship. The lightest is a referral, where you introduce the client and the provider bills them directly. You keep none of the delivery risk and none of the control, which is the honest description of what a referral or affiliate arrangement actually is.
Next is reselling, where you buy at a discount and bill the client yourself. You own the relationship and the margin, and you also own the first phone call when something breaks. That is the trade in buying services at a discount and selling them on. White label goes one step further and takes the provider out of the client view entirely, which is the only one of the three where your brand is on the work.
The choice gets easier once you name the thing you cannot predict. If demand is what moves, meaning the work is much the same each time but the volume is not, buy capacity on a retainer. If the work is what moves, meaning every project is a different problem, buy expertise project by project and expect to pay for the estimating. If neither moves much and you can see the pipeline, hire. Most agencies that are unhappy with outsourcing bought expertise when what they needed was capacity, and paid a project premium every month for the privilege.
None of what follows is caused by bad developers. Almost all of it was set up weeks earlier, in the conversation where the work was agreed, and it surfaces in launch week when there is no time left to do anything about it.
If the only written record of the work is the proposal you wrote to win it, you have a sales document doing a job it was never built for. Proposals are deliberately warm. They say things like a clean, modern booking experience, which is a sentence two people can read in two entirely different ways and both feel certain.
A build specification needs the page list, the states every form can be in including the failure states, who is supplying content and by when, and an explicit list of what is out of scope. That last item does more work than the rest combined, because scope arguments are almost never about what was promised. They are about what somebody assumed was obviously included. The test to apply before you send it: could a developer who has never spoken to you build from this and be wrong in fewer than five places?
Staging, production, backups, and who holds the keys to each. Agencies hand a subcontractor production credentials all the time because staging was never set up, and then find out at handover that the plugin licences are registered to an email address at a company that is no longer involved. Settle it before work starts: whose hosting, whose backups, whose certificates, and whose account the licences are bought under. If the answer is that it all lives on hosting you control rather than the builder controls, most of this disappears.
The launch cutover is the one task on a project plan with no natural owner. The developer thinks the agency will do it. The agency thinks the developer will. It happens at the DNS layer, it is irreversible for the length of the old cache, and it is worth reading what the individual records do before you touch them rather than finding out on the day. Name the person and put the date in writing.
Done should be a checklist somebody can tick, not a feeling somebody has on a Friday. A workable one: every form submitted to a real inbox and confirmed received, the 404 page tested, admin accounts transferred and the subcontractor accounts removed, backups running and one restore actually attempted, licence keys in the client's name, and the old URLs mapped to the new ones.
That last item is the one most often skipped, and its absence takes months to become visible. A rebuild that changes the URL structure without redirects loses the accumulated ranking of every page that moved, and by the time anyone notices the traffic dip the developer has been paid and moved on. If the site had any search visibility worth protecting, the redirect map is not an optional extra.
Performance belongs on the same checklist, with a number attached. Fast is not a specification, and every developer believes their build is fast. Agree a target before the work starts and test it on the real content rather than on three paragraphs of placeholder text, because the thing that slows a site down is usually the gallery the client added afterwards, not the theme. Where that target should sit is a question about what the site is actually being measured on.
If you are selling under your own brand, the mechanics of that need checking rather than assuming. The theme author string. The plugin licence registered to another company name. Commit messages and the email addresses attached to them. A staging URL on somebody else's domain that is still linked from a shared document. The support address in an automated notification email. A footer credit that reappears after a plugin update.
Clients look. Not out of suspicion, usually, but because somebody in their team opens a page source or reads a notification header and asks a reasonable question about who this other company is. Ask your provider in writing what will and will not carry their name, then go and check it yourself on the staging site before the client sees it. A provider who resents that question is telling you something useful.
The build is the smallest part of the money a website will ever cost. It lives for years and it produces small requests continuously: a page of new copy, a form field, a plugin that broke on update, an image somebody wants swapped before a trade show. None of it is hard. All of it is a context switch for somebody who was doing something else.
If your arrangement prices the build keenly and leaves everything afterwards to be handled ad hoc, your margin erodes on exactly the work that repeats forever. Price the year, not the launch. That means deciding what ongoing care of the site costs you before you quote what it costs the client, and it means quoting it at the same time as the build rather than raising it awkwardly six weeks later.
Without a named channel and an agreed response time, post-launch requests arrive by text message on a Saturday, addressed to whoever the client liked best. That is not a client problem. It is the absence of a process, and it is the single most reliable way for a profitable project to turn into an unprofitable relationship.
Half of these requests are not really requests at all. They are the consequences of updates: a plugin that changed its markup, a vulnerability disclosure that needs patching this week, a certificate that did not renew. Somebody has to be watching for those, and if your agreement with the builder ended at launch, that somebody is you. Decide whether you want to own patching and vulnerability monitoring or buy it, and then tell the client which one they are paying for.
Three cases, and they are worth being honest about. Do not outsource the thing you actually sell: if clients choose you because of how you build, subcontracting the build hollows out the reason they picked you and they will work it out. Do not outsource a project small enough that managing the subcontractor costs more than doing the work. And do not outsource when the client bought access to a specific person in your team, because that was the promise, whatever the contract says.
It is the right answer in the opposite conditions. When demand is spiky and you would rather not carry a salary through a slow quarter. When the work is standard enough that a good process beats a specific individual. When you want your own people spending their time on strategy, design and the client relationship, which are the parts a client remembers a year later. If that describes you, the shape worth looking at is delivery that runs under your brand rather than alongside it, priced monthly so the cost is predictable and the estimating conversation goes away.