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,...
← All tags
