Why We Refuse to Build Complex Websites Without a Discovery Workshop

You have a website that needs replacing. You know it. Your team knows it. Your CEO has mentioned it twice in all-hands meetings. So you do what every responsible digital communications manager does: you write a brief, send it to five agencies, and wait for quotes.

Three weeks later, you have five wildly different proposals. One says $40,000. Another says $180,000. A third has scoped something you never asked for. And the one you liked best has clearly copied your brief into a template and added “bespoke” to every second paragraph.

That price gap? It’s just a symptom of a much bigger issue. You’re getting different quotes because nobody actually knows what the job is yet.

The brief that breaks everything

Most projects fail before a single line of code is written. They fail because the brief is a mess.

Here is what typically happens. Your health research institute, university department, or government-funded agency decides it needs a new website. Someone (usually the most time-poor communications manager in the building) gets assigned to write an RFP. They pull a template from the internet, fill in the sections they understand, leave the technical ones vague, and send it out with a two-week deadline for responses.

The agencies responding to that RFP are guessing. They are reading between the lines of your document, making assumptions about your content volume, your integration requirements, your user base, and your internal approval workflows. Every agency fills those gaps differently. That is why you get quotes ranging from $40,000 to $180,000 for what you thought was the same project.

The problem is not that agencies are bad at quoting. The problem is that nobody has done the diagnostic work to define what “the project” actually is.

Think about it this way: a health research institute with six integrated data platforms, WCAG 2.2 AA compliance requirements, and a seven-person content approval chain is not a simple website. No one can quote that accurately from a two-page brief.

Why we stopped quoting without diagnosing

At Marameo, we used to respond to RFPs the way everyone else does. We would read the brief, ask a few clarifying questions over email, build our assumptions into a proposal, and hope we were close enough.

Sometimes we were. Often we were not.

We had a project for a health research organisation where the RFP described “a content refresh and platform upgrade.” But once we started building, we discovered 47 unused content types in their Drupal instance, three separate data feeds from external research platforms that nobody had mentioned, and an internal approval workflow that required content to pass through seven people before publication.

The $90,000 project became $160,000. The six-month timeline became eleven months. Nobody was happy.

That project changed how we work. We stopped responding to RFPs without a Discovery Workshop. Full stop. Not because we want to be difficult. Because we want to be honest.

It’s a paid diagnostic. We map the requirements before touching a mockup, ensuring we aren’t just guessing at the solution.

What a discovery workshop actually involves

Here is how we actually spend that time:

1. Stakeholder interviews

We talk to the people who use the website every day. Not just the communications manager who commissioned the project, but the editors who update content, the researchers who upload publications, the administrators who manage user accounts, and (critically) the end users who visit the site. In a health research institute, that might mean clinicians searching for trial protocols, policy researchers downloading datasets, and PhD candidates looking for supervision opportunities. Each group has different needs, and most of them contradict each other. We need to know that upfront, not six months into the build.

2. Content and data audit

We document every content type, every taxonomy, every integration, every data feed, and every piece of functionality your current site has. We look at what gets used, what gets ignored, and the messy workarounds your team uses to bypass broken features. This is where we find the 47 unused content types and the seven-person approval chain. This is the website planning that most agencies skip.

3. User journey mapping

We map how real people use your site today versus how they should use it. For a health research institute, this might mean understanding that a clinician looking for trial recruitment guidelines and a policy researcher looking for population health data have completely different needs from the same website. For a university faculty, it might mean prospective students, current researchers, and industry partners all landing on the same homepage and needing entirely different paths. If we design for one and ignore the others, we have built half a solution.

4. Technical requirements definition

We assess your hosting environment, your CMS needs, your accessibility requirements (WCAG 2.2 AA is non-negotiable for any organisation receiving government funding), your security posture, and your technical setup. We identify what can be reused and what needs replacing.

5. Strategic roadmap

At the end of the workshop, you get a document. Not a quote. A roadmap. It tells you what needs to be built, in what order, why each component matters, and what it will cost. You own this document whether or not you work with us. It is yours. Take it to another agency if you prefer. It will make their proposal better too.

What changes when you start with discovery

Scope clarity. When everyone, from your CEO to your content editors, has been heard during discovery, the project scope reflects reality rather than assumptions. You stop discovering “surprise” requirements mid-build.

Accurate budgets. A quote built on discovery data lands within 10-15% of the final cost. A quote built on an RFP response routinely lands 40-60% off. For a health research organisation working with fixed grant funding, that difference can kill a project entirely.

Shorter timelines. Projects that skip discovery spend their first 8-12 weeks in a prolonged “requirements gathering” phase that duplicates what a Discovery Workshop does in two weeks, except now you are paying the full project team to do it instead of a dedicated strategist.

Better relationships. It gets us on the same side of the table. We’re working from the same data, not arguing over assumptions. We have clients who started with a Discovery Workshop seven years ago and have never left. That is what happens when you begin with trust instead of a tender.

Start here this week

If you have a website project on the horizon, do one thing before writing that RFP.

List every person in your organisation who touches your website. Not just the project owner. Include the content editors and the IT team managing hosting. Don’t forget the researchers uploading data or the communications manager scheduling campaigns. Even the reception staff who field phone calls when the site is confusing should be on there.

Write their names down. Next to each name, write the single biggest frustration they have with the current website.

That list is the beginning of a genuine project scope. It is also exactly what a Discovery Workshop is designed to capture, except we do it with methodology, experience, and the ability to turn your frustrations into architecture.

Frequently asked questions

How long does a discovery workshop take?

Most run between two and four weeks depending on organisational complexity. A single-site NFP is faster. A multi-faculty university with six integrated research platforms takes longer.

Can we use the discovery workshop output with another agency?

Yes. The roadmap document is yours. We build it so that any competent agency can use it to deliver an accurate proposal. Most clients stay with us after discovery because the relationship and shared understanding are hard to replicate, but you are never locked in.

What does a discovery workshop cost?

Discovery workshops start at $3,500. The cost scales with the complexity of your organisation, the number of stakeholders involved, and the depth of technical integration required.

We already have a brief. Can we skip discovery?

If your brief covers stakeholder needs, content architecture, technical integrations, user journeys, and accessibility requirements in detail, you might not need a full discovery. In practice, we have never seen a brief that does. The briefs we receive from communications managers at research institutes and universities are written by smart people working under pressure. Discovery fills the gaps they didn’t have time to investigate.