Web stack

The web stack is the thing your users actually touch. We picked Next.js as the foundation and never looked back.

Next.js 14 (App Router)

We standardize on Next.js 14 with the App Router. Why:

• Best SEO of any React framework, by a wide margin. Server-rendered pages, structured data, sitemap generation, image optimization — all built in.
• Server components keep data-fetching logic on the server where it belongs. Less code shipped to the browser, faster initial loads.
• Stable enough to bet a five-year codebase on. Vercel maintains it, the community is enormous, and breaking changes between versions are well-managed.
• Great deployment story. Push to main, it's live in 90 seconds. Preview branches per PR. Rollbacks in one click.

We use the App Router, not the older Pages Router, because the App Router is where the framework's future lives. New projects should not be starting on the Pages Router.

TypeScript

Every Solagon project is TypeScript, not plain JavaScript. The 5–10% extra time at write-time pays for itself many times over in maintenance — both for our team and for whoever inherits the code.

We use strict-mode TypeScript with a few sensible exceptions. The compiler runs as part of CI and a build doesn't ship if the types don't check.

React 18

Standard React with hooks. We don't use class components in new code. We use server components where they fit and client components where interaction is required.

We're conservative about adding state-management libraries. React's built-in state + context covers most needs. If we genuinely need something beyond that we reach for Zustand or React Query / TanStack Query — both small, both proven.

Tailwind CSS

Tailwind for styling, with a design token layer built on CSS variables.

The design tokens live in globals.css and define the brand: colors, spacing scale, type scale, radii. Tailwind classes consume those tokens. New developers reading the codebase can see the design system in one file rather than reverse-engineering it from a thousand component files.

Component library

We don't use a third-party component library by default. Most projects ship with a small in-house set of primitives (Button, Input, Card, etc.) that match the brand instead of a bolt-on like Chakra or Material UI.

For richer UI work — date pickers, command menus, command palettes, etc. — we reach for headless libraries like Radix UI or Headless UI, which give us behavior without imposing a visual style.

Animation

Tailwind's transition utilities cover 90% of the cases. For richer animation we use Framer Motion, kept lazy-loaded so it doesn't bloat initial bundles.

Forms

We don't standardize a form library. Most forms are simple enough that controlled React state is plenty. For complex forms — multi-step, with validation rules — we reach for React Hook Form. We deliberately avoid form libraries that ship a runtime schema engine (Formik) — they're heavier than they look.

Image handling

next/image for everything. Image sizes are pinned at the source level so we don't ship 4MB hero images the user has to scale down. Critical images are pre-rendered above the fold; the rest lazy-load.

What we don't use

• WordPress, Wix, Squarespace, or any template-based platform. Every Solagon site is custom code.
• Gatsby. We migrated off years ago and don't miss it.
• CSS-in-JS runtimes (styled-components, Emotion). Tailwind is faster, simpler, and ships zero JS for styling.
• Redux for new projects. The use cases that genuinely need it are rare.

Where to go next

Data & backend → AI & integrations →