“Can’t you just start building?” is a fair question when a project feels urgent — and it’s usually the wrong instinct. A week spent on discovery before any code gets written isn’t a delay. Done properly, it’s the single highest-leverage week in the whole engagement, because it’s the cheapest point at which to be wrong about something.
Here’s what actually happens during a paid discovery week, and why it changes the risk profile of everything that follows.
Stakeholder interviews
Discovery starts with talking to the people who will actually use whatever gets built — not just the person who signs off on the budget. A sales manager, a support rep, a marketing coordinator, and an executive sponsor often describe the same problem differently, and each description reveals a requirement the others didn’t mention. Skipping this step is how projects end up technically correct and practically unused.
A review of what already exists
Before recommending anything new, it matters what’s already there: the current Salesforce org’s actual configuration (not the configuration someone remembers setting up three years ago), the website’s real structure and content, and whatever integrations or workarounds are already quietly holding things together. This review is also where undocumented technical debt tends to surface — the spreadsheet nobody mentioned, the automation someone built and then left the company.
Requirements clarification
“We need better reporting” is not a requirement — it’s a symptom. Discovery is where that gets turned into something specific enough to scope: which reports, for whom, based on which data, updated how often. This step is often uncomfortable in a useful way, because it forces decisions that were being avoided by staying vague.
Technical investigation
Some questions can only be answered by actually looking — what does the current Salesforce data model support without changes, what’s the real condition of the WordPress codebase, does an existing integration have room to extend or does it need to be replaced. This is where “should be straightforward” gets tested against what’s actually there.
Prioritization
Every discovery process surfaces more good ideas than fit in a reasonable first phase. Part of the value is an honest, collaborative ranking — what solves the most urgent problem, what’s a prerequisite for something else, and what’s genuinely a “phase two” idea being disguised as urgent because it’s exciting to talk about.
Risks and dependencies
A written risk list — “this depends on getting API access from a third-party vendor,” “this assumes the current data is clean enough to migrate as-is” — is one of the most underrated deliverables of discovery. Naming a risk in week one is a planning conversation. Discovering the same risk in week six is a schedule and budget conversation, and a worse one.
Architecture direction
Discovery doesn’t produce final technical specifications, but it should produce a clear direction: which integration pattern fits, whether a rebuild or an incremental change makes more sense, what the data model needs to support. That direction is what makes the next phase’s estimate realistic instead of a guess.
Scope definition
Everything above converges into a written scope: what’s included, what’s explicitly not included, and what the stages of delivery look like. This is the document that protects both sides — it’s what a fixed-price stage plan actually gets priced against, rather than an open-ended sense of “and also maybe this.”
What you actually walk away with
A discovery engagement should end with something concrete in hand, not a verbal summary: a written systems and data audit, notes from stakeholder interviews, a prioritized list of what to build and in what order, a named set of risks and dependencies, and a scope and estimate for the next stage. Critically, that output should be useful even if you don’t move forward with the same team — a real discovery deliverable, not a sales pitch disguised as one.
Why this matters more for Salesforce and web projects specifically
CRM and website projects fail less often from bad code and more often from solving the wrong problem carefully. A beautifully built integration between two systems whose data models were never reconciled, or a redesigned website that didn’t account for how content actually gets updated, are both examples of technical execution outpacing the thinking that should have preceded it. Discovery is the correction for that pattern.
What discovery is not
It’s worth being explicit about what a paid discovery week isn’t, since the term gets used loosely elsewhere in the industry. It’s not a free sales call dressed up with a different name — it produces a real, usable deliverable regardless of what happens next. It’s not a substitute for the technical design work that follows — discovery sets direction, it doesn’t produce final specifications or pixel-perfect designs. And it’s not a guarantee that the eventual project will be small or simple — sometimes the most valuable thing discovery reveals is that a project is genuinely bigger than it first appeared, which is far better to know at the start than halfway through.
A short example
A common pattern: a business comes in asking for “a new website.” A week of discovery often reveals that the real, underlying problem isn’t the website’s design at all — it’s that content updates require a developer, or that the site and the CRM behind it don’t share any data, or that three separate tools are each doing part of a job one connected system could do better. The scope that comes out of discovery frequently looks different from the scope that was originally requested, and that difference is the entire point — it’s much cheaper to discover the real problem in week one than to build the wrong solution well.
How this fits our process
This is the “Discover” stage of how we structure every engagement — a paid discovery week that ends in a written recommendation and stage plan, followed by design, build, and support. It’s also the basis of our Assessment engagement, described on the engagement models on our homepage: a fixed-scope audit of your systems and the flow between them, priced and scoped before anything else starts.
If a project feels too big or too uncertain to scope confidently right now, that’s exactly the situation discovery is built for. Book a consultation and we’ll walk through what a discovery week would actually look like for your systems.