Fourteen weeks of interviews and the staging URL still returns a holding template: no CMS login, no component library, and a Core Web Vitals report that has never been run.
That is the fork. Keep the seat open and hope the next offer lands, or outsource web design so something actually ships. The operations lead who owns this decision is not choosing a vibe. You are choosing who writes the templates, who can log into the CMS at 9am, and who is still around when Googlebot fails to render the product grid.
We see the same stall on both sides of the brief. In-house looks cheaper on a slide until notice periods, tooling, and a missing front-end skill show up in the backlog. Outsourcing web design looks fast until handover is a ZIP of mockups and nobody owns crawlability. The useful move is to score both models against the same gates, then pick the one that can clear them this quarter.
The empty seat is already a production risk
An unfilled designer or front-end role is not a neutral state. Campaigns wait. Legal copy sits in a doc. The staging certificate expires. Support keeps pasting the same “new site coming” line into tickets.
HR will keep the JD live because that is their job. Yours is uptime and a publish path. If the current site cannot take a new landing page without a contractor, the vacancy is already costing you more than a salary line. Write that down before the next interview loop starts.
We treat an empty seat as a freeze on template work. No new content types. No navigation change. No migration of the blog into the CMS. If that freeze is unacceptable, the in-house path is already failing, regardless of how strong the shortlist looks on paper.
What an in-house hire actually has to cover
One person rarely covers design, front-end, CMS, and the SEO debt the last agency left behind. The JD usually pretends they can. Then week six arrives and you discover they can Figma a homepage but cannot ship a paginated category template that search can crawl.
List the work that must happen in the next two sprints. Not the five-year brand vision. Templates, forms, redirects, schema, image compression, editor training. If that list needs three disciplines, a single hire will queue two of them. That queue is the real comparison against a shop that already has those seats filled.
In-house still wins when the work is daily publishing, brand-sensitive campaigns, and a design system that marketing will live in for years. It loses when the next useful thing is a rebuild, a CMS swap, or a crawlability fix that has been open since the last redesign.
What changes when you outsource web design
Outsourcing web design is not “send Figma, get a ZIP.” Done properly it is a scoped build: information architecture, templates, CMS fields, staging, QA, and a handover pack the in-house ops team can actually run.
The first useful difference is calendar. A retained team can start on a named sprint. A new hire starts after notice, onboarding, and laptop. If the campaign date is fixed, that gap is the decision.
The second difference is breadth. We put design next to development on purpose because a pretty canvas that fails INP on mobile is not a launch. When you outsource web design to a team that also ships the front-end, the argument about “whose bug is the CLS shift” happens inside one stand-up, not across two vendors and a recruiter.
The third difference is what happens after go-live. If the contract ends at visual QA, you have bought a brochure. If it ends at CMS training, redirect map, and a crawl of the staging host, you have bought an operable site.
Handover is the real deliverable
Handover is where most outsource jobs quietly fail. Files in Drive. A Notion page nobody updates. Admin passwords in a chat thread. The designer who knew why the header breaks on tablet has already started the next client.
We write handover as a ticket, not a courtesy. Repo access. Environment variables. CMS roles. Component inventory. Which templates are canonical. Which are leftover. How to roll a release without taking the nav down. If that pack is missing, you do not have a site. You have a dependency on a person who no longer answers Slack.
In-house handover looks different but it is the same risk. When the only person who can edit the theme leaves, you are back to a holding page with a nicer colour palette. Demand the same artefacts from a staff member that you would demand from a vendor: documented CMS, named environments, and a crawl that still passes after they go.
Ask for a recorded editor walkthrough, not a PDF of screenshots. Ask who owns DNS, hosting, and the staging robots.txt. Ask what happens to the design tokens if the Figma seat lapses. Those answers tell you whether outsourcing web design will leave you operable or stranded.
CMS choice is a staffing decision
The CMS is not a preference. It is who can publish on a Tuesday without opening a ticket.
If marketing must ship landing pages during a sale, a locked custom stack with no editor UI is a staffing plan disguised as architecture. Someone in-house will become the bottleneck, or you will keep paying the build team to type copy. That is a valid model. It is not a cheap one.
If the ops team needs to own pages, forms, and blog posts, the CMS has to match the people who will log in. Fields named in plain language. Preview that matches production. Permissions that stop an intern deleting the header. Training that is not a one-hour call on launch day.
We see the reverse failure too: a CMS so open that every campaign spawns a new template, crawlability collapses, and Core Web Vitals drift because nobody is allowed to say no. Pick the CMS for the operators you actually have, then staff the build around that, whether the builders sit in your office or not.
Crawlability and Core Web Vitals as gates, not polish
A design that marketing loves and search cannot fetch is a failed launch. Crawlability belongs in the same acceptance list as spacing and type. If the menu is a client-rendered widget Googlebot never sees, the IA work was theatre.
Core Web Vitals belong there too. LCP on the template that actually ranks. INP on the filter UI, not on a static mock. CLS on the cookie bar and the late-loading font, not on a lab URL with extensions disabled. We fail a staging build that misses those gates even when the screenshots look finished.
This is the point where in-house and outsource should be scored the same way. Can the people on the job measure field data, not just a single Lighthouse run? Can they fix the template, not just compress a hero image? If the in-house hire is a visual designer, those gates will bounce to a freelancer anyway. Price that bounce into the model before you call in-house cheaper.
JavaScript-heavy builds and who can debug them
A lot of outsource pitches now arrive as a JS framework with a design system and a promise that “SEO is handled.” It is not handled until someone has checked what Googlebot actually renders.
If the front-end depends on client-side rendering, Google’s JavaScript SEO basics still apply: we confirm that the important templates return usable HTML, that internal links exist in the fetched response or the rendered DOM, and that we are not hiding primary content behind a shell that never hydrates for the crawler. That check is a build task. It is not a content task you can bolt on after launch.
In-house, the same trap appears when a strong designer pairs with a front-end who has never looked at URL Inspection. The site looks instant on a laptop and empty in the rendered HTML. Outsourcing web design does not automatically fix that. You have to put crawlability in the SOW and name who runs the rendered inspection before you call the sprint done.
If nobody on either side of the table can explain how the product grid reaches the crawler, do not sign. Hire or vendor, the gap is the same.
WordPress when the ops team needs to publish
Plenty of rebuilds do not need a custom stack. They need templates, a sane editor, and a team that will not drown the install in page builders. When editors need to publish without a ticket, our WordPress development work is usually the stack we put on the SOW because the CMS is already a known object for ops, and handover can be roles, plugins, and a staging clone rather than a six-month training plan.
That is not a default for every brief. Headless can be right when the front-end is an app and the CMS is only a store of fields. Classic WordPress is right when the people who own campaigns will live in the admin all week. The mistake is choosing the stack for the developer’s portfolio instead of the operator’s Tuesday.
If you outsource web design on WordPress, lock the plugin list in the contract. Name who updates core. Name who reviews the template that marketing will duplicate twenty times. In-house WordPress without that discipline turns into a graveyard of leftover builders and a Core Web Vitals chart that only moves the wrong way.
For a rebuild that is more than a theme skin, we put design and engineering on one ticket through our web development service so the CMS fields, the templates, and the crawl path are accepted together. That is the difference between a pretty staging site and a handover you can run.
How we run the first scoping call
Bring the current site, the backlog, and the date that actually matters. Not a moodboard. We will ask who publishes, who signs off design, who owns hosting, and what happens if the campaign moves forward two weeks.
We will also ask what failed last time. Recruiter loop with no hire. Agency that shipped mockups and vanished. In-house designer who could not touch PHP. Those failures tell us which model is lying to you.
The output of that call should be a build model, not a slogan. In-house for daily publishing, with a scoped outsource for the rebuild. Outsource for the templates and CMS, with an in-house editor taking the keys. Full outsource including care, if there is no one internal who should be in the repo. Mixed models are normal. Unowned models are what leave you with a holding template.
If the fit is a rebuild plus technical SEO, we would rather start with a scoped audit of the current templates, crawl, and Core Web Vitals than with a visual workshop. The audit tells you whether you need a designer, a front-end, a CMS person, or all three. That answer is the hiring plan.
Decide the model, then the next ticket
Score both paths on four things only: time to a publishable template, who owns the CMS after week two, whether crawlability is in the acceptance tests, and who is still answering when Core Web Vitals slip.
If the in-house JD cannot cover those four, stop interviewing for a unicorn and outsource web design for the rebuild. Keep a later hire for the publishing rhythm once the system exists. If the outsource pitch cannot name handover, CMS roles, and a rendered crawl, keep the money. You would only be buying another stall.
The next useful step is a written comparison against those gates, using your real backlog, not a generic pros-and-cons list. If you want a second pair of eyes on that comparison, send the current site, the freeze you cannot live with, and the date. We will tell you whether a scoped audit is worth opening, and we will tell you when it is not.
