DEV Community: The Saint

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?