People often ask what tools we use to build the projects we ship. This article is the answer — the six tools that run every project we deliver, why we picked them, and what we would change if we were starting today. It is opinionated, internal, and probably useful if you are picking tools for a small studio of your own.

The constraints

Two-person studio. Bespoke projects for clients. No two projects the same. Some are one-week MVPs, some are six-month builds. The toolchain has to handle both extremes, and it has to be learnable by contractors and short-term collaborators without a long onboarding ramp.

With those constraints in mind, here is the stack.

1. ASP.NET Core 8 for the back-end

Every project we ship has a back-end, and ASP.NET Core 8 is our default. The reasons:

  • Performance. Regularly the fastest mainstream web framework in independent benchmarks. Important when the client cares about response times.
  • Productivity. Razor Pages for simple apps, minimal APIs for everything else, full Entity Framework Core for data access. The whole toolbox is cohesive.
  • Long-term support. Microsoft commits to LTS releases for years. Clients do not have to worry about the framework disappearing.
  • Cross-platform. Runs on Linux, macOS, Windows. Our studio uses Mac and Linux, our clients run everything. No friction.

For data-heavy apps, we pair ASP.NET Core with EF Core and PostgreSQL. For document-shaped data, MongoDB. We have written about the trade-offs in our MongoDB article.

2. Vue 3 for the front-end

We have covered this extensively in our Vue article and our framework opinion piece. In short: Vue's templates read like HTML, the Composition API scales to large apps, and the ecosystem is large enough for almost any need.

For new projects, we use the Composition API with <script setup>, Pinia for state management, and Vue Router for multi-page apps. For server-side rendering and SEO, we use Nuxt.

3. Vite for the build tool

Vite replaced Webpack in our workflow in 2022 and never looked back. The dev server starts instantly, hot module replacement is near-instantaneous, and the production builds are fast. The Vue, React, Svelte, and vanilla TypeScript templates all work out of the box.

The only downside is some legacy plugins assume Webpack. For new projects, this is rarely an issue.

4. PostgreSQL for relational data

PostgreSQL is the default database for every project we ship that needs one. The reasons:

  • Open source, no surprises. No licence fees, no vendor lock-in.
  • Standards-compliant SQL. Migrations and queries port easily.
  • Excellent tooling. pgAdmin, Postico, TablePlus, Supabase.
  • JSON support when needed. You can store document-shaped data in a JSONB column without reaching for MongoDB.

For tiny projects, we use SQLite. For document-shaped data, we use MongoDB. But for most projects, PostgreSQL is the right answer.

5. Tailwind CSS for styling

Tailwind is controversial in the CSS community. Some love it, some hate it. We love it. The reasons:

  • No naming. No more "what do I call this class?" You apply utility classes directly in markup.
  • No dead CSS. Every class in the markup is used. The build strips anything unreferenced.
  • Consistent design. Built-in spacing, colour, and typography scales enforce consistency.
  • Works well with component frameworks. Vue, React, Svelte all play nicely with Tailwind.

For component-heavy apps, we use shadcn-vue (the Vue port of shadcn/ui) for accessible primitives and Tailwind for the custom styling. The combination produces consistent, accessible UIs with very little code.

6. GitHub for source control and CI

GitHub is where every project we ship lives. The reasons:

  • Familiar to every developer. Lower onboarding friction.
  • GitHub Actions for CI/CD. Free for public repos, cheap for private. Sufficient for most projects.
  • Pull request workflow. Reviewing code before merging is the single best quality practice.
  • Integrated package hosting. GitHub Packages for npm, NuGet, Docker.

For more complex CI needs, we occasionally use GitLab. For simple deployments, Render or Fly.io. For large clients with compliance requirements, AWS or Azure.

What is not on the list

A few tools we deliberately do not use:

  • Redux. Pinia (Vue) and Zustand (React) are simpler and do the same job. Redux's time has passed.
  • Bootstrap. Tailwind is more flexible. Bootstrap is fine but feels dated.
  • WordPress. We have built custom themes for clients in the past. Now we refer WordPress projects to specialists.
  • jQuery. Mentioning it so the older readers know we have moved on. Native browser APIs are enough.

What we would change if starting today

If we were starting a new studio in 2026, the list would look mostly the same, with two changes:

  • Consider TypeScript everywhere. Our newer projects use TypeScript end-to-end (Vue with TS, ASP.NET Core with C#). The productivity gains are real.
  • Add a design system tool. Style Dictionary or Tokens Studio for sharing design tokens across web and any future native apps.

7. Linear for issue tracking

Linear replaced Jira, Asana, and Trello in our workflow in 2023. The reasons:

  • Fast. Keyboard-first design. Every action has a shortcut.
  • Opinionated. One workflow, designed well. No config sprawl.
  • GitHub integration. Branches and PRs link to issues automatically.
  • Cycle planning. Two-week cycles with a clear start and end. Matches our sprint cadence.

We have not opened a Jira instance since switching. The closest competitors are Height and Shortcut. Linear is the standard for small, fast-moving teams.

8. Sentry for error monitoring

Every production app we ship has Sentry. The reasons:

  • Stack traces with context. Every error has the user, the URL, the request, the breadcrumbs leading up to it.
  • Source maps. JavaScript and TypeScript errors map back to the original source, not the compiled bundle.
  • Release tracking. You can see which errors are new since the latest deploy.
  • Generous free tier. Small projects can use Sentry for free indefinitely.

Sentry is one of those tools you forget you have until you need it. Then you cannot imagine shipping without it.

9. Figma for design

Every visual design we ship starts in Figma. The reasons:

  • Browser-based. No installation, no version conflicts, no missing fonts.
  • Real-time collaboration. Multiple designers on the same file, seeing each other's cursors.
  • Component system. Reusable design tokens propagate through every screen.
  • Dev handoff. CSS values, asset export, code snippets — all built in.

We tried Sketch, Adobe XD, and others. Figma won. The combination of real-time multiplayer and browser-based access is unbeatable.

10. Cloudflare for DNS and edge

Every domain we manage goes through Cloudflare. The reasons:

  • Free DNS with fast propagation. Better than most registrars' default DNS.
  • DDoS protection. Free tier includes basic protection.
  • SSL certificates. Free, automatic, renewed forever.
  • Workers for edge logic. JavaScript that runs in 200+ locations worldwide.

For projects with serious security requirements, we add Cloudflare's WAF and rate limiting. For most projects, the free tier is plenty.

The hosting stack

For deploying the apps we build, the stack:

  • Docker for containerisation. Every project has a multi-stage Dockerfile.
  • Render or Fly.io for the application servers. Both have generous free tiers and excellent DX.
  • Neon for managed PostgreSQL. Serverless, with branching for previews.
  • MongoDB Atlas for managed MongoDB. The free tier covers small projects.
  • Cloudflare R2 for object storage. S3-compatible, no egress fees.

We have moved away from managing our own servers. The economics of serverless and managed databases are too compelling for a small team. We pay a premium for the simplicity; we get back hours every week.

The full picture

Putting it all together: a typical project we ship in 2026 runs on ASP.NET Core 8 + Vue 3 + Vite + Tailwind, deployed via Docker to Render or Fly.io, with PostgreSQL on Neon or Supabase, source on GitHub, issues in Linear, errors in Sentry, designs in Figma, and DNS through Cloudflare. Every piece is replaceable; the constellation is not.

If you are building a similar stack, do not feel obligated to use the same to

Further reading

This article is opinionated about a specific stack. For each tool we list, the official documentation is the source we trust — everything we say here should be checkable against the docs themselves.

  • ASP.NET Core documentation — the official Microsoft documentation for ASP.NET Core, covering Razor Pages, minimal APIs, and the hosting model.
  • Vue.js official guide — the official Vue 3 guide referenced in this article, including the Composition API and the reactivity system.
  • Vite documentation — the official Vite documentation, covering dev server configuration, build pipelines, and plugin authoring.
  • PostgreSQL documentation — the official PostgreSQL documentation, including the SQL reference, the server administration guide, and the performance tips chapter.
  • Tailwind CSS documentation — the official Tailwind CSS docs, including the utility-first philosophy, configuration, and the v4 migration notes.
  • GitHub Actions documentation — the official GitHub Actions docs, covering workflows, runners, secrets, and reusable actions.
ols. These are what works for our constraints. Your constraints are different. The most important tool is the team and the discipline they bring to the project.

What the stack enables

The whole stack is designed to optimise for two things: developer happiness and operational simplicity. Every tool on the list was picked because it makes one of those better without making the other worse.

That means no Kubernetes, no microservices, no over-engineered CI pipelines. We have shipped serious applications on this stack without any of those. The complexity tax of large-scale infrastructure is not worth it until you actually need it.

When you do need to scale up, the tools above can grow with you. Render can be replaced with Kubernetes. PostgreSQL can be replaced with a sharded cluster. Linear can be replaced with Jira. But until the day you need to, the simple stack is the right stack.

The cost of the stack

Real numbers from a typical project:

  • Render or Fly.io: $7-$25 per month for a small app.
  • Neon PostgreSQL: free tier covers most projects; $20/month for production.
  • Sentry: free tier covers hobby projects; $26/month for production.
  • Linear: free for up to 10 users; $8/month per user for paid tiers.
  • Figma: free for up to 3 editors; $15/month per editor for teams.
  • GitHub: free for public repos; $4/month per user for private teams.
  • Cloudflare: free tier covers most projects.

The total: roughly $50-$200 per month for a small team shipping a real application. Reasonable for the productivity gain, and dramatically cheaper than running your own infrastructure.

FAQ

What about React?

React is fine. We use it on some client projects. For our default stack, Vue wins on onboarding speed and template readability. See our framework article.

What about Svelte?

We love Svelte and would seriously consider it for greenfield work. The ecosystem is smaller, which is the only reason we do not use it as our default.

What about serverless?

For some projects, yes. AWS Lambda for image processing, Cloudflare Workers for edge logic. For most apps, a traditional ASP.NET Core deployment on Render or Fly.io is simpler and more predictable.

What about testing?

Vitest for unit tests, Playwright for end-to-end tests. We aim for test coverage on the business logic, not on every line. The tests are a safety net, not a religion.

What about deployment?

Docker images, deployed to Render or Fly.io. Database hosted on a managed provider (Neon, Supabase, MongoDB Atlas). Monitoring with Better Stack or Highlight. None of this is exotic; it is just what works.

Next step

If you are picking tools for your own studio or project, the most important advice is this: do not over-optimise. Pick tools you know, ship things, and switch only when something actually hurts. The cost of switching tools is real; the cost of using a slightly suboptimal tool is usually negligible.