DEV Community: The Saint

I built Clipsift — 47 private, in-browser media tools with zero cloud uploads

The Saint — Sun, 08 Nov 2026 18:49:44 +0000

Hey everyone! I got tired of file converter sites that cap file sizes, make you wait in queues, and upload personal photos/audio to unknown servers.

So I built Clipsift
: an open catalog of 47 audio, PDF, and image tools running 100% client-side in your browser using Canvas, WebAssembly, and modern web APIs. No server storage, no data collection.

Just added vector SVG to high-res PNG conversion and PDF storyboard synthesis. Would love your feedback on performance and what tools you'd like added next!

From one command to a live app on a $5 VPS

The Saint — Mon, 02 Nov 2026 11:24:36 +0000

You own the server, the code and the data. Here is what the first ten minutes look like.

Why the default path gets annoying

You rent a backend and it works. The annoyance shows up later: on app number two, when you see what a second project costs, and on the day you want to leave and find out what you can take with you.

The database is yours in theory. In practice the export is a job you write yourself, the users sit in someone else's auth format, and the files live in a bucket you do not control.

That is a trade, not a scandal, and it is worth seeing what the other side of it looks like. This post walks through one: a backend you create on your own machine, deploy to a server you rent, and can leave with one command. I build CrescoDB, so that is the tool in the examples, and I will say where it stops.

Create the project

You need Node 20 or newer.

node --version

Create the project:

npm create crescodb@latest my-app

This writes the project into my-app, installs the CLI inside it, starts it and opens the dashboard. The dashboard asks you to sign in to a CrescoDB account. The account is free and needs no card.

Now add auth. Move into the folder and run the generator:

cd my-app
npx cresco create auth

That command writes the auth code into your project as plain files: register.js, login.js, middleware.js and jwt.js, wired to the project database. Passwords are hashed with scrypt and sessions use JWT. Next to them sit schema.cresco, which describes your tables, and cresco.db, the SQLite file.

It is a normal Node project. Open it in an editor and read the login route. Nothing in it is hidden behind a package you cannot open.

Run it

npm run dev

The API starts on port 3000 and the dashboard is at http://localhost:3000/studio. The database is SQLite, so there is nothing to install and no Docker.

For the store starter, the project's own page shows this output:

✓ schema.cresco · cresco.db · store starter
✓ shop is ready.
REST API on :3000
Dashboard opened, connected to shop

Your app is served too. cresco dev serves your project folder at http://localhost:3000/app and reloads the page when you save, so the frontend sits next to its API.

The schema

Everything comes from one file. A model looks like this:

{
  "name": "Order",
  "fields": [
    { "name": "id", "type": "uuid", "primaryKey": true },
    { "name": "total", "type": "number", "required": true }
  ],
  "access": { "read": ["authenticated"] }
}

From that, every model gets create, read, update and delete over REST, with paging and filtering:

GET /orders
POST /orders
PATCH /orders/:id
DELETE /orders/:id

The same schema drives the rest. Auth has four roles: guest, user, mod and admin. A model can declare a rowOwner column so users only see and change their own rows. Files go through bucket storage at /storage, and row changes stream to connected clients over server-sent events.

Tables are private by default. A model with no access block needs a signed-in user to read it. Public has to be something you type on purpose.

The engine underneath is SQLite by default. Point the project at PostgreSQL or MySQL and schema.cresco and the API stay the same, so there is no rewrite between SQLite on your laptop and Postgres on the server. One caution: the first switch off SQLite carries your schema over, but moving data between engines later is an export and an import.

Before anything ships, run the audit:

npx cresco audit

It reads the schema in your repo and answers one question: who can read each table. A public table holding an email column is critical. A public price list is a note. It exits non-zero on a critical finding, so it also works in CI.

Deploy

You need a server. Any Ubuntu or Debian VPS works. Hetzner, DigitalOcean and Vultr all rent a small one for about $5 a month.

In the dashboard, go to Servers & Apps and connect a server. Give it a name like web-1. The dashboard shows one command with your token and key filled in. Paste it into the server:

curl -fsSL .../connect.sh | sudo bash -s -- --token ... --url ... --pubkey '...'

It installs Docker if the box has none, and creates a separate cresco user with no sudo access. It never asks for your root password. The token works once and stops working when the server checks in.

Then, from your project folder:

npx cresco login
npx cresco deploy --server web-1

cresco deploy runs the access audit first and refuses to continue on a critical finding. If it passes, the project is sent to the server, built there, started and health-checked. The app gets a free address under crescoafrica.com with HTTPS. For your own domain, the dashboard shows the DNS record to add and checks it for you. If the record sits behind Cloudflare, turn the orange cloud off so it is set to "DNS only", or certificate issuing fails. HTTPS comes from Caddy and Let's Encrypt, and it renews on its own.

Rollback is built in. The previous version stays on the server. If a new build fails, the old one keeps serving. If it builds but fails its health check, you are told why, and Roll back in the dashboard puts the previous build back.

What you still own after deploying

Run this in the project folder:

npx cresco eject

It writes a folder that runs your project without CrescoDB:

myapp-ejected/
  schema.cresco
  data.sql
  vendor/        the engine, packaged into the folder
  Dockerfile
  docker-compose.yml
  README.md

data.sql holds every table and every row as plain SQL, and psql, mysql and sqlite3 all load it. To run it:

cd myapp-ejected
docker compose up --build

Two limits are worth stating. The bundle is not air-gapped: Docker still pulls a Node base image and npm still fetches ordinary packages, like any Docker build. And two things need changing before you put it anywhere real: the database password in docker-compose.yml is a placeholder, and CRESCO_AUTH_SECRET must be set if the project uses auth. If the data export fails, eject writes nothing and tells you why, so you never end up holding a bundle with an empty data.sql.

What this is not

The server is yours, so you are the operator. You pick it, you pay for it, and its disk, its updates and its uptime are your responsibility. CrescoDB reads CPU, memory and disk from the box and alerts you, but it does not turn a rented VPS into a managed service.

It also does not mean none of your data touches CrescoDB. Project state and backups sit on CrescoDB infrastructure. Your live app and its database run on your server. What leaves it is the backup: each automatic snapshot is encrypted on your server with AES-256 before upload, then stored in Cloudflare R2, with the key held encrypted on our side. A restore check loads the latest backup into a scratch database on your server and counts what came out before the copy is marked verified. Automatic backups and restore checks are part of the paid plans. The free plan has none, and you can run a restore by hand.

If you stop using the service, the app keeps running and your database and code stay with you. You lose the backups and the alerting.

One thing you can do in the browser

If you only want to check one thing before installing anything, run the free access audit on the CrescoDB site. It needs no account. It reads your table rules and tells you which tables anyone can read. I put the link in the first comment.

If you try any of this, I would like to hear where it broke, because that is the part I cannot see from my own machine.

Seven things I check before running Postgres on a server I own

The Saint — Thu, 29 Oct 2026 09:22:20 +0000

Self-hosting Postgres is not hard. Skipping one of these seven is.

I build CrescoDB, a backend you deploy to a server you already rent, so I spend a lot of time thinking about what goes wrong on self-hosted setups. The failures are almost never clever. They are the same seven things, skipped once.

1. Something that restarts it at boot

Postgres will run for weeks and then not come back after a reboot, because the service was never enabled. Enable the database and the app, then reboot the box and watch them return.

sudo systemctl enable postgresql
sudo systemctl enable your-app
sudo reboot

If you have not rebooted, you do not know. A service that is running right now has told you nothing about whether it starts on its own.

This is the habit I am trying to build into CrescoDB: a deploy is not finished when the app answers once, it is finished when the whole stack has shown it comes back after a restart.

2. A connection pool, before you think you need one

Postgres starts a process for every connection. Give each app instance its own pool and the total multiplies faster than you expect, usually just after a traffic bump or a second instance.

PgBouncer in transaction mode, placed in front of the database, keeps the real connection count small. One caveat: transaction mode does not play well with session-level features such as advisory locks or some prepared statement setups, so check your driver before you switch.

Watch connections, not CPU. Running out of connections looks like a mystery outage while the CPU graph stays calm.

3. A restore, not a backup

A dump file is a hypothesis. The only proof is restoring it into a scratch database and counting rows against the source, on a schedule.

createdb scratch_check
pg_restore --no-owner -d scratch_check /backups/latest.dump
psql -d scratch_check -c "SELECT count(*) FROM your_main_table;"

If that restore has never run, you do not have a backup. You have a file. I wrote about this in more detail in A backup you've never restored is just a rumour.

4. Certificates that renew themselves, and a database that is not public

Two separate checks that fail in the same quiet way.

For certificates, use something that renews on its own, such as certbot with a timer or a proxy like Caddy that handles it, and check that the renewal actually ran, not just that it was set up.

For the database, bind it to localhost or a private address:

listen_addresses = 'localhost'

Port 5432 open to the internet gets found. It is not a question of if.

5. Migrations in one direction

Forward only, applied as part of the deploy, recorded somewhere you can read. The day someone edits a table by hand in production, your migrations stop describing your database, and every later deploy is a guess.

If a change turns out wrong, write a new migration that fixes it. Do not reach into the live schema.

6. Alerts on the boring numbers

Disk, connections, failed backups, and whether the app answers. That is the short list.

CPU graphs feel productive and tell you very little. Disk is the one that takes you down without warning, because it fills slowly and then everything stops at once.

7. Log rotation

A chatty app fills the disk with logs, and then Postgres stops accepting writes. Set up logrotate, or cap the journal, before you need it:

sudo journalctl --vacuum-size=500M

For a permanent cap, set SystemMaxUse in the journald config.

The short version

None of this is complicated. All of it is easy to skip on a Friday afternoon, and each one costs a weekend you do not get back.

If you only do one thing today, restore your last backup into a scratch database and count the rows. That is the one everyone skips.

If you want to see how I am approaching this for deploys to your own server, CrescoDB is at crescodb.com.

A backup you've never restored is just a rumour

The Saint — Tue, 27 Oct 2026 21:12:01 +0000

I have 24 users and zero of them have deployed. If one of them deploys tomorrow and their server dies on Thursday, the only thing standing between them and a lost week is a backup I have never opened.

That sentence bothered me enough to change how I think about backups. Here is where I landed.

Everyone has a backup job. Almost nobody has a restore.

Ask a room of developers whether their database is backed up and most hands go up. Ask how many have restored one of those backups, start to finish, and the hands mostly come down.

A backup job that exits with code 0 tells you a file was written. It does not tell you the file is complete, that it matches the schema you are running today, or that it will load on a fresh machine at 2am. Until you have restored it, you are trusting a file you have never opened. That is a rumour with a timestamp.

What a real test looks like

A real test is short to describe:

Restore the backup into a scratch database that nothing else uses.
Query it.

The second step is the one people skip. A restore that finishes without errors can still hand you a database with missing rows, an empty table, or a sequence that restarted at 1. A backup that restores quietly with missing data is worse than no backup, because you will believe it.

So the check is not "did the restore command succeed". It is "do the numbers look like production". Row counts on your main tables, the newest timestamp in a table that gets written constantly, and one real query your app depends on. If those come back right, you have evidence. If you only checked the exit code, you have a hope.

The loop I run

This is the loop CrescoDB uses for apps deployed to a user's own server:

A nightly dump is taken on the server.
That dump is restored into a scratch database on the same server and checked.
The dump is copied off the box to R2.
It is pulled back down from R2 and restored again somewhere else.

To be clear about where the data lives: backups sit in R2 as well as on the user's server. Your data is on your own machine, and a copy of the backup also lives in object storage. I would rather say that plainly than let anyone assume the backup never leaves the box.

The second restore is the point of step four. Restoring on the same server proves the dump is readable. Restoring a copy that came back from storage, on a different machine, proves the copy survived the trip and that you can recover when the original server is gone, which is the case that actually matters.

Automatic backups and scheduled restore checks are part of the paid plans, not the free tier.

What only shows up on restore

Backups tend to fail in quiet, boring ways. These are the ones worth checking for, and what to do about each:

Missing roles or ownership. A dump may reference database roles that do not exist on the new machine, so objects fail to restore or end up owned by the wrong user. Create the roles first, or dump with ownership handled deliberately.
Extensions. If your schema needs an extension and the new server does not have it installed, parts of the restore fail. Keep a list of required extensions next to the backup job.
Version mismatch. Restoring a dump from a newer major version into an older server often does not work. Keep the restore target on the same major version, or newer.
Truncated files. A dump cut short by a full disk or a killed process can look like a normal file. Check the size against previous nights and let the restore fail loudly if the file is incomplete.
Sequences and counters. Row data can come back while sequences reset, which breaks the next insert. Test an insert after restoring, not just a select.
Permissions on the backup itself. A backup readable by the wrong users is its own problem. Check who can read the file, and treat it like production data, because it is.

None of this is exotic. It simply never gets discovered until someone restores, which is the whole argument for restoring on a schedule instead of during an outage.

Test your own tonight

Three commands, using Postgres as the example. Swap in your own names and paths.

Take a dump:

pg_dump -Fc -f /tmp/backup.dump your_database

Restore it into a scratch database:

createdb scratch_check && pg_restore --no-owner -d scratch_check /tmp/backup.dump

Compare it against production:

psql -d scratch_check -c "SELECT count(*) FROM your_main_table;"

Run the same count against your live database. If the numbers match and a recent row is present, you now know something you did not know this morning. Drop the scratch database when you are done:

dropdb scratch_check

Put those four lines in a script, run it from cron, and make it complain when the counts disagree. That is most of the work.

The short version

A backup is only a backup after it has been restored and queried. Do it into a scratch database, check real numbers, and do it again from a copy that came back from somewhere else. If you want to see how this fits into deploying a backend to your own server, CrescoDB is at crescodb.com, and the free audit page is at crescodb.com/audit.

And if you have a backup job running right now, go restore last night's. I would like to hear what you find.

Beyond Deployment: What's Next for CrescoDB, Plus a Clearer Path to Getting Started

The Saint — Tue, 20 Oct 2026 11:04:20 +0000

Beyond Deployment: What's Next for CrescoDB, Plus a Clearer Path to Getting Started
Building a backend is only part of the work.
You define your data, build your API, connect your application, test it, and eventually deploy it. Your application is live. Your users can access it. Everything appears to be working.
Then something breaks.
A route begins returning server errors. A query becomes unexpectedly slow. Your server starts running out of disk space. Your application stops responding, and you don't notice until someone reports it.
The problem isn't necessarily that something broke. Software breaks. The problem is finding out what happened, identifying where it happened, and getting enough information to fix it.
That's the next part of the developer experience we're working on at CrescoDB.
Our upcoming update focuses on production monitoring and the operational visibility developers need after deployment. We're also working to make CrescoDB's own getting-started experience clearer, because we've made that journey more confusing than it should be.
Here's what's changing, why it matters, and how to get a project running in the meantime.

The next stage: understanding what happens after deployment We've been building CrescoDB around the backend workflow: creating your data models, generating an API, adding authentication, verifying access rules, and deploying to infrastructure you control. But a backend doesn't stop being your responsibility when it goes live. Once an application is in production, you need answers to questions like:
Which endpoint is returning errors?
Are requests getting slower?
Which database queries are taking the longest?
Is the server running low on memory or disk space?
Is the application actually reachable by users?
If something fails, will you know before a user has to tell you? Without monitoring, answering those questions can involve manually checking logs, connecting to servers, running commands, and trying to reconstruct what happened after the fact. We're working to make that process less painful. Application monitoring The monitoring capabilities we're preparing are designed to give developers visibility into their application's behavior, rather than simply reporting whether the application process is running. That includes information about:
Requests and errors grouped by route.
Server and client error rates.
Request latency, including p95 latency.
Slow database queries and query failures.
Application errors with useful debugging information.
Runtime indicators such as memory usage and event-loop delay. For example, imagine that a store's checkout endpoint starts returning server errors while the rest of the application continues working. A generic alert saying "your application has an error" leaves you with more questions. Knowing that POST /checkout is failing, seeing how many requests were affected, and having information to investigate the failure gives you a much more useful starting point. The goal is not to replace debugging. It's to help you find the right place to begin. Server monitoring Application health and server health are related, but they're not the same thing. An application can encounter problems because of its own code. It can also encounter problems because the machine running it is under pressure. We're expanding the visibility developers have into the infrastructure supporting their applications, including:
CPU usage and system load.
Available memory and swap.
Disk usage and partitions.
Running containers and their resource usage.
Server availability.
Operational problems that may require attention. Consider a server whose disk is nearly full. That can interfere with deployments, backups, and database operations. Finding out only when a deployment fails is much later than finding out while there's still time to act. The idea is to make those conditions visible before they turn into a larger incident. Uptime checks from outside the server Monitoring an application from inside its own process is useful, but it cannot tell you everything a visitor experiences. A server might be running while its public domain is misconfigured. A certificate might have a problem. A CDN might be returning an error. A URL might be reachable but taking too long to respond. That's why external uptime checks matter. CrescoDB's monitoring direction also includes checking public URLs from outside the server, helping identify problems involving reachability, DNS, TLS, response times, and the page being served. The objective is to see the application from more than one perspective: from inside the app, from the server underneath it, and from the outside where users encounter it. Alerts that tell you when something needs attention Monitoring is less useful if you have to keep a dashboard open all day to benefit from it. Alerts are intended to bring important problems to your attention so you can investigate them. CrescoDB's documented monitoring capabilities include email alerts, with Slack and Telegram available on paid plans. The intention is to help developers respond to meaningful failures without having to watch every metric manually. We're working toward a better operational workflow: detect a problem, understand where it is happening, investigate it, and work toward a resolution. The important distinction is that we're not trying to give developers more numbers to stare at. We're trying to make production problems easier to understand and act on. You can read more about the direction in the current CrescoDB product overview and production monitoring documentation.
Deployment is part of the workflow, not the end of it We've also been thinking about the steps between a working local project and a working production application. Developers have different workflows. Some prefer Git-based deployment. Others want to deploy an existing project without setting up a repository workflow first. We're working on reducing friction in that process, including ZIP-based deployment and better ways to manage disk allocation when multiple applications share a server. The goal is to make deployment more accessible without hiding the important decisions from developers. CrescoDB is built around the idea that you should be able to run your application on infrastructure you control. Your code and data shouldn't become inaccessible simply because you decide to change platforms. That means deployment should be understandable, operational problems should be easier to diagnose, and leaving the platform should remain a practical option. We're not going to pretend that every part of this workflow is finished. We're continuing to improve it.
We also owe you an apology Before talking about more features, we need to acknowledge something about the current product experience. Our homepage and onboarding instructions have been confusing, and we're sorry. We've tried to communicate a lot about CrescoDB: local development, the database and API, authentication, the dashboard, AI assistance, deployment, and the operational tools around production. Those capabilities matter. But presenting them without making the starting point obvious can leave a new developer wondering what to do first. Some of the important distinctions haven't been clear enough:
What you need to install.
How to create and run a local project.
Which features work locally.
When you need an account.
What changes when you want to deploy.
How to connect your project to a server you control. We should have made those steps easier to follow. A developer who wants to try CrescoDB shouldn't have to study the entire product before getting a working API. They shouldn't have to confuse local development with cloud deployment, either. That's a communication and onboarding problem, and it's our responsibility to address it. We're working to make the homepage more focused and the getting-started journey more direct. In the meantime, here's a practical guide you can follow.
How to get a CrescoDB project running You do not need to deploy to a server to begin using CrescoDB. For local development, the prerequisites are straightforward: install Node.js 20 or newer, then install CrescoDB. Step 1: Install Node.js CrescoDB requires Node.js 20 or newer. Node.js 22 LTS is the recommended starting point. Check your installed version: node --version

If you need to install Node.js, use the official installer or a version manager.
Step 2: Install CrescoDB
Install the CLI globally:
npm install -g crescodb

You can also use npx crescodb if you prefer not to install it globally.
Step 3: Create a project
Create a new folder for your project, move into it, and initialize CrescoDB:
mkdir my-project
cd my-project
cresco init

This creates the basic project files, including the schema, configuration, and local SQLite database.
Important: A new project starts empty. That is intentional. You define your own tables and data models rather than being given a pre-populated application.
If you would rather start with demo tables, initialize a starter project instead:
cresco init --starter

Use one initialization option or the other for a new project.
Step 4: Start the development server
From your project directory, run:
cresco dev

CrescoDB starts the local REST API and development dashboard.
Step 5: Open the dashboard
Visit:
http://localhost:3000/studio
From the dashboard, you can browse and edit data, design your schema, run SQL, inspect your models, and explore the project as you build it.
You now have a local project to work with.
You do not need a rented VPS, a cloud account, or Docker simply to reach this stage.
Step 6: Add your data models
Your project starts empty unless you chose the starter option.
You can define tables through the schema file, use the dashboard's schema editor, or describe the data you want to create through the supported AI workflow.
For example, a simple blog might need models for posts and comments. A store might need products and orders.
Once your schema is in place, CrescoDB can generate the corresponding API.
You can then use those endpoints from your frontend or another application over HTTP.
Step 7: Add authentication and verify access rules
When your application needs authentication, you can generate the authentication code:
cresco create auth

CrescoDB writes editable code into your project rather than requiring you to treat authentication as an opaque black box.
Before deployment, you can also run:
cresco audit

This checks access rules against your schema and identifies critical exposure issues. CrescoDB's deployment workflow also runs the audit before preparing a deployment, refusing to proceed when it finds a critical issue unless you explicitly override it.
Step 8: Deploy when you're ready
Local development and production deployment are separate stages.
Once your application is working locally, you can move on to deployment. CrescoDB supports deploying to a server you control, with a workflow for connecting the server, deploying the project, and configuring a domain.
You don't have to do this before you can start building.
For the deployment steps, use the official guide to deploying to your own server rather than trying to infer the process from the homepage.
The full local quickstart is available in the CrescoDB getting-started guide.

What we're trying to build with CrescoDB We don't want CrescoDB to be just another way to generate an API. We want the workflow to make sense from the first local project through production:
Build: Define your data and get a working backend.
Verify: Check access rules before deploying.
Deploy: Run your application on infrastructure you control.
Monitor: Understand application errors and server health.
Operate: Manage the ongoing work of keeping an application healthy.
Own: Retain control over your code and data. These parts are connected. A project that runs locally but is difficult to deploy has an incomplete workflow. An application that deploys successfully but provides no useful operational visibility creates a different problem. And a platform that makes it difficult to leave isn't giving developers full control. We're working on these parts together because they affect the experience of building and maintaining real software.
What's next? Tomorrow, we're sharing the next CrescoDB update, with a focus on production monitoring and the visibility developers need after deployment. We're also continuing to improve deployment workflows and address the confusion around getting started. We'll keep sharing what we're building, explaining what has changed, and listening to the developers using the product. We know that shipping features isn't the only measure of progress. The product needs to be understandable, the documentation needs to be useful, and the path from trying CrescoDB to building something real needs to be clear. We've got work to do on that, and we're taking it seriously. Thank you to everyone who has tested CrescoDB, shared feedback, reported problems, or followed the project while it's evolving. We're building this in public, including the parts we need to get better at. Stay tuned for tomorrow's update. Explore CrescoDB: CrescoDB official website Get started: CrescoDB quickstart

The Hardest Part of Building a Developer Tool Isn't Writing Code

The Saint — Sun, 11 Oct 2026 08:59:21 +0000

Building software is addictive.
You think of a feature, open your editor, write some code, and eventually watch the idea become something real.
That feeling is difficult to beat.
But when you're building a product rather than working on an isolated project, there's a problem: you can spend months building things without getting any closer to building a product people actually need.
I've been thinking about this while working on developer tools.
The challenge isn't always figuring out how to implement something. Sometimes, it's deciding whether it should exist in the first place.
The feature trap
Imagine you're building a tool for developers.
You start with a clear problem to solve. Then you notice another problem you could address.
You add a feature.
While implementing it, you discover something else that would make the experience better. You add that, too.
Before long, your roadmap contains authentication, analytics, integrations, monitoring, deployment, automation, and several other ideas.
Individually, each feature makes sense.
Together, they can make the product harder to understand, harder to maintain, and harder to launch.
The dangerous part is that you're still making progress.
Your codebase is growing. Your feature list is getting longer. Your product looks more impressive.
But none of those things necessarily means you've found product-market fit.
You might simply be getting better at building things that people haven't asked for.
More features don't automatically create more value
A feature has at least two costs.
The first is the cost of building it.
The second is the cost of keeping it working.
Every new capability can introduce additional edge cases, bugs, documentation requirements, support requests, and maintenance work.
Integrations need to be maintained. APIs change. Dependencies become outdated. User expectations grow.
A feature that takes two days to implement might create months of maintenance.
This doesn't mean we should avoid ambitious products. It means we should understand the difference between the cost of creating a feature and the cost of owning it.
For a small team, that distinction matters enormously.
Start with the problem, not the feature
When evaluating a new feature, I think these questions are more useful than asking whether it would be cool to build.

Who specifically has this problem? If the answer is everyone, the answer probably isn't specific enough. Identify the people who experience the problem and understand how they currently deal with it.
How painful is the problem? A minor inconvenience might not justify a new product feature. A problem that repeatedly wastes hours, causes failures, or forces people to pay for several disconnected tools might be worth investigating.
What do people do today? Look at existing workflows, competitors, spreadsheets, scripts, workarounds, and manual processes. The way people solve a problem today can reveal more than a list of features they say they want.
Can we test the idea before fully building it? Sometimes a prototype, landing page, manual service, or small experiment can tell you whether the idea deserves more investment. You don't always need to build the entire system to test the underlying assumption.
What will we stop doing to make room for it? This is the question I think early-stage builders should ask more often. Time is limited. If a new feature takes two weeks, those are two weeks you cannot spend improving onboarding, fixing an existing problem, talking to users, or finding customers. A roadmap should reflect those trade-offs. Distribution is part of building the product There's another trap developers can fall into: believing that a better product will automatically attract users. It won't. People need to discover your product, understand what it does, see why it matters, and decide that trying it is worth their time. That means distribution cannot always wait until development is finished. You can have excellent engineering and still struggle to get users if nobody knows your product exists. For an early-stage startup, speaking to potential users, publishing useful content, participating in developer communities, and testing acquisition channels are not distractions from building. They are part of discovering what is worth building. What I'd do differently with a new product If I were starting another developer tool from scratch, I'd keep the initial plan deliberately narrow. I'd identify one specific audience and one painful problem. Then I'd build the smallest version that could solve that problem for a real user. I'd put it in front of people early, observe what they actually do, and use that information to decide what comes next. I'd keep a separate list of interesting ideas so I wouldn't confuse an idea worth remembering with a feature worth implementing immediately. Most importantly, I'd measure progress by what users can accomplish, not simply by how much code I've written. The goal isn't to build the smallest product possible forever. It's to earn the right to build a bigger product by proving that the smaller one is useful. Final thought Building software rewards people who can execute. Building a sustainable product also requires knowing when not to execute. There will always be another feature to add, another integration to support, and another idea that seems too good to ignore. But an early-stage team doesn't have unlimited time or resources. Sometimes, the most valuable thing you can do for your product is leave a good idea unbuilt. I'm curious about other builders' experiences: What's one feature you were convinced you needed, but later realised you could have shipped without? I'd like to hear the reasoning behind it.

Your Application Is Not Your Server: Why Production Monitoring Needs Both

The Saint — Fri, 09 Oct 2026 19:20:30 +0000

Building an application and keeping it healthy in production are two different engineering problems.

You can have an application that starts successfully, responds to requests, and looks perfectly fine during a quick manual test. Then, under real usage, requests become slow, errors appear, or the application stops responding entirely.

When that happens, where do you look?

The application? The server? The network? The disk?

The answer depends on what failed. That's why production monitoring needs to look at both the application and the infrastructure underneath it.

Application health is only half the picture

Application monitoring focuses on what the software itself is doing.

Depending on the monitoring setup, useful signals include:

Runtime errors and crashes

Application availability

Downtime

Failed requests and unexpected behavior

These signals help answer questions such as:

Is the application still running?

Has the process crashed?

Is the service available to users?

Are runtime errors occurring?

But an application can experience problems because of something outside its own code.

For example, a database operation may start failing because the server is running out of disk space. Requests may become slow because CPU usage is consistently high. An otherwise healthy application may become unreachable because the underlying server is unavailable.

Looking only at application-level signals can make those problems harder to investigate.

The server has its own health indicators

The infrastructure running an application produces useful signals of its own.

CPU usage: Sustained high CPU utilization can indicate that a workload is overwhelming available compute capacity.

Disk space: A nearly full disk can affect logs, temporary files, databases and other write operations.

Network latency: Increasing latency can indicate a connectivity or performance problem somewhere along the relevant network path.

Server availability: If the underlying server becomes unavailable, applications hosted on it can become unreachable regardless of whether their code was healthy before the incident.

These metrics don't automatically identify the root cause of every incident. They do, however, give you more information to investigate the problem.

The important point is that application health and server health are related, but they aren't the same thing.

Why small teams need both

Large engineering organizations can build elaborate observability stacks with separate tools for metrics, logs, traces, alert routing and infrastructure monitoring.

Small teams and independent developers often have a different problem: too many tools to configure and too many places to check when something breaks.

The goal shouldn't be to collect every possible metric. It should be to collect enough useful signals to notice problems and begin investigating them.

A practical starting point is:

Know when the application becomes unavailable.

Detect important runtime failures.

Watch resource pressure on the underlying server.

Alert the people responsible when something needs attention.

Have a clear path to investigate the issue.

Alert delivery matters, too. A dashboard is useful when you're looking at it. An alert is useful when you're doing something else.

Email, Slack and Telegram provide different ways to route notifications into workflows developers already use.

Bringing application and server monitoring together

This is the problem we're addressing with Monitor, the sixth pillar of CrescoDB.

CrescoDB is expanding its lifecycle tooling across Build, Own, Verify, Deploy, Operate and Monitor.

With Monitor, we're bringing visibility into both the application and its underlying server. That includes application crashes, runtime errors and downtime, alongside server signals such as CPU usage, disk space, network latency and server availability.

When something goes wrong, alerts can be sent through email, Slack and Telegram.

The goal isn't to claim that one dashboard eliminates every production incident. It's to give developers a clearer view of what's happening across the layers they depend on.

Monitoring belongs in the deployment workflow

Deployment is not the end of the software lifecycle.

After deployment, an application needs to keep running, respond to users, use resources responsibly and remain available as conditions change.

That is why we think about the lifecycle as:

Build → Own → Verify → Deploy → Operate → Monitor

Each stage addresses a different concern, but they work together. Verification helps catch problems before release. Deployment gets the application running. Operations keep it running. Monitoring helps reveal when something needs attention.

We're building CrescoDB around that connected workflow because developers shouldn't have to treat production reliability as an afterthought.

A question for developers

When one of your applications starts failing, how quickly can you tell whether the problem is in the application or the infrastructure running it?

And what do you use to monitor both?

We're building CrescoDB to make that workflow simpler. You can explore it at https://crescodb.com.

Your App Being “Online” Doesn’t Mean It’s Healthy

The Saint — Tue, 06 Oct 2026 07:21:21 +0000

One of the easiest traps in production is assuming:

“The website is responding, so everything is fine.”

It isn't.

An application can technically be online while quietly falling apart underneath.

Your API might still respond while CPU usage sits at 95%.

Your server might still accept traffic while disk space has 300 MB left.

Your database might be reachable while requests are taking five seconds instead of 200 milliseconds.

Your process might still be running while one important background worker died twenty minutes ago.

And sometimes the first person to tell you something is wrong is a user.

That's usually too late.

Uptime is only one signal

The simplest form of monitoring asks one question:

Is the application reachable?

You send a request every few seconds or minutes.

If it returns successfully:

everything looks green.

If it stops responding:

send an alert.

That is useful.

But it only detects one class of failure.

Production systems often degrade long before they completely disappear.

Imagine this:

Technically, the server is alive.

Operationally, you should probably be worried.

Monitoring the application

Application monitoring looks at what is happening inside the software.

Things like:

application crashes
unhandled exceptions
failed requests
response time
API errors
runtime failures
unhealthy processes
failed jobs

Consider an API that normally responds in:

and gradually moves to:

Nothing has technically crashed.

But something has changed.

Maybe a database query became slower.

Maybe traffic increased.

Maybe a dependency is struggling.

Maybe memory pressure is causing garbage collection problems.

Monitoring gives you a chance to investigate before the application becomes unavailable.

Then there is the machine underneath it

This is the part I think developers sometimes forget.

Your application isn't floating in the cloud.

Eventually, it is running on a machine somewhere.

That machine has:

And any one of those can become the actual reason your application fails.

For example, your Node.js API might be perfectly written.

but It doesn't matter if the VPS disk is full.

Your application can't write new files.

Your database may not be able to expand.

Logs stop being written.

Eventually, things start breaking in strange ways.

The application is the symptom.

The server is the cause.

CPU spikes matter

Suppose your server normally runs around:

Then suddenly:

for several minutes.

That might mean:

unexpected traffic
runaway process
expensive database operation
infinite loop
background job
compromised server
badly optimized code

You don't necessarily want an alert every time CPU touches 90% for three seconds.

That would become noise.

But sustained abnormal usage?

You probably want to know.

Something like:

CPU usage has remained above 90% for 5 minutes.

That's actionable.

Disk space is boring until it destroys your weekend

Disk monitoring might be one of the least exciting things in software.

Until this happens:

Databases need disk.

Logs need disk.

Uploads need disk.

Temporary files need disk.

Docker images need disk.

Backups may need disk.

A slowly growing log directory can quietly consume storage for weeks before anything obviously fails.

So instead of discovering:

after the damage starts, monitoring should warn you earlier:

The alert isn't the solution.

It gives you time to create one.

Network problems are different from downtime

A server can be reachable and still have terrible connectivity.

Maybe:

Your users experience the application as slow.

Your uptime monitor says:

All systems operational.

Both statements can technically be true.

This is why latency belongs beside uptime.

You want to understand:

Is the server reachable?
How quickly is it responding?
Has network latency changed?
Are packets being dropped?
Is one region behaving differently?

Availability and performance are related, but they are not the same thing.

Monitoring without alerts is just a dashboard

There is another mistake I've seen:

Beautiful monitoring dashboards.

Charts everywhere.

CPU graphs.

Memory graphs.

Latency graphs.

Error graphs.

But nobody is staring at those dashboards at 3:17 AM.

A monitoring system needs a way to say:

Something changed. You should look at this.

That could be:

depending on how the team works.

The important part is delivering the right alert to somebody capable of acting on it.

For example:

Production API Down

api.example.com has failed 3 consecutive health checks.

Last successful check: 02:41 UTC

Or:

Server CPU Alert

CPU usage on production-01 has remained above 90% for 5 minutes.

That is much more useful than discovering the problem because somebody posted:

“Is your site down?”

on Twitter.

But alerts can also become useless

The opposite problem is alert fatigue.

If your system tells you:

every thirty seconds, you eventually stop caring.

Then the important notification gets buried with everything else.

Good monitoring needs thresholds.

And often, duration.

Instead of:

CPU crossed 80%.

think:

CPU remained above 85% for five minutes.

Instead of:

One request failed.

think:

Error rate exceeded 5% over the last five minutes.

The goal isn't maximum notifications.

The goal is useful awareness.

Monitoring should exist at multiple layers

I've started thinking about production monitoring as two connected systems.

Layer 1 — Application

Watch:

Layer 2 — Infrastructure

Watch:

Because sometimes the application is broken.

Sometimes the infrastructure is broken.

And sometimes one is telling you something about the other.

Seeing both makes diagnosis much easier.

Monitoring shouldn't begin after something breaks

This is probably the most important part.

Teams often add monitoring after their first serious incident.

Something goes down.

Nobody notices for forty minutes.

Users complain.

The team fixes it.

Then someone says:

“We should probably add monitoring.”

Monitoring shouldn't be the postmortem action item.

It should be part of getting something into production.

I've increasingly started thinking about the backend lifecycle as:

Build → Verify → Deploy → Operate → Own → Monitor

Building answers:

Can we create it?

Verification asks:

Does it behave correctly?

Deployment asks:

Can we get it into production?

Operations asks:

Can we manage it there?

Ownership asks:

Do we retain control of what we're running?

And monitoring asks:

Will we know when something changes?

That last question matters more once nobody is sitting there watching the terminal.

This is something we're working on ourselves

We've been thinking about this while building CrescoDB.

CrescoDB already manages the production server layer for projects deployed through it, so we can see things like server availability and runtime health.

We're now expanding that into a more complete monitoring layer.

Not an attempt to recreate every observability feature from platforms built entirely around monitoring.

The goal is simpler:

Give smaller engineering teams the information they actually need to know when something is going wrong.

At the application level:

And underneath that:

Then push useful alerts through the channels teams are already watching:

Telegram, Slack and email.

The interesting part for us isn't adding another dashboard.

It's connecting application health with the infrastructure running it.

Because if your API goes down at the same moment the server's memory hits 98%, those two pieces of information probably belong beside each other.

Production is really about feedback

When you're developing locally, feedback is immediate.

Something breaks.

Your terminal tells you.

You fix it.

Production creates distance between the developer and the software.

Monitoring closes some of that distance.

It tells you:

Something changed.

before the user has to.

And that might be the simplest definition of good monitoring:

Knowing your software is unhealthy before your customers do.

What production issue have you had that proper monitoring would have caught earlier?

AI Made Building Software Faster. It Didn’t Make Production Easier

The Saint — Fri, 02 Oct 2026 09:00:12 +0000

A weird thing is happening in software development.

Building software has become ridiculously fast.

You can describe an application to an AI coding tool and have a working interface within minutes.

Need an API?

Generated.

Database schema?

Generated.

Authentication flow?

Probably generated too.

A solo developer can now build something in a weekend that might have taken a small team several weeks a few years ago.

That is genuinely impressive.

But there’s a point where the speed suddenly disappears.

It usually happens around the moment someone says:

“Alright. Put it in production.”

And now you have a completely different problem.

Generating code and running software are different jobs

AI is extremely good at helping us produce software.

It can generate:

routes
database models
API handlers
authentication
tests
Dockerfiles
CI configs

But generating those things doesn't automatically mean the resulting system is ready to serve real users.

Production introduces questions that don't matter nearly as much while you're working locally.

What happens if your server crashes?

What happens if a database migration fails halfway through?

What happens when two users modify the same data simultaneously?

Where are your logs?

How do you know the application is healthy?

Where are your backups?

Have you ever restored one?

How do you roll back a bad deployment?

What happens when your server runs out of memory?

Who gets alerted when any of this happens?

AI can help answer every one of those questions.

But somebody still has to ask them.

The bottleneck is moving

For years, one of the biggest constraints in software was simply writing the thing.

You needed enough engineering hours to turn an idea into functioning software.

AI is reducing that constraint.

Not eliminating it, but reducing it significantly.

So another constraint becomes more visible:

Operating what we build.

We are creating applications faster than ever.

But those applications still need databases, deployments, infrastructure, monitoring, migrations, security, backups and recovery.

If development becomes 5x faster while everything after development remains roughly the same, then production becomes a larger percentage of the work.

That changes the developer workflow.

“It works” is becoming an increasingly dangerous milestone

There's a huge difference between:

It works.

and:

It can survive production.

An application running on your laptop usually has ideal conditions.

You're probably the only user.

The database is nearby.

You know the environment.

You can restart everything.

You can read the terminal directly.

If something breaks, you are literally sitting in front of it.

Production removes most of those advantages.

Now the application needs to behave correctly when nobody is watching.

That means the definition of “finished” starts expanding.

Instead of:

Feature works ✓

you eventually need something closer to:

Feature works ✓

Tests pass ✓

Configuration verified ✓

Migration safe ✓

Deployment reproducible ✓

Monitoring active ✓

Backups available ✓

Rollback possible ✓

This part is much less exciting than generating a beautiful application from a prompt.

Unfortunately, users don't care which part was exciting.

They care that the software works.

AI can also create operational debt faster

There's another side to faster development.

When building becomes easier, it becomes easier to build more.

More features.

More endpoints.

More dependencies.

More services.

More database tables.

More infrastructure.

And every additional moving part becomes something that might eventually need to be operated.

You can create complexity faster than you can understand it.

That's an interesting problem.

A developer might previously spend three days implementing a feature and naturally become familiar with almost every part of it.

Now an AI agent might generate the same feature in twenty minutes.

The output arrived faster.

The developer's mental model did not necessarily accelerate at the same rate.

That gap matters when something breaks.

This changes what developers need to get good at

I don't think the lesson is that developers should stop using AI.

Quite the opposite.

The productivity increase is too useful to ignore.

But our skills probably need to move upward.

Knowing how to generate code becomes less valuable than knowing how to evaluate it.

Questions like:

Is this architecture appropriate?
What assumptions does this code make?
What happens when this fails?
Is this secure?
How will I observe this in production?
How do I recover from failure?
What happens at 100x the current traffic?
What dependencies am I introducing?

Those questions become increasingly important.

The job starts moving from:

How do I write this?

toward:

How do I know this is actually good?

That is a much more interesting engineering problem.

Production is where abstractions meet reality

Development tools can hide an enormous amount of complexity.

And that's usually a good thing.

Good abstractions let us build faster.

But production eventually exposes whatever the abstraction didn't cover.

Your database doesn't care how quickly the application was generated when a migration locks a table.

Your server doesn't care that an AI wrote the endpoint when memory usage keeps growing.

Your users don't care how impressive the development process was when authentication goes down.

Reality remains annoyingly traditional.

Networks fail.

Disks fill.

Processes crash.

Humans make mistakes.

Dependencies break.

Credentials expire.

And software has to deal with all of it.

The next generation of developer tooling will probably move downstream

We've spent the last few years making creation dramatically easier.

AI coding agents.

App generators.

Better frameworks.

Managed databases.

Backend-as-a-service platforms.

Component libraries.

All of these reduce the time between idea and working software.

The next major opportunity may be making everything after creation equally simple.

Not just:

Build

but:

Verify → Deploy → Operate → Recover

Because if AI keeps making software creation faster, developers are going to produce more software.

And all of that software eventually has to run somewhere.

The interesting question isn't “Can AI build this?”

We're rapidly reaching a point where the answer to that question is often:

Probably.

The more useful questions are becoming:

Should we build it this way?

Is it ready for production?

Can we understand what happens when it fails?

Can we safely operate it?

Can we recover?

The impressive part of software development is becoming easier.

The boring part is becoming the bottleneck.

And ironically, the boring part is usually what determines whether the software actually survives.

Has AI made you ship faster, or has it just moved the difficult part of your work somewhere else?

Writing About Code Has Made Me Better at Writing Code

The Saint — Wed, 30 Sep 2026 08:07:50 +0000

Most developers treat technical writing as something you do after you know what you're talking about.

I've started thinking about it the other way around.

Sometimes I don't realize how poorly I understand something until I try to explain it.

You can spend hours working with a piece of technology and feel completely comfortable with it.

Then somebody asks:

Why does it work that way?

And suddenly your brain goes:

Well… it just does.

That's usually the point where you discover the difference between recognizing something and actually understanding it.

Code lets you hide behind working software

Programming has an interesting loophole.

Your code can work even when your mental model is incomplete.

You can know that:

await db.query(...)

works.

You can know where to put it.

You can know how to handle the response.

But that doesn't necessarily mean you understand:

what happens when the connection drops
how the connection pool behaves
when the promise resolves
what happens under concurrent requests
how the database handles the query
what failure actually looks like

And that's fine.

Nobody needs to understand every abstraction underneath every line of code they write.

But the gaps become obvious when you attempt to explain the system to another person.

Writing removes the autocomplete from your understanding.

Explaining something forces you to find the missing pieces

Let's say I want to write:

"A database connection pool improves performance."

Easy sentence.

Then I ask myself:

Why?

Because we're reusing connections instead of creating one for every request.

Okay.

Why is opening a new database connection expensive?

Now we're talking about networking, authentication, resource allocation and connection setup.

What happens if the pool is exhausted?

What decides how many connections should exist?

Can too many connections make performance worse instead of better?

Five minutes ago I thought I was writing one paragraph.

Now I'm reading PostgreSQL documentation.

That's what I like about writing.

It exposes the edges of what you actually know.

Tutorials are especially unforgiving

When you're coding alone, you can skip steps mentally.

You know that before this:

npm run dev

you already:

npm install

created .env, configured the database and probably fixed three errors you no longer remember.

The reader doesn't know any of that.

So when you're writing a tutorial, you have to reconstruct the real sequence.

That forces you to think more carefully about:

dependencies
assumptions
defaults
edge cases
setup
failure states

You begin noticing complexity you've learned to ignore.

I've had several situations where writing about a workflow made me think:

Why does this require so many steps in the first place?

Which is also where product ideas tend to appear.

Writing is surprisingly good product research

This one wasn't obvious to me initially.

When you try to explain a technical problem properly, you naturally start researching how other developers solve it.

Suppose I'm writing about deploying a backend.

I might start with:

"Deploying a backend requires…"

Then I need examples.

So I start looking at:

Docker
Railway
Render
VPS deployments
CI/CD
migrations
reverse proxies
environment management
health checks

And while reading, patterns start showing up.

Everyone has slightly different solutions to the same underlying problems.

You start noticing where tools overlap.

Where workflows are unnecessarily complicated.

Where developers complain.

Where documentation repeatedly has to explain the same thing.

You weren't doing market research.

You were trying to write a decent article.

But you end up learning a lot about the market anyway.

Writing also generates ideas

One article tends to create five more.

You start writing about logging.

Then you realize error reporting deserves its own article.

That leads to observability.

Then production debugging.

Then distributed tracing.

Then suddenly you have a backlog of topics you didn't have yesterday.

It's basically recursion for ideas.

The most useful part is that the ideas aren't coming from:

"What should I post today?"

They're coming from questions you naturally encountered while trying to understand something.

Those tend to make better articles.

It changes how you read documentation

Before I started writing more often, documentation was usually transactional.

I had a problem.

I searched for the answer.

I copied the relevant mental model into my brain.

Then I left.

Now I notice more things.

Why did the documentation explain this concept before that one?

What misconception are they trying to prevent?

Why is this warning here?

What edge case was common enough that somebody decided it deserved an entire section?

Good technical documentation isn't only teaching you the technology.

It's showing you where people usually misunderstand it.

That information is incredibly useful.

It makes vague opinions harder to keep

Developers have plenty of opinions.

"This framework is slow."

"Microservices are overkill."

"SQL is better."

"Serverless is expensive."

"X is easier than Y."

Those opinions are easy to say.

They're much harder to publish when you know another developer can ask:

Based on what?

Writing forces you to qualify things.

Instead of:

Serverless is expensive.

You start writing:

Serverless can become expensive for workloads with these characteristics…

Which is a much better statement.

You stop trying to sound certain and start trying to be accurate.

That's useful far beyond writing.

You don't have to become a "content creator"

This is probably the part developers hate.

The moment somebody says:

You should write.

it starts sounding like:

Build your personal brand. Post three times every day. Optimize engagement.

I'm not talking about that.

You can write once a month.

You can have 20 readers.

You can publish something that gets absolutely no traction.

The value isn't only distribution.

The process itself is useful.

You are forcing your brain to turn:

I think I understand this

into:

Here is exactly how I think this works.

Those are very different things.

The simplest writing habit I've found

When something makes me stop while coding, I write it down.

That's it.

Things like:

Why did this migration fail?

Why does this API behave differently in production?

Why are these two tools solving the same problem differently?

Why does this configuration exist?

What actually happens when this command runs?

You don't need the article immediately.

Just keep the questions.

When you eventually sit down to write, you're not staring at a blank editor trying to invent a topic.

You're answering something that genuinely made you curious.

And curiosity is usually a better starting point than a content calendar.

Writing is part of learning

I used to think the sequence was:

Learn → understand → write

Now I think it's closer to:

Learn → write → discover what you don't understand → learn more → rewrite

And the loop keeps going.

The article is almost a side effect.

The real output is a clearer mental model.

So if you're learning something, building something or repeatedly solving the same technical problem, try writing about it.

Even if nobody reads it.

You'll probably discover something you didn't know you didn't know.

Your Backend Works Locally. That Doesn’t Mean It’s Production-Ready

The Saint — Tue, 29 Sep 2026 00:07:56 +0000

You finish the feature.

The API responds correctly.

The database connection works.

Authentication passes.

You run the app locally for the tenth time and everything looks fine.

Then someone says:

“Cool. Let’s deploy it.”

And suddenly the problem changes completely.

A backend that works on your laptop is not necessarily a backend that is ready for production.

Local development proves that your application can run in your environment.

Production asks a much harder question:

Can this thing keep working when the environment is no longer under your control?

That difference is where a lot of small teams get caught.

Local development hides a lot

Your development machine is unusually forgiving.

You probably have:

the correct environment variables
direct access to the database
the right runtime installed
every dependency available
full filesystem permissions
a predictable network
logs directly in your terminal
one developer making requests
a database you can reset without consequences

Production gives you none of those guarantees.

The application now needs to survive restarts, failed migrations, missing secrets, expired credentials, network interruptions, disk limits, bad deployments and actual users.

That means “it runs locally” is only the beginning.

Configuration becomes infrastructure

Locally, this might be enough:

DATABASE_URL=postgresql://localhost:5432/app
JWT_SECRET=dev-secret
PORT=3000

In production, configuration has consequences.

What happens if JWT_SECRET is missing?

Does the application refuse to start?

Or does it silently fall back to something unsafe?

What happens when:

process.env.DATABASE_URL

is undefined?

A production backend should fail predictably.

For example:

const required = [
"DATABASE_URL",
"JWT_SECRET"
];

for (const variable of required) {
if (!process.env[variable]) {
throw new Error(
Missing required environment variable: ${variable}
);
}
}

It is simple, but it is much better than discovering the problem after deployment.

Configuration should be validated before the application begins accepting traffic.

Database migrations stop being harmless

During development, database changes are easy.

Something breaks?

Reset the database.

Change the schema.

Run the migration again.

Move on.

Production is different because the database contains data you cannot casually destroy.

Imagine changing:

ALTER TABLE users
DROP COLUMN username;

locally.

No big deal.

Now imagine doing that with 50,000 production users and discovering another part of the application still depends on username.

The migration technically succeeded.

The deployment still failed.

Production migrations need to consider:

backwards compatibility
existing data
rollback strategy
application version compatibility
long-running operations
database locks

For risky changes, the safer pattern is often incremental.

Instead of:

remove old field
deploy new code
hope

you might:

add new field
deploy compatible code
migrate data
verify
remove old field later

The boring version is usually the safer version.

“The server is running” is not a health check

Your process can be alive while your application is effectively dead.

Maybe:

PostgreSQL is unreachable
Redis is unavailable
migrations failed
storage credentials are invalid
an external dependency is timing out

Your process manager may still happily report:

RUNNING

That is why production systems usually need an actual health endpoint.

A simple example:

app.get("/health", async (req, res) => {
try {
await db.query("SELECT 1");

res.status(200).json({
  status: "healthy"
});

} catch {
res.status(503).json({
status: "unhealthy"
});
}
});

Now your infrastructure has something meaningful to test.

Not:

Is Node.js still running?

But:

Can this application actually serve requests?

That distinction matters.

Logging changes when nobody is watching the terminal

During development:

console.log(error);

often feels perfectly adequate.

You are already looking at the terminal.

Production errors usually happen while nobody is looking.

And this:

Something went wrong

is almost useless three hours later.

Useful production logs should tell you things like:

what happened
when it happened
which request triggered it
which service failed
how severe the failure was

Structured logs are much easier to search and process.

Instead of:

console.log("Database error");

something closer to:

logger.error({
event: "database_connection_failed",
requestId,
error: error.message
});

gives you something you can actually investigate.

Production observability is not about printing more text.

It is about leaving enough evidence to understand failures after they happen.

Backups do not matter until restoration works

A lot of systems technically have backups.

Far fewer know whether those backups can actually be restored.

There is an uncomfortable difference between:

“We create a backup every night.”

and:

“We successfully restored yesterday’s backup into a clean database.”

The second statement proves something.

The first only proves that a file exists somewhere.

A production backup strategy should answer:

How often do backups run?
Where are they stored?
How long are they retained?
Are they encrypted?
How quickly can they be restored?
When was restoration last tested?

A backup you have never restored is still partly a hypothesis.

Deployment without rollback is a one-way door

Imagine deploying version 1.8.

Ten minutes later:

error rates spike
users cannot authenticate
database queries slow down
one endpoint starts returning 500

What happens next?

If the answer is:

“Give me twenty minutes while I fix it.”

you do not really have a recovery strategy.

Sometimes the fastest fix is simply returning to the last known-good version.

That requires your deployment system to know:

v1.6
v1.7
v1.8 ← current

and to make returning to:

v1.7

boring.

Production reliability is not about never breaking anything.

Eventually something will break.

Reliability is largely about reducing how expensive failure becomes.

Production traffic exposes assumptions

During local development you might be the only user.

Production introduces:

User 1
User 2
User 3
...
User 10,000

And all of them can do things at inconvenient times.

You start encountering problems like:

race conditions
exhausted database connections
duplicate requests
slow queries
rate abuse
concurrent writes
memory growth
unexpectedly large payloads

For example, this query may seem harmless:

SELECT *
FROM orders;

until orders contains several million records.

Production has a habit of turning assumptions into benchmarks.

A better definition of “done”

For a backend feature, “done” should probably not mean:

✓ Works locally

A stronger checklist is closer to:

✓ Works locally
✓ Configuration validated
✓ Database changes are safe
✓ Authentication and permissions verified
✓ Health checks available
✓ Errors observable
✓ Deployment reproducible
✓ Backups exist
✓ Restoration tested
✓ Rollback possible
✓ Production behavior monitored

Not every side project needs enterprise infrastructure.

But every application should know what level of failure it is prepared to tolerate.

That is the important part.

The backend lifecycle is bigger than building

Developers spend a lot of time discussing how quickly we can create APIs, databases and authentication.

Those things matter.

But building the backend is only one stage.

Eventually the lifecycle becomes:

Build → Verify → Deploy → Operate → Own

And the transitions between those stages are where a surprising amount of engineering time disappears.

That is also the problem we have been thinking about while building CrescoDB: how to give smaller engineering teams a cleaner path through the backend lifecycle without forcing them to stitch together an increasingly complicated production stack.

But regardless of which tools you use, the principle stays the same:

A backend isn't production-ready because it runs. It's production-ready when you understand how it fails.

What is the one production check you wish you'd added before one of your deployments went wrong?