Does a local service or delivery business need an SPA? An honest comparison
An SPA is not a sign of modernity but a trade: you pay in JavaScript weight and SEO complexity for smooth transitions. Sometimes that trade pays; often it does not.
What an SPA means technically
A classic SPA serves near-empty HTML and assembles the interface in the browser from a JavaScript bundle. Navigation happens without page reloads and data arrives via separate API calls.
The cost is time to first paint: the user waits for the bundle to download and execute before seeing anything. On a fast device that is tenths of a second; on a budget Android over 3G it is several seconds of blank screen.
The modern compromise is server rendering with hydration: HTML arrives complete and interactivity layers on top. In Next.js that is the default, and it covers most scenarios without choosing an extreme.
SEO: where the problems actually appear
Google can execute JavaScript, but does so in a second pass and with delay. For a catalogue of thousands of pages that means slow, partial indexation; for a fast-changing assortment, a permanently stale index.
Meta tags, canonicals and hreflang injected client-side are missed by some crawlers. Every SEO-critical element must be in server-rendered HTML — a requirement, not a suggestion.
A typical SPA failure is navigation without changing the URL, or via hash fragments. Pages without their own address are neither indexable nor shareable, which matters especially for a Telegram-driven local audience.
When an SPA is genuinely justified
Customer accounts, courier panels, dispatcher interfaces, order builders with many dependent fields, live maps tracking a driver — all sit behind authentication, have nothing to index, and carry complex, constantly changing state.
The signal that an SPA fits: the user spends minutes in the interface performing dozens of consecutive actions. The one-time bundle cost is repaid in smoothness.
The opposite signal: the user arrives from search, views one or two pages and converts to a call or order. Here the bundle download is pure loss.
A typical local scenario: food delivery
The sensible architecture is mixed. The public part — menu, categories, dish pages, delivery information — is server-rendered or statically generated, because that is what gets indexed and brings traffic.
Cart, checkout and order tracking are the interactive part, living client-side against an API. They need no indexation, but responsiveness is critical.
Consider a Telegram Web App as a second interface for repeat orders: regulars order through the messenger while search traffic lands on the server-rendered site.
The cost in development and maintenance
A full SPA needs a separate API, deliberate state management, offline handling and network error paths. That is substantially more code than server rendering with forms, and costlier to maintain.
Market guidance: a server-rendered site with an admin panel from 25,000,000 UZS; a project with an SPA account area, separate API and roles from 60,000,000 UZS. The gap is almost entirely the interactive part.
Factor in the cost of failure modes too: broken hydration, state desynchronisation and memory leaks in a long-lived tab are problems that simply do not exist with server rendering.
How to decide
Split the site into public and authenticated parts and decide separately for each. Mixed architecture is the norm rather than a compromise, and modern frameworks support it directly.
The real question is not 'SPA or not' but 'which pages must be indexed, and how fast must they appear on a weak connection'. The answer determines architecture almost unambiguously.
If a contractor proposes an SPA for a service site with a contact form, ask what problem it solves. Usually the answer is developer convenience, and the bill is paid in speed by a user on 3G in the regions.