A brochure site is a pamphlet. A single-page app is a tool. If your users log in, complete a workflow, and come back tomorrow, you are no longer in pamphlet territory.
We still love a fast marketing site. They have a job: explain the offer, collect a lead, get out of the way. The trouble starts when a growing product is forced to live inside that shape. Forms that should be an application become a pile of plugins. State lives in the URL until it does not. The CMS becomes a hostage.
Signals you have outgrown the pamphlet
You need a SPA when the session matters. Authenticated dashboards. Multi-step booking or onboarding. Real-time status. Two-sided flows where one person lists and another books. If the interface has to remember who you are and what you were in the middle of, a traditional page-by-page site will fight you.
You also need one when the frontend and the API should be able to change on different clocks. A React and TypeScript SPA talking to a dedicated API lets the product team ship UI without waiting on a theme deploy, and lets the API grow tenancy, payments, and jobs without dragging the marketing pages along for the ride.
What we actually build
Our SPAs are not “React for its own sake.” They are typed clients with clear routes, honest loading and empty states, and an API contract the rest of the business can trust. Postgres holds the source of truth. Express (or Laravel, when the admin is the center of gravity) owns auth, tenancy, and side effects. The marketing surface can stay a fast static or CMS site. The product lives where it can be tested.
The cost of getting this wrong
Bolt a product onto a marketing theme and you will pay for it in support tickets. Users will lose work. You will be afraid to deploy on Fridays. A SPA is not automatically better. It is better when the job is an application. We will tell you if it is not.
If you are staring at a site that is trying to be software, bark at us. We will help you draw the line between the story and the tool.