What to do after an unsuccessful contractor engagement

Hiring an outside developer or agency to build your website is usually the right call. You get the specialty and the flexibility without adding headcount, and a healthcare marketing site is exactly the kind of project that benefits from someone who has done it before. But sometimes it goes wrong. The kickoff is great, the first staging link is promising, and then things get rocky. Deadlines slip. The provider directory that was supposed to be done in March is half-built in June. Emails take four days to answer. Eventually you end the engagement, and you're back where you started with less budget and less time.

A lot of the healthcare companies I talk to are in exactly this spot. They had a site built by a generalist agency or a freelancer who came recommended, and now they have something that's either unfinished, or finished but impossible for the marketing team to update without a developer. This post is about what to do next.

Should you start the next project right away?

No. Take some time off first.

This is the hardest advice to follow, because you have deadlines and you're now further behind than when you started. A conference is coming up and the new site was supposed to be live for it. Leadership is asking why the project they approved a year ago is still a staging link. Every instinct says to find a new developer this week and get moving.

Resist it. If you jump straight into the next engagement, you will carry the same assumptions, the same gaps in the brief, and the same unspoken expectations into it, and you'll get a similar result. Take a day. A real one, with the project closed. Come back to it with less of the frustration and more of the clarity, and do the review below before you talk to anyone new.

Was it really all the contractor's fault?

Probably not entirely, and it's worth being honest about that before you go looking for someone new.

Let me be clear that the contractor may well have failed. Missed deliverables, slow communication, disappearing for two weeks in the middle of the build, handing over a CMS that only they understand: those are real failures and they're on them. I've taken over enough half-finished healthcare sites to know what bad work looks like.

But the engagement had two sides, and the only side you can change for next time is yours. So ask yourself some uncomfortable questions.

Did you vet them properly before starting? Did you look at sites they'd built for other healthcare organizations and talk to those clients, or did you go on a portfolio and a good first call?
Did you run a planning session before kickoff? Did anyone write down what the site was for, who it had to serve, and what done meant?
Were there warning signs you noticed and set aside? A vague proposal, a timeline with no milestones, an answer about HIPAA that didn't quite land.
Did you give them enough detail? Did they have your content, your brand guidelines, your list of integrations, the names of the people who had to approve things?
Was everyone clear on expectations? Did your compliance team know they'd be reviewing forms? Did your marketing team know they'd need to supply copy by a certain date?
Were deadlines, milestones, and deliverables written down and agreed to, or did they live in a kickoff call recording nobody rewatched?
Were communication expectations set? How often would you hear from them, in what form, and what counted as a decision needing your input?

It's difficult to examine the role you played when a project goes wrong. I'd encourage you to do it anyway. Not to assign yourself blame, but because every honest answer to one of those questions becomes a requirement for the next engagement.

What actually went wrong, and when?

Walk the timeline. Not the emotional version, the actual sequence of events.

How did the introduction go? What did the proposal look like? Was there a discovery phase, and did it produce anything you could point to, like a content inventory or a sitemap or a migration plan? How did kickoff go? When was the first milestone due, and was it hit? When did you first notice something was off? When did you first say something about it? When did the project go from behind to broken?

On healthcare site projects, the trouble usually shows up at one of a few predictable points, and it's worth checking whether yours matches.

Content. The agency assumed you'd supply finished copy for 80 pages. You assumed they'd migrate what was on the old site and clean it up. Nobody said either out loud. Three months in, the site has a beautiful design and lorem ipsum on every page.

Compliance. Nobody scoped legal review. The appointment request form was built, then legal saw it, then it had to be rebuilt to send submissions somewhere with a business associate agreement instead of to a shared inbox. The rebuild ate the buffer and the timeline never recovered.

The CMS. The site was built, but the content model was whatever the developer found convenient. Your marketing team can't add a new location page without a developer, because "location" was never set up as a content type. The site technically launched and is functionally stuck.

Integrations. The CRM, the scheduling system, the careers feed. Each was "easy" in the proposal and each turned out to need weeks of back-and-forth with a vendor's support team.

The handoff. The contractor delivered, got paid, and left. There's no documentation, no training, and no one who knows where the DNS is managed.

Find your points. For each one, ask what would have caught it earlier. Usually the answer is a planning step, a written document, or a check-in that didn't happen. Those become your process changes.

What should you change before the next engagement?

Turn the review into specific changes, and make them before you talk to anyone new. Here is what I'd suggest for a healthcare marketing site specifically.

Write down what the site is for. One page. Who it serves (patients, referring providers, partners, investors, job candidates), what each of those audiences needs to do on it, and what has to be true at launch. This document is what you'll hand to every candidate, and it's what you'll measure proposals against.

Inventory what you have. Every page on the current site, every form and where it sends data, every third-party script, every integration, and every URL that gets meaningful search traffic. A good developer will do this during an assessment, but doing a rough version yourself tells you how big the project actually is and makes it much harder for a proposal to undercount it.

Decide what done means. For a site migration, I'd include: every page migrated or deliberately retired with a redirect, every form reviewed by legal and working end to end, analytics loading only after consent, an accessibility check against WCAG, and your team able to create and publish a page without a developer. Write your version down. If a proposal doesn't address each item, ask.

Decide how you want to communicate. Weekly written updates are a reasonable minimum. Decide what you need to see (work done, work planned, open questions, decisions needed) and ask for it in that form. Decide who on your side answers questions and how fast.

Decide what you'll supply and by when. Copy, images, brand assets, logins, introductions to your compliance and IT people. Put dates on them. Most stalled projects are stalled waiting on the client for something, and nobody likes to say so.

How do you vet the next developer differently?

Use what you learned. The questions below are the ones I'd want a healthcare client to ask me, and the ones I'd be wary of a contractor who couldn't answer.

Show me a healthcare or life-sciences site you built. Can I talk to that client?
How do you handle forms that collect patient information? Where does the data go?
How do you handle analytics and consent?
What does the content model look like, and how will my marketing team add a new page, a new provider, or a new location without you?
What are your milestones, what do I get at each one, and what do you need from me at each one?
What happens at the end? What does handoff include?
What does it cost, and is that fixed?

A contractor who has done this before will answer those quickly and specifically. A generalist will answer vaguely or, more often, confidently and wrong. Listen for specificity. It's the most reliable signal I know.

On pricing: a fixed price tied to defined milestones is safer for you than hourly, and it's safer for the contractor too, because it forces both of you to agree on scope before the work starts. If someone can't give you a fixed price, it usually means they don't yet know what the project is, and the right next step is a paid assessment that produces one, not a start date.

What do you tell leadership?

The truth, early, with a plan attached.

The instinct after a failed engagement is to go quiet until you have a replacement lined up, so the conversation with your CEO or board is "here's what went wrong and here's who's fixing it" rather than just "here's what went wrong." I understand the instinct and I'd argue against it. The longer the gap between the project stalling and leadership hearing about it, the more it looks like the problem was hidden rather than handled.

What works better is a short, factual write-up. What was contracted, what was delivered, where it broke, what it cost, and what you've learned. Then the process changes from the section above, and a realistic timeline for choosing the next partner, including a discovery or assessment phase before any build starts. Leadership in healthcare organizations is used to risk registers and corrective action plans. Frame it that way and it reads as competence, not failure.

Be specific about what it cost and what was salvaged. "We spent $60k, the design is usable, the build is not, and we expect the replacement project to reuse the design" is a sentence a CFO can work with. "It didn't work out" is not.

What should the handoff have included?

If your contractor did deliver something, check it against this list. It's what I hand over at the end of every build, and the gaps will tell you what you're missing and what to ask the next person for.

Access. You own the domain registrar, DNS, hosting account, CMS project, analytics property, and every third-party service the site uses. Not the contractor. You.
The code, in a repository you control, with a README that says how to run it and how to deploy it.
A content model your team understands. Every content type on the site, what it's for, and which fields are required. If a new provider or a new location needs a developer, the content model is incomplete.
Form routing. A list of every form, where it sends data, who receives notifications, and which of those have been reviewed by legal.
Analytics and consent configuration. What loads, what waits for consent, and how to add or remove a tag without breaking the gate.
Redirects. Every old URL that now points somewhere new, in a file you can read.
Training. A recorded walkthrough of the CMS for your marketing team, and a written one for the person who joins after they leave.

If the handoff you got covers half of this, you're in reasonable shape and can probably hire someone to fill in the rest. If it covers none of it, treat the site as unfinished regardless of whether it's live.

What about the site you're left with?

Sometimes the half-finished site is salvageable and sometimes it isn't. Before you decide, get someone independent to look at it. Not the person who built it and not someone who wants to rebuild it from scratch on principle. An honest review should tell you which parts are sound, which parts are fragile, and whether the content model is worth keeping.

In my experience, the design work is often reusable and the implementation often isn't. A site with a good visual design and a bad CMS setup can keep the design and get a new content model and build underneath it. A site that was never finished is frequently cheaper to restart with a clear plan than to complete inside someone else's half-made decisions.

Either way, get the review before you commit to a direction. It's a small cost against the alternative of paying twice.

How do you move on?

Sometimes you just make a bad call. You hired someone who seemed right and wasn't. That's the risk of hiring anyone, and it's not a reflection on you unless you repeat it.

So: take some time off. Be honest about both sides. Walk the timeline and find where it broke. Turn each break into a process change, in writing. Vet the next person against what you learned. Then start again.

The healthcare companies I've seen come out of a bad engagement well are the ones that treated it as a lesson in how to run a website project rather than as a reason to avoid running one. The second site is almost always better than the first would have been, because this time the brief exists, the milestones are written down, and everyone knows what done means.