The most important weeks of any project

Most agencies will tell you they do discovery. It's in the proposal, somewhere between the methodology diagram and the timeline. But a lot of the time it gets compressed into a few days of workshops, or it gets skipped entirely because the client already has a spec.

We don't skip it. Every project at brytloop starts with a proper discovery phase, regardless of how clear the brief seems. The length varies — sometimes it's a couple of weeks, sometimes longer — but it always happens. Here's why.

The brief is never the full picture

Clients come to us with a problem they've been thinking about for months, sometimes years. They've usually got a solution in mind. "We need a new portal" or "we need to replace this spreadsheet with a system." And they're often right about the what. But the why behind it — the processes, the workarounds, the stakeholder politics — that's where things get interesting.

In discovery, we talk to the people who'll actually use the thing. Not just the project sponsor, but the case workers, the administrators, the team leads who've been patching gaps with email and sticky notes. That's where you find the requirements that didn't make it into the brief.

What discovery actually looks like

It starts with listening. Stakeholder interviews, process mapping, looking at the systems already in place. We're trying to understand how work actually flows through the organisation, not how it's supposed to flow according to the policy document.

Then we start pulling things apart. Map out the data, identify the integration points, flag the technical constraints. If there's a legacy system involved — and there usually is — this is when we figure out what it actually does versus what people think it does.

Finally, synthesis. We pull together our findings into something concrete: a proposed architecture, a prioritised backlog, a realistic estimate. The client gets a document they can actually make decisions from, not a vague set of recommendations.

Why this keeps working

The projects that go badly are almost always the ones where someone started building too early. They committed to a database schema before understanding the data. They picked a framework before knowing the constraints. They estimated 12 weeks and hit 30.

Discovery costs time upfront, but it saves significantly more later. We've caught scope problems early on that would have been six-figure mistakes in month four. We've found existing systems that did 80% of what the client wanted to build from scratch.

It's not exciting work. Nobody's going to write a case study about a really good stakeholder interview. But it's the difference between a project that delivers and one that drags.

When there's pressure to move faster

Some clients have tight timelines. Budget pressure, a fixed deadline, a minister who wants something live by April. We get it. The answer isn't to skip discovery — it's to scope it tighter. Focus on the riskiest assumptions. Map the happy path. Identify the things most likely to derail the project and stress-test them early.

The worst thing you can do is start building something nobody fully understands. That's how you end up six months in with a system that technically works but doesn't solve the problem.

A short, focused discovery phase is the best investment any project can make. Everything after it goes faster.