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.
Pick what sounds familiar
what's actually wrong
They have no website at all — anyone who hears about them has nothing to look at.
what it's costing you
Every person who searches their name finds a competitor instead. They're paying for word of mouth and then losing it at the last step.
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.
Why 'needs' and 'upsell' are kept separate
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.
What this replaces
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.