Skip to content
Back to blog Development

From boilerplate to product: our React & TypeScript stack

M Mocoda Studio May 8, 2026 7 min read

Every studio has a default stack — the set of tools it reaches for without re-litigating the decision each time. Ours has settled, after a lot of shipped projects, into something deliberately boring and deeply productive. Here’s what we build with, and more importantly, why.

React and TypeScript, together

React is the obvious part; TypeScript is the part we’d fight to keep. Types aren’t paperwork — they’re the cheapest tests you’ll ever write. They catch the typo, the renamed prop, the “this can be undefined” bug before the code runs, and they make refactoring feel safe instead of terrifying. On a small team that can’t afford a huge QA process, the compiler is an extra pair of hands that never gets tired. The upfront cost of typing things is paid back the first time you rename a field and the editor shows you every spot that needs updating.

Vite for the dev loop

The dev loop is where the hours actually go, so we optimise for it ruthlessly. Vite gives near-instant startup and hot module replacement that updates the screen faster than you can look away — change a line, see it immediately, never lose your place. It sounds minor. It isn’t. A fast feedback loop changes how you work: you experiment more, you catch problems sooner, and you stay in flow instead of waiting on a spinner a hundred times a day.

Tailwind for styling

Tailwind gets argued about, so here’s our honest take: it keeps styling local and consistent. Styles live right next to the markup they affect, so you’re never hunting through a stylesheet wondering what a class does or whether it’s safe to delete. A shared design-token config — colours, spacing, type scale — keeps everything on-system without anyone memorising hex codes. And because the build strips everything unused, the shipped CSS is tiny. It’s not the only way to do it, but for a small team moving fast, it removes a whole category of bikeshedding.

Astro for content and marketing sites

Not everything should be a single-page app. For marketing sites and blogs — like this one — we reach for Astro. It ships almost no JavaScript by default, renders content to fast static HTML, and still lets us drop in a React component on the rare occasion a page needs interactivity. The blog you’re reading is Markdown files compiled to static pages at build time. It’s the right tool when the job is “be fast, rank well, and be easy to update,” which is most of the web.

Tauri when it needs to be a desktop app

When a product genuinely belongs on the desktop — Flow, Notes, and Pulse all do — we wrap the same React UI in Tauri, which produces a real native application instead of a browser tab. That buys things the web can’t do cleanly: global shortcuts, a system-tray presence, a fast local database, and a properly installable, signed app. Crucially, we reuse the web skills and much of the web code; Tauri changes the shell, not the whole discipline.

Local-first by default

Across all of it, we lean local-first: the app’s data lives on the device, and the network is an enhancement rather than a dependency. It makes apps faster, more private, and cheaper to run — and it’s a deliberate architectural choice we make at the start, because retrofitting it later is painful. (We wrote a whole piece on why, if you want the long version.)

The boring parts that matter

The unglamorous habits are what make the stack hold up: types enforced rather than optional, builds and checks run locally before anything is pushed, and dependencies kept lean so the project still installs and builds cleanly a year from now. None of this shows up in a demo. All of it shows up the day a client asks for a change and we can make it quickly and confidently. A stack isn’t a trophy shelf of trendy tools — it’s whatever lets us turn an idea into reliable, shipped software, and then keep it healthy. This is ours.