Performance problems are rarely caused by one bad query. They come from accumulation: an unoptimised hero image, six analytics scripts, a carousel library shipping 80kb of JavaScript for a five-second animation.
Set a performance budget during design. Decide the largest allowed hero image, the script budget per page and the Core Web Vitals you will hold yourself to. Then treat exceeding the budget as a design change, not an engineering task.
Teams that do this ship faster sites because the constraint shapes the design early, when changing it is still cheap.Off-the-shelf platforms are excellent when your process matches the mainstream. The cost is not the licence; it is the workarounds.
Build custom when your process is a competitive advantage and you cannot afford to flatten it. Avoid building custom when you are optimising a routine that most of your competitors already run the same way.
The honest middle path is usually a platform for the commodity parts and custom integrations where your advantage lives.A project brief should answer three questions before it talks about technology.
What is broken today? Describe the process, not the tool. Who does what today, where does it slow down, and what does it cost you?
What does better look like? Give us a measurable outcome — time saved, errors reduced, revenue recovered.
What must not break? Existing integrations, data you cannot lose, compliance constraints.
Everything else — stack, architecture, timelines — follows from those answers. When those three are clear, the technical conversation becomes short.