What is our tech stack

Reading time3min


Bu Kinoshita
Vitor Capretz


We use TypeScript and Node.js across our back-end applications. They are divided into serverless functions using Next.js API Routes and long running Express servers.

Our applications generally try to follow a single concern, for example, our public API is served from an Express server, our SMTP from another one, but we have a few others used internally for operations or background jobs.


We use React with Next.js for our dashboard and public website.

For styling we build custom components using Tailwind CSS, Radix Primitives, and Radix Colors.

We currently use SWR and API routes to make requests to the back-end to fetch the necessary information, as well as Zod to parse responses into strongly-typed schemas.


We have workloads spread across different providers, such as Vercel, Railway, and Fly.

Depending on the problem we're trying to solve, we choose the best provider for the job. For example, we use Vercel for our Next.js apps, which allows us to ship features quickly using Preview Deployments.


We use Postgres as our main storage system, the applications consume data using Drizzle as the ORM/query-builder.

We also have Redis, used for caching some data for fast access.


We use a combination of tools to monitor our applications:

Background jobs

We have many background jobs that are triggered from different flows; the goal is to make requests faster by moving non-critical code out of the main path or to perform an action continuously based on some criteria.

Our main tool is Inngest, which provides a great developer experience and helps us visualize and debug background jobs.


Our documentation is written using Markdown and it's powered by Mintifly, which let us focus more in writing the best content we can.


We use Svix for processing webhooks to our users. It's a great tool that helps us monitor and scale webhooks with automatic retries.


We use Vitest as our testing framework for unit testing. We don't enforce a specific test coverage, and we try to be reasonable in balancing the amount of tests we write.

We don't have UI tests or E2E tests in our dashboard, but we know we need them sooner rather than later.

Code styling

Recently, we switched from ESLint and Prettier to Biome and noticed huge performance improvements. We have been happy about it, even though some features from our previous setup are missing.


  • pnpm as a package manager
  • TypeScript is the default. We try to be very strict about its rules
  • Pino is our logger library across the board
  • MDX is how we write content