typical quote request asks you to already know the answer: pick a package, pick a page count, pick features off a list written by someone who's never seen your business. That works fine if you already know exactly what you need. Most people asking for a website or an app don't — they know something is costing them customers or time, and they're hoping the person on the other end can translate that into the right build. So we start there instead.
Theproblemcomesfirst.Whatactuallyfixesitcomessecond.Thepackagecomeslast,andonlyafterbothofthosearesettled.
That's not summarized or paraphrased — it's reading directly out of PAIN_POINT_BRIEFS in lib/pricing.ts, the same structured data our own sales process uses internally to make sure every conversation about "no online booking" or "slow site" actually lands on the same real cost and the same real fix, instead of depending on whoever happens to be on the call that day to remember it correctly.
Every pain point in that file distinguishes between what genuinely fixes the problem (needs — no fix without it) and real, useful extras that are only worth raising once the core is agreed (upsell). "No online booking" needs a booking system; a CRM integration is a legitimate upsell on top of that, not a substitute for it. Keeping those two lists structurally separate in the data means a scope can't accidentally include the extra while skipping the actual fix, and it means a conversation about your problem doesn't turn into a conversation about add-ons before the core has even been agreed.
It replaces the version of this conversation where the actual diagnosis lives entirely in one person's head, gets phrased slightly differently every time, and drifts a little further from what actually matters each time it's retold. Writing it down as structured data — a real problem statement, a real cost, a real fix — means the diagnosis is the same whether you talk to us on a Tuesday or a Friday, and it's the same thing driving both the conversation and the actual scope that gets built.
A redesign should begin with the failure the business can observe, not with a request to make the homepage more modern. Useful evidence includes search queries, analytics, form completion, support questions, sales objections, device breakdown, accessibility complaints, editing delays, performance data, and the manual work staff perform because the current system cannot.
- Traffic but few enquiries may point to unclear positioning, weak proof, poor calls to action, or a broken conversion path.
- Qualified enquiries with slow follow-up may point to routing, CRM, notification, or internal workflow problems rather than page design.
- Search visibility falling after years of edits may require a content and technical audit before any URL structure changes.
- A site that is difficult to update may need a better content model and ownership process, not simply a visual refresh.
- Customers repeatedly calling for basic tasks may reveal the case for a portal, booking flow, or account area.
Once the problem is specific, the project can define what improvement looks like. That might mean reducing steps in an enquiry, preserving every valuable search URL during migration, letting staff update a service without developer help, meeting keyboard and screen-reader requirements, or recording leads reliably in the system the sales team already uses. These are testable outcomes; make it pop is not.
The answer may be smaller than a rebuild. Fixing a form, clarifying the offer, repairing analytics, improving performance, or reorganising a high-value journey can be the responsible first phase. Discovery earns its keep when it can recommend less work as confidently as more.