Web application development
A web application is software that runs in a browser and does work — authenticating users, storing records, enforcing rules, moving money. A website presents information; a web application changes state. That distinction drives every architectural decision that follows.
The architecture decision that matters most
Almost every debate about frameworks is downstream of one question: where does the HTML come from?
Server-rendered pages arrive complete. The browser paints immediately, and a crawler that cannot execute JavaScript sees the same content a person does. The cost is a round trip for each navigation.
A single-page application ships a JavaScript bundle that renders in the browser. Navigation is instant once loaded, and the first load is heavier — often much heavier. Content is invisible to anything that will not run scripts, which still includes a meaningful share of crawlers and preview bots.
The pragmatic answer for most business applications is to split by page type. Marketing and content pages are server-rendered or fully static, because they must be fast on a cold visit and indexable. The logged-in application is a SPA, because nobody is indexing your dashboard and users navigate it constantly.
This site is a working example: the homepage is pre-rendered to static HTML and then hydrated, so the first paint has no JavaScript dependency at all.
Performance is an architecture problem, not a plugin
Performance work is usually sold as an afterthought and is almost always structural. The wins that matter come from removing things from the critical path, not from adding a caching layer at the end.
When we rebuilt this site, the mobile Lighthouse score went from 30 to 97. Nothing clever was involved. We pre-rendered the page instead of booting React to produce the first paint, replaced a CDN Tailwind build with compiled CSS, self-hosted the fonts and images so there was no third-party connection in the critical path at all, and gated an expensive WebGL scene off phones entirely. Total blocking time went from 69,920 ms to 60 ms.
The same pattern applied to a rental marketplace took its mobile score from 74 to 89 and its page weight from 1,208 KB to 758 KB — self-hosted variable fonts, localised imagery, deferred hero assets.
What we build with, and why
Node.js and Express on the server, PostgreSQL for data, React where a rich client is warranted, and server-rendered templates where it is not. Redis for queues and caching. PM2 behind nginx for process management, with deployments that are scripted rather than remembered.
None of that is exotic, and that is the point. A stack chosen for novelty is a stack your next engineer cannot hire for. We would rather spend the innovation budget on your problem domain than on our tooling.
- PostgreSQL with real constraints and race-tested sequences for anything a human reads or a regulator audits
- Background job queues for work that must not happen inside a request
- Structured logging that is useful at 2am and does not leak credentials into a log file
- Staging that mirrors production closely enough to be worth testing on
The parts clients forget to budget for
Authentication is never just a login form: password reset, session revocation, role changes and account recovery are each a small project. File uploads need validation, storage, and a decision about what happens when the disk fills. Email delivery needs a real sending domain and monitoring, or your password resets land in spam.
None of this is visible in a design mockup, and all of it is the difference between a demo and a system people can rely on.
Frequently asked
What is the difference between a website and a web application?
A website presents information — pages, articles, contact details. A web application performs work and changes state: users log in, records are created and updated, rules are enforced, payments are processed. Web applications need database design, authentication, permissions and background processing that a brochure site does not.
Should we build a single-page application or server-rendered pages?
Split by page type. Public marketing and content pages should be server-rendered or static so they load fast on a cold visit and are visible to crawlers. The logged-in application is usually better as a single-page application, since nobody indexes a dashboard and users navigate it constantly.
How do you make a web application fast?
By removing work from the critical path rather than adding caching at the end. In practice: render the first paint without waiting on JavaScript, self-host fonts and images so there is no third-party connection blocking, compile CSS rather than generating it in the browser, and defer or gate anything expensive on low-power devices.
Which technology stack do you use?
Node.js and Express, PostgreSQL, Redis, and React where a rich client is justified. Deployed with PM2 behind nginx. Deliberately conventional — a stack chosen for novelty is one your next engineer cannot be hired for.
Related
Want this built?
Tell us what you are trying to ship and we will tell you honestly whether we are the right team for it.