Server side
Bun and Node.js backends
The part nobody sees, which is exactly why it has to be right.
Behind most useful websites is a server doing real work: checking stock, sending a confirmation, writing a booking to a database, talking to a payment gateway. When that layer is sloppy, the symptoms show up as a slow page or a lost order, and nobody can tell you why.
We build these services on Bun and Node.js. Bun starts faster and runs many workloads quicker, which is why we use it for new services and for the tooling around every project. Node.js is the safe default where a library or a hosting environment expects it, and it is still what most of the ecosystem is tested against.
Both run JavaScript and TypeScript, so the same language and the same types run on the server and in the browser. One team, one vocabulary, fewer translation mistakes at the boundary.
What the work covers
Included in every bun & node.js backends project.
Typed API endpoints
Request and response shapes defined once and shared with the front end, so a rename cannot silently break a screen.
Database design
Schema, indexes and migrations planned before the first query. PostgreSQL for most work, MySQL and MongoDB where the project already lives there.
Authentication and roles
Sessions, tokens, password resets and permission levels built with current practice, not a snippet copied from a forum.
Background jobs and schedules
Reports, reminders, imports and cleanups that run on a timer, with a record of every run and what it did.
Third party gateways
Payments, SMS, email and messaging connected server side, with the keys kept out of the browser where they belong.
Logging and error reporting
When something fails at two in the morning, the log says which request, which user and which line. Silent failures are the expensive kind.
No themes, no page builders, no plugin stacks
Every site written from scratch, starting from almost nothing and adding only what the pages need. The whole speed recipe is published, not kept secret.
Read the recipe →AI, used properlyWe use AI to go faster, not to decide
It writes the mechanical parts. It never chooses the architecture, the performance budget, or a single fact about your business. Everything is reviewed by the person who will maintain it.
Where we draw the line →Questions
Asked often enough to answer here.
If yours is not here, the general questions page covers how we work, or you can just ask.
Why use Bun instead of Node.js?
Bun installs packages and starts processes noticeably faster, which shortens every build and every local run. For a new service with no unusual native dependencies we default to it. When a project depends on a package that only supports Node.js, we use Node.js and lose nothing.
Can you work with an API we already have?
Yes, and often that is the sensible route. We read what exists, document the parts that are unclear, and build against it. Rewriting a working backend is rarely money well spent.
How do you keep API keys safe?
Secrets stay in server environment variables and never reach the browser. Anything the front end needs from a paid service goes through our own route, which validates the request before passing it on. A key in a page source is a key that is already public.
Related work we do
All 16 servicesCustom web development
Websites written from scratch for one business, rather than a theme bent into shape until it almost fits.
Next.js development
The framework we reach for first, and the one we know well enough to know when it is the wrong answer.
Website speed and Core Web Vitals
Speed is not a finishing touch we apply at the end. It is a decision made at every step, and it is the one we care about most.
Want this for your business?
Tell us what you have now and what is not working. We will tell you what we would do and what it would cost.