This is part two of the stack writeup. Part one covered the technical side: frontend, UI, content API, database, auth, uploads, deployment, and tooling. This post is about the operational decisions that sit on top of that stack: how the inquiry flow actually works, why I lean on CloudFront cache, the SLO and SLA I am willing to commit to, and the disaster recovery plan. The shape of the project The website is for a brick and mortar business that needs a proper web presence. The goal is quite practical: Show catalog items, services, and offers clearly. Let staff update content without touching code. Let customers send an inquiry with enough details. Generate a reference code so WhatsApp discussion is easier to track. Keep the system small enough that I can operate it myself. That last point is important. I do not want to run a big platform for a small business website. I want something that I can understand when it breaks. Inquiry flow: form, database, WhatsApp The inquiry form is the main conversion feature. Customers can choose catalog item, offer, service, or custom request. They can fill in quantity, size, option details, deadline, urgency, delivery method, contact details,...
I have been building a website for a brick and mortar business recently. It is not only a brochure site. It has catalog pages, offer pages, an inquiry form, staff admin panel, image upload, lead dashboard, and WhatsApp handoff. The project is split into two repos: one repo for the public website and admin UI one repo for the content API, database, upload, and inquiry backend I want to write down the stack while it is still fresh, because I know I will forget the small decisions later. This is not a "best stack for everyone" post. It is just what I use, what problem it solves, and why I am okay with the trade off. This is part one. I will cover the technical stack: frontend, UI, content API, database, auth, uploads, deployment, and tooling. Part two covers the operational side: the inquiry flow, caching decisions, SLO/SLA, and disaster recovery. Frontend: TanStack Start The frontend is built with TanStack Start, React 19, TanStack Router, and Vite. I picked it because I wanted server-side rendering, file-based routing, and normal React without going too far into a full framework that hides too much. The routes map quite directly to the business:
← All tags
