Side projects rarely die because the idea was bad. They die in the gap between "it works on my machine" and "it survives real users" — the database migration nobody ran, the backup nobody took, the misconfiguration nobody noticed until launch day.
Yatta JS is a backend-as-a-server for Bun: database, auth, mail, storage, realtime, jobs, and observability embedded in your application process instead of provisioned as separate services. It is live as yatta.js@1.0.0 on npm — install it with npm i yatta.js — and the docs are at https://yatta.js.org. What I want to talk about today is not the architecture, though. It is the three boring commands that sit between a demo and a shipped thing.
- Doctor first: check the patient before the launch
Every framework has a setup guide. Few of them will look at your actual project and tell you what is off. Yatta's doctor command does that job: it checks your project setup and flags problems before they become launch-day surprises.
My rule now is simple: doctor runs before every deploy, not after something breaks. It is the cheapest form of confidence a solo builder can buy, and it costs nothing because the check is local to your own project. If you take one habit from this post, take this one — verify the setup, don't assume it.
- Migrations as a normal part of the workflow, not a scary event
A side project that never changes its data model is a side project that never ships a second feature. Yatta's CLI treats migrations as ordinary work: make a migration, check migration status, run the migration. That rhythm matters more than any single command, because it turns schema changes from a dreaded manual step into a repeatable one you do without thinking twice.
The practical payoff is unglamorous and real: your local database, your staging data, and your production data move forward in the same steps, in the same order. When you are the only person on the project, that repeatability is your whole ops team.
- Backup before you need it, not after you lose something
Yatta's CLI includes database backup and restore commands, and the honest truth is that most solo projects never test a restore until the day they need one. Build the habit the other way round: take a backup before a risky migration, and know that restore is a command you have already practised, not a README you are reading in a panic.
That is the whole pre-ship checklist, and it fits in a short paragraph: run doctor, keep migrations routine, back up before risky changes. None of it is exciting. All of it is what keeps a one-person project alive past week two.
None of this replaces good judgement — a backup you never tested is a hope, not a plan, and a migration you never reviewed is still your responsibility. But having doctor, migrate, and backup as first-class commands in the same runtime that already holds your database, realtime, and jobs means the unglamorous work stops being a separate project. It is just part of shipping.
If you are building on Bun and you are tired of assembling a backend from six services before you write a single feature, Yatta JS is worth a look: https://yatta.js.org — npm: https://www.npmjs.com/package/yatta.js — code: https://github.com/psrockstar098/yatta.js
What is the one pre-launch check you always skip and always regret? I would genuinely like to steal better habits from the comments.
Top comments (1)
Since storage and jobs sit alongside the database, I'd make the restore exercise cross those boundaries: create an uploaded file with a database reference, queue a job, take the backup, then restore into an isolated instance. Is the file still readable, and does a job that completed after the snapshot get repeated? That would establish what the backup actually covers and which external effects need reconciliation. A successful database restore alone can't answer those two questions.