An SPA is a web app that you load once, after which all navigation and interaction happens client-side — think Gmail, Trello, Notion or Figma. We build custom SPAs for dashboards, customer portals and SaaS products where the app feel and speed determine the user experience.
With a traditional website (a multi-page application), every click requests a new HTML page from the server. With a Single Page Application, the browser loads a JavaScript bundle once, and the app then handles all navigation, data exchange and state itself. To the user it feels like a desktop or mobile app: instant transitions, no flash of white, and the sense that everything responds immediately. Classic examples you use every day are Gmail, Google Maps, Trello, Notion and Figma — all SPAs.
That makes an SPA the right choice for products where users spend longer sessions — dashboards, project management tools, customer portals, configurators and real-time applications. For a marketing site or content platform, an SPA is usually not the best idea, and we're honest about that. We work through the trade-offs between an SPA, a server-rendered MPA or a hybrid approach with islands (Astro) with you before a single line of code is written.
We have been building SPAs for SaaS vendors, B2B portals, admin panels and mobile-first web apps for years. Each time custom, each time TypeScript from start to finish, and each time with attention to the areas where SPAs have traditionally been weak: fast initial load, accessibility and behaviour on poor connections. We are happy to discuss how a SPA fits within the wider range of web development in an introductory call.
Most SPA enquiries we receive fall into one of three patterns. Which one fits depends on the type of product and the level of real-time interaction. We advise on this in the first conversation.
A logged-in environment in which users view data, review reports and carry out actions. React or Vue 3 as the front end, a REST or GraphQL API underneath, and a component library such as shadcn/ui or Radix UI for the UI building blocks. Suited to B2B portals, vendor dashboards and in-house admin tooling.
A full-scale product with multiple roles, an extensive data model and carefully considered UX flows. Think of a planning app, a Trello-style board, or a vertical SaaS for a specific sector. A modular front end, type safety from database to UI, and a design system that grows alongside the product.
A SPA where live updates, collaboration or an offline flow are central: a chat platform, a monitoring dashboard, a trading environment or a field app that must keep working without an internet connection. WebSocket or Server-Sent Events for the stream, service workers for the PWA layer, and installable on both desktop and mobile.
An SPA consists of more than just a framework. Each of these choices affects development speed, maintainability and how well your team can keep the app running in a few years' time. A brief tour of what we typically use and why.
React with Vite or Next.js is our most frequently chosen stack — the largest ecosystem and the easiest to expand a team around. Vue 3 with the Composition API and Nuxt is a fine alternative, particularly for teams with a Vue background. We choose Angular for enterprise projects where TypeScript strictness is central. Svelte or Solid.js for lightweight or performance-critical apps.
For most apps we start with TanStack Query for server state plus Zustand for local UI state — simple and scalable. We reserve Redux Toolkit for complex domains where time-travel debugging adds real value. In Vue projects, Pinia is the standard. We avoid state spaghetti through clear conventions from sprint one.
Forms are where many SPAs run into trouble: validation rules that drift out of sync with the back end, poor error states, inaccessible labels. We work with React Hook Form and Zod schemas that we share between client and server, so that a single source of truth governs validation. In Vue we use FormKit with the same pattern.
For customer portals, we often choose Auth0 or a comparable hosted IdP: quick to go live, social logins included for free, and SAML and SSO as you grow. For privacy-sensitive sectors or on-premise requirements, we use Keycloak, which you can host yourself. We only build a custom JWT stack if the requirements are truly unique, because authentication mistakes are expensive.
A SPA is only as good as the API beneath it. We build REST with Spring Boot, Node or Django; GraphQL with Apollo or Hasura when the data model is relational and the UI needs many different slices of it; and tRPC when client and server both run in TypeScript and we want end-to-end type safety without schema generation.
For chat, multi-user collaboration and live dashboards we use WebSockets, either via Socket.IO or a managed service such as Pusher or Ably. We choose Server-Sent Events when the stream is one-way, as they are simpler to scale. For Elixir/Phoenix backends we make use of Phoenix Channels, which are built precisely for this type of real-time UI.
A production-ready SPA, plus everything around it needed to manage it yourself, extend it, or hand it over to another team. No black boxes.
Four patterns where a Single Page Application genuinely adds value. If your situation matches any of these, we would be glad to talk further.
Your users don't stay for five seconds; they work in the tool. A full-page reload on every click breaks that rhythm. A SPA feels like a desktop or mobile app.
A dashboard with live KPIs, a chat, a trading screen, a monitoring cockpit. SPAs using WebSockets or Server-Sent Events show updates without the user having to look for a refresh button.
Filters, drag-and-drop, multi-step forms, nested tables, in-place editing. This kind of UI calls for client-side state management, and that is what SPAs are built for.
A field engineer with no 4G signal in a basement. A tablet app for the shop floor. PWA functionality on top of a SPA allows installation to the home screen and a workable offline mode.
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →A conversation in which we understand which flows the SPA needs to support, which types of users will work with it, and where it integrates with your existing landscape. We often also compare a SPA against a server-rendered alternative here, because not everything needs to be a SPA.
Together we decide on the framework (React, Vue or sometimes Svelte), the state approach, the authentication layer and the backend strategy. In parallel we work out the first screen flow in Figma with you and a few end users, so that the build starts from a design everyone supports.
A working build you can test every two weeks. We build by skinning horizontally: first a working end-to-end flow with one role, then depth, then additional roles. Performance budget and a11y checks run from sprint one.
Pen test, accessibility audit (WCAG 2.2 AA), Lighthouse report, and a phased rollout to your users. After that we can handle the management, or hand it over neatly to your own team with a runbook and a few handover sessions.
An SPA is not automatically the right choice. Below are the three most common alternatives and when they are a better fit. We discuss this openly in the first conversation: if an SPA doesn't suit you, we'll say so.
A classic server-rendered website built with Rails, Django, Laravel or Spring. Better for content-heavy sites, marketing pages and publications that need to rank highly in search engines. No JavaScript requirement on the client, fast first paint, straightforward SEO. We use this for your public website and choose an SPA for the logged-in tooling behind it.
Astro renders server-side by default, but lets you add "islands" wherever interactivity is needed. This combines the SEO strengths of server rendering with the interactivity of React or Vue on specific parts. A good compromise for sites that are part content, part app, such as a marketplace with product pages plus a logged-in dashboard.
When you need deep hardware access (camera, Bluetooth, push notifications on iOS), a genuine offline flow over long periods, or distribution through the App Store for consumer reach, a native or hybrid app is often the better choice. We advise on this and build them too, but for many use cases a PWA based on an SPA is a cheaper and faster route to the same result.
For internal tools or an initial validation, no-code platforms can quickly deliver something that works. They become limiting when you need your own branding, complex roles, real-time functionality or custom integrations, and a lock-in soon develops that is costly to unwind later. We often advise: start with no-code for the initial validation, then move to a custom SPA once the product has proven itself.
The questions clients ask before we begin an SPA project.
A no-obligation introductory call of half an hour. We listen to what you want to build, think along with you about the technology choice, and are honest if an SPA isn't the best form for your challenge. We're also happy to advise on questions around microservices architecture or a broader enterprise software strategy.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
