Small business websites are interesting because the problems are rarely theoretical. If the site is awkward on phones, people notice. If prices or menu copy are hard to change, staff feels it immediately.
The goal here was simple: make it feel like the shop, make it easy on mobile, and make sure the team could update it without waiting on me. Bright, playful, direct. No overbuilt restaurant platform. No CMS that only makes sense to engineers.
Build
I built the site with Next.js, Tailwind, Sanity, and Vercel. Sanity handles the parts staff need to change. PostHog gives enough signal to see what visitors actually use without turning a dessert shop website into an analytics science project.
Ordering is not live yet, but the interface leaves room for it. That matters because the next step should not require throwing the site away when they are ready to connect a POS.
After launch
The handoff mattered as much as the deploy. If I am still the bottleneck after launch, I did not really finish the job. Training and short docs made the site more independent, which is the real win for a small business project. On the next client build, I would plan that handoff even earlier instead of treating it as the final step.
problem
The shop needed a site that worked on phones, made the menu easy to update, and matched the energy of the business without turning every copy or price change into a developer task.
constraints
- The business needed polish, but the site still had to stay simple enough for staff to maintain.
- Menu and content changes had to move through a CMS instead of ad hoc developer edits.
- The ordering path needed to be considered without pretending POS integration was already live.
what it taught me
- For small businesses, handoff is part of the product. A CMS only helps if the client can really use it.
- Analytics should answer practical questions, not turn a simple site into surveillance software.
- The best technical choice is often the one that removes a future dependency on you.
