How to read a list like this, including this one
Most tool round-ups are assembled from other tool round-ups. You cannot tell by reading one, the writer has often never run half of what they recommend, and the incentives point the wrong way: longer lists rank better, and affiliate programmes pay per referral. So before the list, here is how to check any list, applied to this one.
- Does the writer say they use these, or only that they are good? Those are different claims and only one of them is checkable.
- Can you verify it? Everything below is in the package manifest of the repository this page is served from. If a tool is named here and absent there, we are wrong and you can prove it.
- How long is the list? Twenty tools in a category means the writer is cataloguing rather than choosing. Nobody uses twenty.
- Are there any affiliate links? There are none here, and no relationship with any of these projects. Check for redirects through a tracking domain if you are unsure on someone else's list.
- Is anything ruled out? A list with no rejections is a catalogue. There is a section of them below.
This list is short and boring on purpose. It is what one small studio settled on for one kind of work: content-heavy sites with a content system the client owns. It is not a recommendation for your situation, and several choices here would be wrong for a team of thirty.
What this site is built with
Versions are as of 25 August 2026 and are the ones in the manifest on that date, not the latest available. Where those differ it is usually deliberate.
| Tool | Version | What it does for us |
|---|---|---|
| Next.js | 15.5.22 | The framework. App Router, and static generation for every public page |
| React | 19.0.0 | The rendering model underneath it |
| TypeScript | 5.7.3 | Types, and the reason a content change can fail a build rather than a page |
| Tailwind CSS | 3.4.17 | Styling, constrained to a named type scale a test enforces |
| Firebase | 12.12.1 | Hosting, database, authentication and storage |
| Framer Motion | 11.18.2 | Animation, including the reduced-motion path |
| jose | 5.10.0 | JSON web token handling in the Edge middleware |
| @react-pdf/renderer | 4.5.1 | Renders the client documents to PDF from the same source as the HTML |
That is the complete runtime list bar one: a marker package called server-only, which exists purely to fail the build if server code is ever imported into a client component. It does nothing at runtime and is listed here only so the table above can be described as complete without a footnote.
| Tool | Version | What it does for us |
|---|---|---|
| Vitest | 2.1.9 | The unit suite. 287 tests as of this writing |
| Playwright | 1.62.1 | End-to-end tests, and the browser our measurement scripts drive |
| ESLint | 8.57.1 | Linting, run with --max-warnings 0 so a warning is a failure |
| Prettier | 3.4.2 | Formatting, kept separate from linting on purpose |
| firebase-tools | 15.25.1 | Deployment, and the emulators the rules tests run against |
The one worth explaining is Playwright, because it does two jobs here. It runs the end-to-end suite, and it is also the browser our own measurement scripts drive: the screenshot manifest that catches a page rendering blank, and the Core Web Vitals run. Having a real browser already installed as a test dependency is what made both of those cheap enough to write.
The documentation we actually open
More useful than the tool list, and rarely published. These are the primary sources we go to rather than the summaries of them, and most disagreements about how something works are settled by opening one of these instead of searching.
- MDN Web Docs for anything about the platform itself: HTTP, headers, cookies, browser APIs. It is the reference the browsers themselves point at, and it is where we check rather than where we search.
- Google Search Central for how search actually treats a page. Worth reading directly, because a great deal of secondhand SEO advice describes a version of Google that stopped existing years ago.
- web.dev for performance, and specifically for the definitions of the Core Web Vitals and their thresholds. Thresholds move, so the date you read them matters.
- The Chrome UX Report documentation, which is the difference between the number you measure and the number you are ranked on.
- Schema.org for structured data, over any generator. Generators produce markup nobody on the team can then explain or amend.
- The WCAG quick reference for accessibility, which is more readable than the specification and specific enough to act on.
The pattern is that all six are primary. Reading a summary of a specification is how a team ends up confidently wrong about something that is one click away and settled.
What we deliberately do not use
A list with no rejections in it is a catalogue rather than a set of choices, so here are the choices. None of these are criticisms of the tools themselves and all of them are specific to the kind of work described at the top.
- A hosted CMS. Every site we build ships with a content system the client runs, and a hosted product would put a subscription of somebody else's between a client and their own text. That is the one thing the studio exists to avoid, so the tradeoff is not close for us even though those products are good.
- A component library. The type scale here is a fixed set of named steps with a test that fails when the count grows, which is a constraint a general-purpose library would immediately break. A smaller design surface is easier to keep consistent than a larger one, and consistency is the thing clients actually notice.
- A structured-data generator. The markup ends up in the repository either way, and generated markup is markup nobody can explain when it is wrong.
- Lint rules at warning level. The rule is that either something is worth failing the build for or it is worth deleting. We ran 15 warn-level rules while publishing that opinion, which was its own small embarrassment, and the lint script now runs with --max-warnings 0.
The honest caveat on all four is that they are the choices of a studio doing one kind of work at one size. A team of thirty maintaining a design system across products would be wrong to skip a component library, and a newsroom would be wrong to hand-roll a CMS.
What this does not cover
- Naming a tool here is not an endorsement of the company behind it, and it is not a prediction. Tools get acquired, change licence and change character, and this page is a snapshot of one date rather than a standing recommendation.
- Nothing here is sponsored and there are no affiliate links. We have no relationship with any of these projects beyond using them.
- It is the stack for one kind of work at one size: content-heavy sites for small teams, built by a small studio. Several of the choices, especially the rejections, would be wrong for a larger team or a different product.
- We have not compared these against their alternatives in any rigorous way. They are what we settled on, which is a weaker claim than what is best, and anybody presenting the stronger claim about a whole category should be read carefully.
- Versions are accurate as of the date on this page and will drift. The manifest in the repository is the live answer; this page is a description of it.
- A link resolving is not the same as the page still saying what it said when we read it. Our link checker can catch the first and nothing can automatically catch the second, which is why every source above carries a retrieved date.
Sources
- whatscene.in dependency manifest. Every tool and version named on this page is read from package.json in the repository this site is built from, so the list is checkable rather than asserted. Prettier is the one exception: it is invoked through npx rather than declared as a dependency, and its version is the one recorded by the lint evidence run. Run: package.json and content/LINT-EVIDENCE.md, read 2026-08-25.
- MDN Web Docs, Mozilla. Retrieved 25 August 2026.
- Google Search Central documentation, Google. Retrieved 25 August 2026.
- Web Vitals, Google. Retrieved 25 August 2026.
- Chrome UX Report, Google. Retrieved 25 August 2026.
- Schema.org, Schema.org. Retrieved 25 August 2026.
- How to Meet WCAG (Quick Reference), W3C Web Accessibility Initiative. Retrieved 25 August 2026.
- Next.js documentation, Vercel. Retrieved 25 August 2026.
- Playwright documentation, Microsoft. Retrieved 25 August 2026.
Revisions
- 25 August 2026 First published, with every tool checkable against the repository's own package manifest.
This page is revised in place rather than replaced, so its address does not change.