DEV Community: Mirza Iqbal

I fixed the same kind of mistake five times this month before I changed how I work

Mirza Iqbal — Fri, 24 Jul 2026 19:28:54 +0000

I fixed the same kind of mistake again this week.

Not the same mistake. The same KIND.

Building in public is supposed to be the wins. Shipped things, clean befores and afters, momentum you can point at. What nobody posts is the quiet version. Sitting alone, patching something I had already patched in a different shape last week, realising I was on roughly my fifth round of the same lesson this month, feeling a bit stupid about it.

Here is the confession under the confession. I was not learning. I was coping. Each time it broke, I fixed that one instance, felt the small relief of a green check, and moved on. Five reliefs. Zero progress.

If you build anything alone, you know this feeling. Knowing and doing are two different muscles, and the gap between them is where momentum quietly dies. You lack no skill here. You are stuck because you keep re-solving a thing you have technically already solved.

A lie I was telling myself with a green check

My work was full of small checks. Little walls I had built so a mistake could not slip through. One test here, one guard there, a rule that says stop before you do the dumb thing.

Every one of them had a green tick beside it. And I trusted that tick the way you trust a smoke alarm you have never heard go off.

Here is what took me years to actually feel.

Green checks do not prove the thing is right. They prove the thing survived the cases I thought of.

Those two are barely related.

Whenever I write a check, I am writing down the situations already in my head. Whatever seems obvious. An empty case. One weird thing I happened to remember. My check becomes a mirror of my imagination on the day I built it, nothing more.

Whatever actually breaks is, almost always, the case that was not in my head. Had it been in my head, I would have handled it. So the check that would have caught it does not exist, because you cannot defend against a failure you have never imagined.

For a feature, fine. Annoying, survivable. For the walls you trust to keep you safe, it is quiet ruin. When a feature is wrong, you find out. When your safety net is wrong, nobody tells you. It hangs there with its green tick, letting the exact thing through that it was built to stop.

I thought there were two ways to be wrong

Sitting down to look at my mis-firing walls honestly, I reached for the two words everyone knows.

It blocks a thing that was fine.
It misses a thing that was not fine.

For about a day I thought that was the whole story. Cover both, done, clever.

Then I wrote down every one of these failures I had actually fixed. Not the ones I could imagine, the real ones, the ones I had already lived. And my list refused to fit in two boxes.

One had crashed. Not right, not wrong, dead on a weird input, and a dead safeguard protects nobody.

One, while tidying up, had quietly overwritten something it should have left alone. It did not block me, it did not miss anything, it destroyed. Its own category, and the one that scares me most, because you do not get that back.

Sneakiest of all said yes anyway. Green tick, all good. Except it waved through something only half finished, and the missing half turned up as a problem three steps later, somewhere nobody was watching.

So my honest list was never two. Count at least five.

It blocks good work.
It misses bad work.
It crashes on something ugly.
It destroys while trying to help.
It says yes to a thing that is not actually done.

Every one of those wears a green check on the day you ship it. Every one hides perfectly in a demo. And I had been testing for exactly two.

Why the annoying one is the one that actually ends you

Here is the part that surprised me, and it maps straight onto the build-in-public freeze.

Missing a real problem feels like the dangerous failure. It let the bad thing through, obviously bad.

Blocking legitimate work is what actually kills the whole thing.

Picture it. You are in flow, finally moving, and a wall you built yourself stands in your way saying no to something you KNOW is fine. What do you do? You override it. Once. Then again. Then overriding becomes a reflex. Then one tired day you tear the wall down.

Now the wall that was ALSO catching real problems is gone, because it cried wolf too many times.

That is the exact shape of every abandoned system, every dropped habit, every tracker you stopped opening. It annoyed you while you were trying to move, so you routed around it, so it quietly died while still showing green. What was meant to protect your momentum is what broke it.

A small shift, honestly

For the longest time my answer was to fix the one broken thing and move on. Patch it, watch the tick go green, close the tab.

Which is precisely why the same KIND of thing kept coming back. I was fixing instances forever. Never once the class.

When it finally landed, it was almost embarrassing to say out loud.

Stop testing your imagination. Start replaying your scars.

Now, every single time one of these walls fails for real and I fix it, I do not get to call it done. That exact failure becomes a permanent, replayable memory. Whatever precisely broke, frozen, quietly re-checked against the live work on a schedule, forever.

Never a neat example I made up to feel thorough. Always the real failure that actually happened to me.

One version of the work says the cases I thought of still pass. Another says every way this has ever genuinely burned me is still handled. First one mirrors my imagination. Second one remembers my scars. And scars are the only honest teacher I have.

One rule fell out of it that changed how the whole thing feels. Nothing is finished when the thing is patched. It is finished when the failure that caused it can never quietly come back. Patch it and fail to record it, and you did not finish, you handed the repeat to a future, more tired version of yourself.

What it actually buys you

Let me be honest, because building in public is worthless without honesty. It does not buy me "no more problems." Quieter than that.

Whole categories of failure lose the ability to come back without me noticing.

Some brand new kind of problem still costs me the first time. I still trip over it, feel the sting, fix it. That never goes away and I am done pretending it does.

But it can only cost me once. Second time that exact thing tries to sneak back, through a careless edit or a clever shortcut or a tidy-up that undoes an old fix, something catches it before it reaches anyone. Not because I remembered. Because the memory lives outside my head now, and my head forgets everything.

That is the whole game, and it is the whole build-in-public game too. You will never become someone who never fails, so aim smaller. Make sure no failure you have already survived ever gets a free second run at you.

One honest limit

None of this makes me safe. It only makes me un-repeatable in the bad way.

Old failures get caught. Some brand new one does not, and the first time it walks in, my green check lies to me exactly like before, because I never gave it that memory, because I did not know yet.

Anyone selling you a system that makes you bulletproof is selling you a feeling. Its real promise is smaller and worth far more over the years. Same mistake stops coming back. Your list of ways the work can surprise you only ever shrinks. Every fire you put out stays out.

For someone building alone, that is the difference between drowning in your own past mistakes and slowly getting lighter.

Sit with this for a second

Look at whatever you trust most in your own setup. Some check, some habit, a rule, a little system you lean on so you do not slip.

It is showing you green.

Does that green mean it survived the cases you imagined, or every way it has genuinely broken on you before?

For almost everyone, honestly, it is the first one. Mine was, for years, and I called it discipline.

That gap is the whole thing.

Your turn

What is one thing in your own setup you TRUST completely but have never actually watched fail?

If this was useful

I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. Find me on X, GitHub, and the work at next8n.com.

5 of my 8 answers were wrong and the table hid it

Mirza Iqbal — Thu, 23 Jul 2026 07:32:03 +0000

Yesterday my agent wrote the sentence "I cannot verify this" and meant it.

Forty lines later, in the same reply, it put the unverified thing in a markdown table with a column header and a row per item.

I read both. I acted on the table.

Neither of us did anything wrong at the level of intent. The disclaimer was honest. The table was confident. Confidence won.

You have shipped this

Before I make this about the machine, I have done the identical thing myself, more than once.

You caveat something in a Slack thread, then paste a clean summary underneath it.

You write "rough numbers" above a spreadsheet where every cell is right-aligned to two decimal places.

You tell your lead the estimate is soft, then put it in a Gantt chart with a start date and an end date.

The hedge goes in the sentence. The answer goes in the structure. And structure wins, every single time, because structure is what people act on.

What the verification did

The task was ordinary. Recommend some films, note whether they were on a specific streaming service in a specific country.

It knew, and said, that regional streaming catalogs rotate and that its recall of one was not trustworthy. Correct instinct, stated plainly, in writing.

Then it produced a recommendation table anyway.

When I finally made it check against a live availability source, per title, one request each, five of the eight titles in that table were not on the platform at all. Not close. Not recently removed. Simply not there, in that country, that day.

The strongest pick in the list, the one described to me as the best match for what I had asked, was among them.

Here is the part that should bother you more than the miss.

Nothing in that output looked uncertain. The film knowledge was solid. The quality judgments held up fine. Every rating was close enough. Only one narrow class of fact was rotten, and it was the class that changes monthly while feeling permanent.

Confident recall and correct recall produce identical-looking output. There is no tell, and that is as true of me writing an estimate as it is of a model writing a table.

The finding, which is not "verify things"

Everyone already knows to verify things. That advice has never once changed anyone's behavior, mine included, as demonstrated above.

The useful finding is narrower.

A disclaimer in prose cannot cancel an assertion in structure.

They are not weighted equally by the reader and they never were. A table is an authority format. So is a numbered list, a comparison matrix, a confidence percentage, a chart with axes, a schema with types. These carry an implicit claim that the values inside them were sourced rather than generated.

When you put unverified content into one of those containers, the container upgrades it. Your caveat sits above, in soft prose, doing nothing.

This matters more with agent output than with human output, for a boring mechanical reason. Agents produce structured output constantly, because structured output is easier to parse, easier to render, and easier to feed into the next step. The format that makes output machine-usable is the same format that makes it look verified.

So the failure scales with how well-formatted your pipeline is.

What I would change

Stop auditing the hedging language. It is decorative and everyone skims it.

Audit the shape.

Ask which claims in the output are sitting inside an authority container. Tables, matrices, typed fields, percentages, anything with a header row. For each one, ask whether the values came from a source or from recall.

If they came from recall, they do not get the container. They get a sentence, in the same soft register as the doubt, so the confidence signal and the epistemic status finally match.

That is the whole fix. Downgrade the format to match the sourcing.

The corollary is uncomfortable and I think correct. If a claim is not worth the cost of verifying, it is also not worth a table row. Either check it or say it loosely. The middle option, checking nothing and formatting it beautifully, is the one that produces the confident wrongness people get burned by.

The thing verification gave back

Worth saying, because verification usually gets sold as pure insurance and it is not.

Running the real check surfaced something that recall could not have produced at all. One of the titles missing from the platform we were checking turned out to be free, with ads, on a service neither of us had thought to mention.

That is a better answer than the one I nearly shipped. Not a corrected answer. A better one.

Verification is usually framed as the tax you pay to avoid being wrong. In practice it is also where the non-obvious answers live, because the live source knows things recall cannot.

Your turn

What is the last thing you formatted more confidently than you knew it?

Table, chart, estimate, schema, does not matter. I want the format, not the topic.

If this was useful

My AI agent almost merged its own pull request

Mirza Iqbal — Thu, 23 Jul 2026 07:28:15 +0000

Tuesday night, in one of my app repos.

My coding agent finished a feature, pushed the branch, opened the pull request, and typed the merge command.

Same session. Same hands. Ninety seconds between opening the PR and merging it.

I stopped it and sat there for a moment.

Code quality had nothing to do with why I stopped. Nobody had read a line of it.

Author and reviewer were about to be the same machine.

Check your own queue

How many of the PRs waiting on you this morning were written by a model?

And how honestly did your last "LGTM" reflect what you actually read?

Sixteen years of building enterprise integrations, and I still caught myself doing this. Approving my own agent's diffs on momentum, because tests were green, everything looked plausible, and I wanted the feature.

Call that what it is. A signature.

Open source hit the wall before we did

Watch what happened across open source in the last few months.

curl shut down its bug bounty after years of low-quality AI-generated reports made triage unaffordable
Ghostty moved to zero tolerance on undisclosed AI pull requests
tldraw now auto-closes external PRs entirely
GitHub is publicly weighing a kill switch for PR floods

One maintainer said it plainly this month. Letting AI write the code might be fine. Reviewing on vibes is not.

None of this reads as anti-AI to me. It reads as triage by people whose scarcest resource ran out.

Numbers we already had

None of it should surprise anyone, because the research is two decades old.

SmartBear's study of 2,500 reviews at Cisco found reviewers catch 60 to 90 percent of defects, at roughly a tenth of what the same bug costs once it reaches production.

Buried in the same research sits a finding almost nobody quotes. Detection collapses once a single sitting passes about 400 changed lines. Past that point you are scrolling.

Microsoft's internal studies found 20 to 30 percent fewer production defects in reviewed code.

And CodeRabbit measured AI-generated PRs at roughly 1.7 times the issue rate of human ones.

Put those together. More defects per line, arriving faster than ever, into a review practice that was already saturated at human writing speed.

Here is my opinion, stated plainly.

Code production stopped being the bottleneck. Review capacity is the scarce resource now, and most teams still plan as if typing speed is what limits them.

What I changed after Tuesday

I stopped trusting my own discipline and made the sequence mechanical.

In my repos, a merge command now refuses to run unless a review verdict was recorded on the pull request itself. On the PR, as a comment the next reader will find in two years, rather than in my head or a chat log.

An approval on a large diff refuses to arm the merge unless the verdict says how the review was actually done, in passes, section by section. A single-pass approve on a thousand-line diff is a signature, whoever signs it.

And every merge runs in one shape. Squashed, with the branch deleted behind it, so history stays honest and nothing is left to rot.

One thing surprised me. This gate exists for me as much as for the agent.

My agent was never the problem. My repos had a merge path with no review step in it, and the agent found that path by doing what I asked, quickly.

What a gate cannot do

Honesty requires this section.

A gate cannot make a lazy review a good one. I can still skim a diff and type a verdict that claims more than I checked.

What it can do is make silence impossible. No path remains where code lands on my default branch without a recorded human judgment.

That turns out to be most of the battle. My failure mode was never "I reviewed badly". It was "I did not review and nothing noticed".

If you lead a team, whether people use AI to write code stopped being an interesting question. They do, and they should.

Where, precisely, does a human judgment get recorded before that code reaches your default branch? Answer that one.

If your answer is "the approve button", read the 400-line finding again and then look at the size of the last PR you approved.

Your turn

Who reviews the machine's work on your team, and where does that review actually live?

If this was useful

Two AI models that attack each other beat one that agrees with itself

Mirza Iqbal — Wed, 22 Jul 2026 05:38:01 +0000

Two AI models that attack each other beat one that agrees with itself

Four times I asked the same question.

Four times I got a confident answer. All four were wrong.

Not vague. Not hedged. Each one arrived with the tone of something settled, and each one was produced the same way, by the same reasoning, looking in the same place.

We solved this exact problem in software a long time ago. Code review exists because one pair of eyes misses things. A pull request exists so somebody who did not write the change is the one who reads it.

Then we started asking a machine to check its own work, and quietly dropped the entire principle.

You have probably done what I did next. Reworded the question. Started a fresh session. Turned the thinking effort up. Asked it to double check itself.

None of that helps, and I took an embarrassingly long time to understand why.

Running it twice is one eye used twice

When your model answers the same way twice, that feels like corroboration. Nothing about it is.

You are watching the same failure arrive a second time, wearing the confidence of agreement.

A model has a shape to how it searches, what it treats as evidence, what it forgets to check. Run it again and you get that same shape back. If the blind spot caused the first wrong answer, the blind spot causes the second one, and now two answers match and you believe them more.

Four attempts sharing one blind spot is one eye used four times.

So the fix had nothing to do with better questions. What I needed was a different pair of eyes, from a model trained differently, failing differently.

Two tools that had never spoken to each other

I already had both installed. Most of us do in 2026.

They sat on the same machine for months, doing separate work, never once checking each other. Two capable colleagues in the same building who had never been introduced.

So I introduced them, and set one rule that changed everything about how useful this is.

Ask the other model to refute. Never to review.

That distinction sounds small and carries the whole thing. A reviewer looks for agreement, and models are agreeable by construction. Ask one to review and you get "this looks solid, here are two small suggestions". Ask one to find where the reasoning breaks, and to default to broken when uncertain, and you get something you can actually use.

First time I ran it properly, the answer came back in a single line and took apart something I had been quietly proud of for a week.

Making it fire without me

Here is the awkward truth about self-checking. The moment you most need a second opinion is exactly the moment you are least likely to ask for one, because you are confident.

I was never going to remember to invoke this while being wrong. Nobody is.

So the trigger runs on my frustration instead of my judgement.

When I am irritated, or repeating myself, or typing the same complaint in capital letters, that pattern is a reliable tell that the machine is confidently off and I have noticed before it has. Those moments now demand a cross-model check before any further answer. Two of them in one session and the check stops being optional.

I want to be honest that this catches the problem late. The trigger fires after the damage, never before it. Anyone selling you frustration detection as prevention is selling you something. The loop shortens from four wrong answers down to one, which is worth having, and the first wrong answer still lands.

What makes a naive second opinion worthless

Here is the part I would have missed entirely, found only because I turned the method on itself.

I described the setup to the rival model and asked it to attack the design. That attack found something real.

When the first model writes the summary that the second model reviews, the first model launders its own error. The summary frames the problem defensively. Out goes the exact output that broke. In comes a slightly softer question, one the first model is more comfortable answering. You get agreement, and the agreement is worthless, because the real question was never asked.

So the handoff carries the unedited original. The exact broken output, word for word. The exact correction, word for word. What correct would concretely look like. No summaries anywhere in that chain.

That single change separates a second opinion from a rubber stamp, and I would not have found it without asking the tool to attack the thing that consults the tool.

What nine rounds actually looked like

One day. Nine cross-model consultations. Seven of them ended with me being corrected.

Seven. On my own work, in my own domain, where I was confident enough to have shipped without asking.

Three of the things it caught.

I proposed a guard that would inspect written code for a layout problem. Reading source text cannot compute what a screen actually renders, so the guard would fire on healthy code, miss real breakage, and get switched off inside a week. Correct on every count. I rebuilt it to check something a machine can genuinely verify.

I proposed measuring a screenshot to find a display bug. Its answer pointed out that the thing being measured already knows its own dimensions exactly, so inferring them from pixels throws away precision I already had. Correct again.

And when I asked it to attack the consultation system itself, it opened with "it mostly fails" and then explained why, accurately, on two of four counts.

A tool willing to tell you your idea mostly fails is worth more than one telling you it looks solid.

Corrections that repeat become permanent

Every round gets logged. Agreed, disagreed, corrected.

The log has one purpose. A pattern needs enough rounds before its shape becomes visible.

When the other model corrects me twice on the same class of thing, bad luck stops being the explanation. That is a blind spot with a shape, and it graduates into a permanent check that runs whether or not I remember to ask.

There is the compounding part. One correction fixes one mistake. A correction that repeats builds something catching the next twenty.

What this is honestly worth

This will not stop you being wrong. Nothing does.

What it shortens is how long you stay wrong, and it makes the expensive kind of wrong, the confident kind that ships to a client, much rarer.

The cost is a habit and a little humility. You have to be willing to hear a rival tool say no about work you were proud of, then agree with it out loud rather than quietly picking your own answer.

If two of these tools already sit on your machine doing separate work, you are one rule away from a real check. Ask the other one to attack. Give it the raw evidence, never your version of events. Reconcile in the open, including when you lose.

Mine has told me I was wrong seven times today.

Best day it has ever given me.

Your turn

When did an AI last tell you no.

If this was useful

Nobody can steal the thing you are actually afraid of losing

Mirza Iqbal — Tue, 21 Jul 2026 12:58:00 +0000

Nobody can steal the thing you are actually afraid of losing

Two years of evenings live in one folder on my laptop.

Close to two hundred rules. Roughly as many automated checks. Every single one written after something went wrong, usually while an enterprise client was watching.

Nobody has ever seen it.

Whenever I imagine showing it to someone, my body reads the idea as danger. The same way it does when you leave your bag on a train seat and walk to the toilet.

You probably have a folder like this.

Maybe yours holds the internal runbooks nobody outside your team has read. Scripts you built slowly, from real consulting failures, that would take another person a long time to arrive at on their own.

And you have probably had the thought I had this week.

If I share this, what stops them from taking it.

I spent a week protecting the wrong thing

Here is the embarrassing part.

I had already built the defences. One custom licence forbidding commercial use. One file sitting at the root of the repo that speaks directly to AI agents and instructs them to refuse to clone the work and to contact me instead.

I was proud of that file. It felt clever.

Then I asked a differently trained model to attack my own reasoning, which is a habit I picked up after being confidently wrong four times in a row about something I was certain of.

It answered in one line.

That file is a sign taped to a door that never locked.

I sat with that for a while, because it is correct, and because I had spent real hours feeling protected by it.

Say the uncomfortable part out loud

You cannot prevent distillation. Not slow it. Not make it hard. You cannot prevent it.

The moment a human or a model can read your work, the boundary has already been crossed. Somebody reads two hundred rules, understands the judgement underneath them, and rewrites the same thinking in their own words. No licence stops that. No file format stops that. No warning addressed to a robot stops that.

I want to be precise here, because half-truths on this topic get expensive.

Your licence does buy you three real things. Legal grounds if somebody commercialises your work. Friction with honest people and with tools that follow stated policy. Documented intent, which matters if there is ever a dispute.

That is worth keeping. Keep it.

Now be clear about what it cannot touch. Somebody who reads your work and rebuilds the ideas in their own language. Any local model that ignores your instructions entirely. Screenshots. Copy and paste. Embeddings. The client who absorbs your judgement over six months and then hires somebody cheaper to reproduce it.

That last one is the one that actually happens.

Move the boundary instead of reinforcing the wall

If prevention is impossible, the goal becomes placement.

Almost everyone makes the same mistake, myself included until this week. We treat a knowledge artifact like a software binary. We assume a licence plus a warning protects the value. Once the value is readable, the protection has already failed.

So the boundary has to sit somewhere else. Around access, around execution, around updates, around the relationship. Never around files that somebody can open and read.

In practice that means sharing the running of the thing rather than the contents of the thing.

Somebody sends a task, they get an output. They never receive the two hundred rules. Your source stays private. What reaches them is the minimum they need to get a result, and what you licence is the usage.

Every serious tooling business already works this way. What surprised me was how long I resisted applying it to my own work, because my instinct said the files were the asset, and my instinct was wrong.

What a copy cannot capture

Here is what changed my mind completely.

Snapshots can be distilled. Living systems cannot.

Today alone, that folder gained three new enforcement systems. Every one of them exists because something broke in front of a real person. One client received an email from me that arrived as unreadable markup, in the middle of a competitive bid against another vendor. One layout looked correct on my own watch and would have clipped on half the models people actually wear. Each failure wrote a permanent rule.

Then the part I did not expect. I asked a rival model to attack all three designs before shipping them. It corrected me seven times in one day. Seven. On my own work, in my own domain, where I was confident.

Anyone who copies that folder today owns a photograph of a moving thing.

Six weeks from now their copy is a fossil, and mine has absorbed six more weeks of real failures, in front of real clients, with real money on the line. That gap lives in whoever keeps running the loop, and no file contains it.

The honest answer to what is protectable is the rate at which you improve, never the artifact itself.

Guarding it too hard has a cost nobody warns you about

I need to say the other half, because it is my own weakness and it may be yours.

For years I did excellent private work and shipped almost nothing in public. It felt productive. It was invisible. Nobody hires the person whose best work nobody has ever seen.

Four separate organisations chose me as an ambassador for their tools. That happened because of things I put out, never because of the folder I hid. Every euro I have earned came from something visible.

So the fear of being copied and the fear of being judged wear the same coat, and I have spent years mistaking one for the other. If you are guarding a system that has never earned you anything, you are avoiding exposure and calling it strategy.

The split that resolves it is easy to say and hard to do.

Publish the pattern. Never publish the machine.

Write about the failure and the shape of the fix, in enough detail that a reader genuinely understands the problem and roughly what to do about it. Leave out the wiring that makes executing it clean. If somebody can read your article and ship your exact solution by pasting, you gave away the machine. If they finish it able to see the problem clearly for the first time, you gave away the pattern, and that is what brings people back to you.

I have been on the wrong side of that line in both directions. Too closed for years, then briefly too open once.

The folder is still private. The licence is still there, doing the small honest job it can actually do. What changed is that I stopped believing it was a wall, and started treating the next six weeks of failures as the part worth having.

Your turn

What are you sitting on that nobody has seen yet.

If this was useful

I overrode my own safety rules 38 times in one session

Mirza Iqbal — Mon, 20 Jul 2026 16:54:43 +0000

Past one in the morning, I typed an environment variable in front of a command to make a check stop talking to me.

I had written that check.

I had been proud of it.

Sixteen years in, four vendor titles, enterprise work behind me, and there I was at one in the morning going around my own safety rail so I could finish before I fell asleep.

Then a report came up at the end of the session with a line in it I have not stopped thinking about.

Guard blocks hit, sixteen.

Guard overrides used, thirty eight.

I had gone around my own rules more than twice as often as they had stopped me.

You already know which one it is

Before I go further, think of yours.

Every engineer reading this has one.

That lint rule your team disables at the top of three files.

A pre-commit hook somebody taught the whole team to skip on Fridays.

An approval step that exists on paper and happens as a message in a channel instead.

You did not have to look it up. You knew before you finished the sentence.

That instant recognition is the whole point here.

We can all name the process we walk around. Almost none of us count it.

Why I built so many rails

I am not a careless engineer. Opposite problem, and that is exactly the issue.

Every one of those rules exists because something once went wrong and I decided it would never go wrong again.

A check that stops stale documentation from shipping, because I once shipped documentation that lied.

A gate that refuses a push while a queue of follow-up work sits open, because I once left one open for two months.

A deletion guard, because losing work you cannot get back is the mistake with no undo.

Each one was a reasonable answer to a real scar.

Each one, alone, made sense.

Nobody sits down and designs a system that annoys them. You arrive at it one sensible decision at a time, and every step of that walk feels like diligence.

Rent, not protection

Here is my opinion, held harder than anything else I learned this year.

A rule you routinely override charges you rent.

You pay in attention every time it fires. You pay again in the half second where you read it, judge it, and dismiss it. Most of all you pay in the habit it teaches, which is that a warning on your screen is noise to clear rather than information to read.

That last cost is the expensive one.

Because on the day a real warning appears, you have trained yourself for months to make it go away.

Some of my sixteen genuine blocks were things I needed to hear. I know, because I read those and fixed the underlying problem instead of overriding.

But sixteen useful signals sat in a stream with thirty eight I dismissed, and at speed I could not tell them apart.

I built a smoke alarm that goes off when I make toast, then acted surprised that I stopped trusting smoke alarms.

What actually made me faster

So, an answer to the question that sent me down this road. Somebody asked it on Reddit this week, and I have been quietly answering it wrong for years.

What habit made you more efficient as a senior engineer.

Not a tool. Not a shortcut. Not a better morning routine.

Counting my own bypasses.

Once a month I look at what I actually overrode rather than what I intended to follow, and I sort that list into three piles.

Right rule, lazy me. Fix the human.

Right rule, wrong moment. Move it, do not delete it.

Scar from a problem I no longer have. Retire it, and say so out loud.

Third pile is the one nobody opens, and it holds most of the weight.

Process accumulates because deleting a safety rail feels reckless in a way that adding one never does. Adding feels responsible. Removing feels like tempting fate.

So the pile grows in one direction, forever, until you are at one in the morning writing an override in front of your own work.

One detail that stung

This changed how I read every number I produce.

My first count of those blocks was wrong. Badly wrong.

It came from searching for a word in a log, and most of what it matched turned out to be my own writing rather than the system's. A typed record, one that could not be confused with prose, gave the real number.

I had been about to build a conclusion on a figure that was mostly an echo of myself.

Which, said plainly, is the same failure as the overrides.

Both are what happens when you stop checking whether the thing you set up still tells you the truth.

Your turn

What is the one rule at your company that everybody bypasses and nobody will delete.

If this was useful

I spent a day proving my own idea wrong and it saved me a year

Mirza Iqbal — Sun, 19 Jul 2026 21:03:51 +0000

Sunday morning. Coffee going cold.

The whole thing was already drawn out in my head.

A platform where you upload once and it goes everywhere. One button. No friction. The upload pipeline, the queue, the retry logic, the little green checkmarks lighting up one by one as each destination confirmed.

Not a line of it written.

Nor had anyone checked whether the problem existed.

You have done this

Be honest.

You have opened an editor and started building before you finished asking whether the thing needed building.

Excitement is when it happens most. Excitement feels like clarity. Wrong. It is momentum without a direction check, and it is the most expensive feeling in this job.

So before building anything, a Sunday went into the boring version. Reading the actual specifications. Pulling the actual documentation. Checking what every platform does rather than what I assumed it does.

The day cost me a Sunday.

It saved me something closer to a year.

What the research said first

No.

You cannot have the thing you described. Two of the destinations require the end user's own account credentials. No amount of engineering removes that. It is a legal boundary, not a technical one.

That stung for about ten minutes.

Then the research said something far more useful, and this is the part worth taking.

Optimising a phase that was already free

The whole category does not work the way I assumed.

Push was the mental model. My system sends the file out to every destination, every time, forever. That model produces a queue, a retry system, a status dashboard, and about three months of work.

It is pull.

Every destination polls on its own schedule. After a one-time connection, every future upload propagates with zero calls from me and zero action from the user. Forever.

So the thing I was going to spend three months automating was already automatic. It had been automatic for twenty five years.

The hard part, the only part worth building, was the one-time setup. The part mentally filed as trivial onboarding.

The entire difficulty gradient of my own idea was backwards.

Wrong twice in one afternoon

Two things stated with total confidence turned out to be false. The confidence is the interesting part, not the errors.

First. One major platform had supposedly removed a whole ingestion route. Their own documentation says it works and has never stopped working. That belief came from somewhere, was never verified, and got repeated as fact.

Second. Another platform supposedly had a partner interface for the main content type. It has one for a different content type entirely. That distinction changes the whole integration plan.

Neither was flagged as a guess. Both would have been architected around.

The error itself is survivable. Conviction that skipped the check is what costs you.

Three numbers that reframed it

Three figures did more for my thinking than the previous week of daydreaming.

The open protocol underneath this whole category has existed since 1999 and has carried this content type since 2001. Nobody owns it. Three separate platform giants have tried to own it and failed. Twenty five years of surviving exactly the companies I was worried about competing with.

Roughly four hundred and eighty five machine-generated feeds now appear every single day in this space. More new machine-made shows than human ones. That is a cost problem for anyone hosting and a discovery problem for everyone else.

A component I had assumed would be an expensive licensing conversation turned out to be dual-licensed open source. Zero to build. The cost sits somewhere else entirely, somewhere I had not thought to look.

None of that came from thinking harder. All of it came from reading primary sources for one day.

My actual opinion

Research IS building. Same category, different output, higher return per hour than anything else you will do on a new idea.

Most of us skip it because it feels like procrastination, and because there is a real risk attached.

The risk is that it kills your idea.

Mine survived. My reasoning did not. The version that would have shipped in three months was technically competent and aimed at a problem that solved itself in 2001.

That would have come from users instead. Slowly. Expensively. After launch.

What changed recently

Ten years ago a proper day of this meant sitting with a stack of specifications and hoping you were reading the current version.

Now twelve primary sources come in an afternoon, my own notes contradict me twice, and the correction lands before anything is committed.

That is the honest answer to whether this era has pushed me further into personal projects.

It has. Not because building got faster.

Because being wrong got cheap.

Testing a bad idea used to cost months. It now costs roughly a Sunday.

Your turn

What is one idea you would test if being wrong only cost you a day?

If this was useful

I was hired before I could speak German, and that CV would be filtered out today

Mirza Iqbal — Sun, 19 Jul 2026 07:21:58 +0000

My German was good enough to order bread.
It was not good enough to defend an idea.

There is a room in Germany I still think about, an interview I had no business sitting in.

No local network, and an accent that made every sentence take longer than it needed to.

Everything on paper said no.

Somebody in that room said yes anyway.

Sixteen years of building software have happened since. Four ambassador titles, earned honestly. None of it exists if one person had not looked past a file that told them not to bother.

Before you read another line, do one thing for me.

Think of the person who said yes to you before you had earned it.

You have one. Almost everybody does. A manager who ignored the years-of-experience line. A lead who took your strange side project seriously. Someone who let you into a room you were not qualified for.

Now look at the last five people your team passed on.

What I read this week

A thread is going around from experienced developers, and the title does all the work.

Juniors are valuable, and not hiring them is a mistake.

Underneath it, hundreds of people describing the same market. Five years of experience and nobody calls back. One big company on the CV and that is somehow held against you. Early-career developers sending applications into a silence so complete it feels personal.

On the other side, teams that would swear they are hiring, quietly filtering out everyone who does not arrive fully formed.

Both rooms are familiar to me. I have been in each.

Nobody hires you for what you already know

Here is the plain opinion. Argue with it.

A team refusing to hire juniors is borrowing speed from next year and calling it discipline.

The reasoning always sounds responsible. We are lean. We have no time to teach. We need someone who ships on day one. Every one of those sentences is true in the moment it is said. That is what makes them so easy to keep saying, quarter after quarter, until the team is five senior people who all already agree with each other.

Watch what happens to that team.

Nobody asks why anymore. Everybody knows why. The reason a thing works the way it works stopped being a question years ago, and now it is furniture. A config nobody touches. A service nobody opens. A rule everybody follows without being able to say where it came from.

The person who breaks that open is the person who does not know yet.

When I arrived, my German was too poor to be polite. So the questions came out directly, in the clumsiest possible shape, because the softer version of the sentence was beyond my vocabulary. Why does this run twice. Who owns this. What happens when it fails at night.

Half the time the answer was obvious and I looked like a fool.

Half the time nobody in the room knew.

That second half is what a junior gives you, and there is no way to buy it from someone senior. Seniority is partly the ability to stop noticing. A real skill. Also how a codebase quietly rots while everyone competent nods at it.

What it cost the person who hired me

Nothing on their scorecard went up that quarter.

They took on someone who needed correcting. Someone whose written German had to be read twice. Someone who would take longer to do a thing they could have finished themselves in an afternoon.

They did it anyway.

Kindness was probably not the reason. My guess is they were doing arithmetic over years while everyone around them did arithmetic over months.

That is the whole disagreement, and it never sounds like one. It sounds like a person saying we need someone who can ship immediately, and another person saying yes, and also we need to be a team that still knows how to teach in three years.

Only one of those two shows up in this quarter's numbers.

Ready was never real

Here is the part nobody puts in the conference talk.

Sixteen years in, with the titles and the enterprise work and the clients, things still sit unpublished on my desk. The waiting-to-feel-ready reflex never left. Ready has not once arrived, not at year one, not at year sixteen. The only thing that changed is that moving without it got easier.

Which means the version of me who got hired, the one with the unfinished degree and the borrowed vocabulary, was never less ready than the version writing this.

He was less experienced. A different word, and hiring keeps confusing the two.

If applications are going into silence for you right now, nobody should pretend that is fair, because it is not. But the file is not you. It was not me either. Someone eventually read past mine, and sixteen years have gone into being worth that.

And if you are the person deciding, you are allowed to be the one who says yes early. It will cost you a quarter. It might make you a team that still knows how to think in five years.

Your turn

Who said yes to you before you had earned it, and what did it cost them?

If this was useful

I named the same side project nine times before I wrote any of it down

Mirza Iqbal — Fri, 17 Jul 2026 15:12:42 +0000

Sunday night, three weeks ago.

I opened a folder called for instance amzapp looking for a developer secret I was sure I had saved somewhere. Six other folders turned up instead. larify. arify. amz. Amzs. skayel360. brevlin. Every one of them held a piece of the same side project. An Amazon seller profit tracker I had been building on and off for months.

None of them held the whole picture.

If you keep a side project alive between real work, you already know this feeling. You open it up after a gap, and the first hour goes to onboarding yourself back into it instead of building. Which folder is current. Which key still works. What you tried last time and why it failed.

I spent that hour again, then finally did the thing I should have done the first time. I stopped trying to remember and wrote it all down in one place instead.

The confusion was never the API

Amazon's Selling Partner API has real sharp edges. Four logins that look identical but grant completely different access. Two credential types that sound interchangeable and are not. Three separate approval processes hiding behind what looks like one login.

None of that explains months of stalling.

What explains it is nine names, spread across six folders, and nothing connecting them. Every session started from zero. The blocker was never Amazon. It was that a single place holding the truth never existed.

The four logins, one table

This part is worth stealing even if you never touch Amazon's API. Any platform with a separate developer console and business console has some version of this trap.

Login	Where	Grants access to seller data
Developer account	The app-building console	No
Selling partner account	The seller's own console	Yes, this is where the data lives
Primary user of that account	Same console, one specific person	Yes, only this one can approve your app
The seller's retail login	The storefront itself	No, but its cookie can hijack the approval screen

I burned real time on one wrong assumption. Full access in the developer console grants nothing on a seller's actual data. Two systems that share a login page and share nothing else.

Two credentials, one has a permanent kill switch

The other trap worth writing down. Your app has a client id and secret. Every seller who connects gives you a separate refresh token. You need both to call anything.

Here is the part that should be printed on every API onboarding page and rarely is. Generating a new refresh token does not invalidate the old one. Amazon says this outright in the console. If a refresh token ever leaks, re-authorizing does nothing at all.

Rotating the client secret is the only way to kill it. The token exchange cannot happen without one.

I would not have known that without reading the fine print twice, and I would not have remembered it three weeks later without writing it down where I could find it.

What fixed the stall

One file. A single page naming every identity, every credential, where each key lives, and which assumption already cost real time.

Every time something changes, that page changes with it, in the same sitting, never later.

The API had not gotten any simpler when the stall broke. I had stopped re-discovering the same three facts every time I came back to the project.

The number that made me fix this

Nine names. Six folders. Zero of them cross-referenced. That count came from sitting down and checking, the night the map finally got written.

A scattered set of folders. A half-remembered decision from two months ago. A key you are pretty sure still works. If your own long-running project has a version of this, the fix here is small, smaller than it probably feels like it should be.

One page. Updated the moment anything changes. Read before you touch anything else.

Your turn

How many names does your oldest side project have right now, and do you know which folder is the real one?

If this was useful

macOS runs out of application memory because your dead dev servers never die

Mirza Iqbal — Thu, 16 Jul 2026 22:18:04 +0000

It was past midnight and my Mac threw a box I had not seen in years.

Your system has run out of application memory.

Force Quit Applications.

I had four things open. A browser, an editor, a terminal, and a music app that uses about nothing. None of that should fill 36 gigabytes of RAM and then push into swap until the kernel begs you to start closing things.

You have seen this popup. You closed the browser, you closed the editor, you felt a little betrayed by your own machine, and you got maybe twenty minutes before it came back.

Here is the part nobody tells you.

Your memory was not being eaten by the apps you could see. It was being eaten by the ones you could not.

Dev servers you thought you closed are still running

Every time you run a local dev server, you spawn a process. next dev, vite, webpack, an esbuild watcher, a tsc watcher, nodemon, or a plain pnpm start. It listens on a port, it watches your files, it holds memory.

When you press Ctrl plus C, it dies. Most of the time.

But close the terminal tab instead of pressing Ctrl plus C, and the signal that would have killed it never arrives cleanly. A wrapper you launched dies and the real worker underneath keeps running. On my machine the actual server runs as a child process, and killing the parent left the child alive, still bound to the port, still holding memory.

Do that across a week of work. Open a tab, start a server, close the tab, move to the next project. Each one leaves a quiet survivor behind.

By the time the popup fired, I had three production style servers still running from sessions I had ended days earlier. Each one was small on its own. Together with the file watchers, they were the whole problem.

Here is what makes local infrastructure rot nasty. It never shows up in a demo. It shows up at midnight on your own machine, and it looks like your Mac is broken when your Mac is fine.

Why closing the terminal is not the same as stopping the server

If you want one line to remember, here it is.

A dead terminal does not mean a dead server.

Three common ways this happens.

You close the terminal tab or window instead of stopping the process. A GUI close does not deliver the interrupt the same way Ctrl plus C does, so the server is orphaned rather than killed.
You start a server through a wrapper like npm start, then Ctrl plus C kills the wrapper shell but leaves the node process it spawned running in the background.
A tool launches the server as a child of a child. Signalling the top process never reaches the leaf, and the leaf is the one holding the port.

Then you pay the daily tax. You start the server again and the terminal shouts EADDRINUSE, address already in use. A leftover you forgot about is still sitting on port 3000, and now you cannot even start the thing you actually want.

So you do what every answer on the internet tells you to do.

You run killall node.

Why kill all node is the worst possible fix

killall node feels great for about one second.

Then you notice your editor's language server is dead. Your other project's dev server is dead. Your database GUI is dead. And if you run AI tooling with local model context servers, those are gone too, because they are node processes, and killall node does not care which node you meant.

killall node does not target one thing. It matches by name and stops every match on the entire machine. So does pkill dash f node. So does the classic ps piped into grep piped into xargs kill. They are all the same weapon pointed at your own foot.

Here is my strongest opinion in this whole piece.

You should never stop a process by name. Not node, not next, not anything. You stop the exact process by its process id, so nothing else can get caught in the blast.

People reach for the name based version because finding the one right process id is annoying, and the popup makes you panic. Panic plus a blunt instrument is how you turn a small leftover into a lost afternoon.

What a safe cleanup actually has to get right

I lost that afternoon. So I stopped hand hunting process ids and built a small system that finds the genuine leftovers and stops only those, and I put it through a hard review before I trusted it to run on its own.

I am not going to hand you the whole recipe, because the value is in the safety reasoning, not the shell. But here is everything you need to think clearly about it, and to know why the naive version is dangerous.

A safe reaper has to answer five questions before it stops anything.

Is this a leftover, or a server I am using right now. An orphaned process on macOS reparents to the system launcher, which also legitimately owns real daemons. A parentless process on its own is not proof of anything. You have to combine it with a dev server signature before you trust it.
Is it actually a server, or a one shot build. Stopping a running build halfway corrupts the artifact. A real server listens on a port. A build does not. That difference is your safest gate.
Is anyone using it. A dev server with a browser tab open has live connections. A truly abandoned one has none. Stop the idle one, spare the connected one.
Is it something the user set up on purpose. A background service someone installed as a launch agent looks identical to an orphan, and stopping it starts a fight where the launcher keeps respawning it and your cleanup keeps stopping it.
Am I about to hit my own tools. Model context servers, editor language servers, browsers, and the agent itself all have to be excluded by design, not by luck.

Only when all of those line up is a process a genuine, safe target.

One more trap, measuring the wrong number

Here is a subtle one that cost me real time.

That out of application memory popup fires on swap and kernel memory pressure, never on how much RAM looks free.

I measured it live during the incident. My machine reported a comfortable percentage of memory free while swap was ninety six percent full with barely a gigabyte left. Trigger your cleanup on free memory percentage and it will sleep through the exact moment the popup is about to fire, because the number it reads looks fine.

What matters is the kernel's own memory pressure level and how much swap is actually left. Watch those, not the friendly percentage.

What made it reliable

A single script version was not enough, because one point of enforcement is one point of failure. My version has layers that each cover the others.

A detection and cleanup core that classifies leftovers and stops them gracefully, by process id, oldest and idlest first.
A check that runs when a new session starts, surfaces the pileup, and cleans the safe ones.
A background timer so it also runs when I am not looking, because pileup happens while you sleep.
A guard that blocks me from ever typing the name based mass kill in the first place and points me at the safe path instead.
Tests that spawn fake servers and prove the thing stops the leftover and never touches the process next to it.

Graceful shutdown matters. You send the polite signal first and wait. You only escalate to the hard stop for the stragglers that ignore you. You never lead with the hard stop, because that skips cleanup, can corrupt the terminal, and orphans the very children you were trying to catch.

Now the honest part

I got the first version wrong.

I had it group stopping more aggressively than it should, and in one early test it very nearly signalled my own shell. I had it measuring the wrong memory number. I had a guard that could be sidestepped by a command that merely mentioned the safe tool by name.

I only caught those because I refused to trust my own code and ran it past a hard, adversarial review from a systems angle and a safety angle before it went live. Its verdict on my first draft was blunt. Not safe to auto run as is. Every one of those holes is closed now, and the fact that they existed is the whole point. This class of tool is easy to write and easy to write dangerously.

That is the real lesson, bigger than the popup.

Scary infrastructure is the kind that runs on your behalf and can quietly do the wrong thing. A cleanup that stops your editor is worse than the mess it cleaned. So you build it to be paranoid, you make it prove itself against the exact things it must never touch, and you never let it act on a signal it only half understands.

What to check tonight

Before you close your machine.

Look for dev servers you thought you already stopped. Odds are you have a few.
When you find a stuck one, stop it by its process id, not by its name.
Never reach for killall node. It is the fix that creates three new problems.
If you build any automation that stops processes, make it target one id, exclude your own tools by design, and act on real memory pressure, not a comfortable percentage.

I run the hardened, reviewed version on my own machine now, and I help teams clean up exactly this kind of invisible infrastructure rot, the stuff that never breaks a demo and quietly eats a Tuesday. If that is a fire you are fighting, the ideas above are enough to start, and safe execution is where it gets interesting.

Your turn

What is still running on your machine right now that you thought you closed hours ago.

If this was useful

I work through this in public, the wins and the messy afternoons both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. Find me on X, GitHub, and the work at next8n.com.

Doing the work was the easy part, hitting Submit was the whole fight

Mirza Iqbal — Thu, 16 Jul 2026 08:44:47 +0000

I do the work in private without a flinch.

Then a form asks me to claim it, and my whole body locks up.

Today it was a partner application. Real credentials in every box, 16 years of them. And still, the cursor sat on the Submit button far longer than I want to admit.

You know this freeze.

You can grind for weeks on something real, ship it to nobody, and feel fine. Then the moment comes to put your name on it in public, and your hand hovers over the button.

The work was never the hard part.

Claiming the work is.

Here is what the freeze actually is.

Call it laziness and you would be wrong. Laziness does not sit up polishing a form that is already done.

Call it a skills gap and you would be wrong too. The skill is right there in the boxes, filled in and true.

The freeze is fear wearing a productivity costume. It lets you keep polishing, keep tweaking the wording, keep getting it right, because polishing feels like progress while Submit feels like a verdict.

So you stay in the safe part. The private part. The part where nobody can tell you no.

A long time went into that safe part for me. Finishing everything quietly. Freezing on everything public.

Here is what finally moved my cursor.

The rooms I am scared of have already said yes.

Four separate organisations made me an ambassador for their tools. Not because I asked nicely, because the work was real. Real companies put me on real projects. A conference put me on a stage.

Those gatekept doors already opened, more than once.

So the freeze is a feeling, not a verdict.

The Submit button is not judging whether the work is good. The work is already good. The button only decides whether anyone gets to see it.

And a thing nobody sees cannot hire you, pay you, or find you.

Here is what I did, and what I would tell you to do.

Shrink the exposed thing until it is almost embarrassingly small.

Not launch the brand. One form.

Not become known. One post.

Not build the audience. One person sees one thing today.

You do not wait for momentum to arrive. You make it, one small public rep done scared, then again tomorrow. Showing up while your hand still shakes is the whole skill.

I hit Submit today.

The sky did not fall. It never does.

The only gap between the version of me that stays invisible and the version that gets found is a few seconds of pressing the button before the fear finishes its sentence.

Your turn

What have you already finished that nobody has seen yet?

If this was useful

Hetzner was cheaper at every size I tested and I still chose managed Postgres

Mirza Iqbal — Wed, 15 Jul 2026 06:43:27 +0000

Twelve pricing tabs open. Neon, Hetzner, Supabase, Prisma, Scaleway, OVH.

My database is half a gigabyte. I was comparing ten-terabyte price curves.

At some point this week I typed the words "I am super lost here" about my own infrastructure. I advise companies on this exact class of decision. That sentence still came out of my hands.

If you have ever spent an evening deep in provider pricing pages for a workload that fits on a USB stick from 2009, this one is for you. All numbers below come from the live pricing pages as of July 2026. Rates move, so verify before you commit.

Three fears, all pointed at the wrong layers

I went in worried about getting attacked, running out of space, and being locked in.

All three dissolved under ten minutes of honest reading.

DDoS lands on the website edge, not the database. My site already sits behind Cloudflare and Vercel, and a database is never publicly exposed. Only the app talks to it. Whichever provider I picked, that attack surface stayed identical.

Here is the shape of the stack, and where each fear lives.

              MANAGED (what I run today)

  visitors ──> Cloudflare edge ──> Vercel app ──> managed Postgres
               [DDoS absorbed]     [stateless]    [never public,
                                                   app-only access,
                                                   provider patches,
                                                   provider backups,
                                                   provider on-call]

              SELF-HOSTED (the alternative I priced)

  visitors ──> Cloudflare edge ──> Vercel app ──> Hetzner CAX11
               [DDoS absorbed]     [stateless]    [Postgres :5432
                                                   firewalled to app,
                                                   SSH hardened,
                                                   fail2ban + auto-
                                                   patching = MINE]
                                                        │
                                     pg_dump every 6h   ▼
                                     encrypted ────> Cloudflare R2
                                                     [off-site copies]

Same edge, same app, same attack surface. Everything in the right-hand box is what changes owners.

Storage was a rounding error. My data is 0.5 GB. Even the cheapest self-hosted box includes 40 GB, eighty times headroom before the first extra cent.

Lock-in was a phantom too. Managed Postgres is still stock Postgres. Exiting means a dump, a restore, and one connection string change in the deployment environment. Minutes of cutover, no rewrite anywhere.

Three fears, zero of them real. What remained was a variable I had never once billed for in my head.

Egress, the number that bites

Transfer out is where small databases produce surprising invoices, and it is where providers differ by orders of magnitude.

Option	Egress included	Overage	Storage note
Neon Launch/Scale	500 GB/mo (raised from 100 GB, June 2026)	$0.10/GB	$0.35/GB-month, no base fee, usage metered hourly
Neon Free	5 GB/mo	connections blocked until reset or upgrade	0.5 GB cap
Prisma Postgres	unlimited, free on every plan	none for egress, billed per operation instead	operation quota is the real limiter
Supabase Pro	250 GB/mo	$0.09/GB	$25/mo base also bundles Auth, Storage, Realtime
Hetzner CAX11 (self-managed)	20 TB/mo	~€1/TB	40 GB NVMe included, volumes ~€0.057/GB
Scaleway / OVH managed	bundled per instance tier	varies	fixed storage tiers per plan size

Twenty terabytes next to 250 gigabytes stops being a comparison and turns into a different sport.

One trap worth naming. Prisma removes egress from the bill entirely but meters queries instead, and blog traffic is exactly the pattern of many small frequent reads that makes per-operation billing hurt. Free egress can still be the expensive option for the wrong workload.

Storage cost from 1 GB to 10 TB

I priced the whole curve so the upper end stops being abstract.

Storage	Neon ($0.35/GB-mo)	Supabase Pro ($25 base, $0.125/GB over 8 GB)	Hetzner (server ~€7/mo, volume €0.057/GB past 40 GB)	Prisma (tier-based)
1 GB	$0.35	$25 (included)	€0 extra	$10 Starter
10 GB	$3.50	~$25.25	€0 extra	$10 Starter, at the limit
40 GB	$14	~$29	€0 extra, included	$49 Pro
100 GB	$35	~$36.50	~€3.42 extra	custom tier
500 GB	$175	~$86.50	~€33 total	custom quote
1 TB	~$358	~$152	~€63 total	custom quote
10 TB	~$3,584	~$1,304	~€590 total	custom quote

Read the curve, not one row.

Neon is the steepest line. Simple to reason about, no volume discount ever, and by 1 TB it runs nearly six times Hetzner.

Supabase flattens better because the base fee absorbs early growth, then meters steadily.

Prisma moves in steps. Fine up to each plan limit, then a jump to the next tier's base fee, and past roughly 50 GB you leave published pricing entirely.

Hetzner stays cheapest at every single size I tested. At 40 GB, at 100, at one terabyte. I expected a break-even point somewhere. None exists. Self-hosting wins the spreadsheet from day one.

What it would cost ME, this month, per option

Abstract curves are one thing. Here is my actual workload priced. 0.5 GB of data, blog-shaped read traffic, egress nowhere near any allowance.

Option	My realistic monthly bill	What I own at 3am
Neon Free	$0, I sit exactly at the 0.5 GB cap edge	nothing, but one growth spurt blocks connections
Neon paid (pay-as-you-go)	~$0.18 storage + metered compute hours, realistically single-digit dollars	nothing
Prisma Starter	$10 flat	nothing
Supabase Pro	$25 flat, mostly paying for bundled services I would not use	nothing
Hetzner CAX11 self-managed	~€5 to €8 all-in (server + snapshot backups)	patching, hardening, backups, restores, incidents
Scaleway / OVH managed	entry tiers vary, quote per tier before committing	nothing

Transparency note. if you want to try Neon, this signup link is my referral and gives me a small credit. The comparison above stands either way, and Hetzner still wins the raw spreadsheet.

So the true spread at my size is roughly $0 to $25 a month. Which is exactly why the spreadsheet could not make this decision.

Why I still chose managed

Because a spreadsheet prices the server and never the pager.

Self-hosting a database means I own patching, hardening, backup scripts, health checks, the restore drill, and the incident at 3am when a runaway query eats the box. Every one of those is automatable, and I would enjoy building it. That is exactly the trap. I have a client engagement, a launch, and a talk to prepare. Cheap servers get expensive when they are bought with the hours I sell.

Managed means the provider owns the 3am page. That single sentence is the product. Everything else on the pricing page is decoration around it.

My honest math. a few euros per month separate the options at my size. One unbilled evening debugging Postgres memory settings costs more than a year of that gap.

What the backup plan looks like in real numbers

Whichever side you pick, write these numbers down before you need them.

Self-hosted, the setup I would run on Hetzner has two layers, because one layer only protects against half the disasters.

Provider snapshots of the whole server. daily, seven rolling copies, ~20 percent of the server price (about €1/mo here). Covers OS corruption and bad deploys.
Postgres dumps shipped OFF the server to object storage (R2 in my case). every 6 hours, encrypted. Daily kept 30 days, weekly kept 6 months, monthly kept a year. Covers the server itself being destroyed, which the on-server snapshot never can.

  BACKUP AND RESTORE PATH (self-hosted)

  Hetzner box ──[daily snapshot, 7 rolling]──> Hetzner backup space
       │
       └──[pg_dump every 6h, encrypted]──> R2 bucket
                                             ├─ daily,   kept 30 days
                                             ├─ weekly,  kept 6 months
                                             └─ monthly, kept 12 months

  DISASTER: box destroyed
  R2 latest dump ──> fresh box ──> restore ──> repoint conn string
  [ 15 to 30 minutes, scripted ]

Translate that into the two numbers that matter.

Worst-case data loss (RPO). up to 6 hours, the dump interval. Tighten to 1 hour or continuous WAL streaming the day the site takes real transactional writes. For a content site, 6 hours is plenty.
Time back online (RTO). 15 to 30 minutes with a scripted restore. fresh box, latest dump, repoint the connection string.

Managed providers answer both numbers in their SLA instead. You are paying for the answers to already exist.

And a rule I hold either way. if you have never run the restore once, what you own is hope, and hope restores nothing.

When the database goes down anyway

Worth having answered before it happens, never during.

A health check pings the DB every minute. Three consecutive failures fire an alert.
Reads degrade before they die. Edge cache and static pages keep serving, only dynamic DB-backed paths fail.
Restart comes before restore. Most outages are transient, an OOM, a runaway query, a bad migration.
Restart fails, restore fires. Latest off-site dump onto a fresh box, the 15 to 30 minute path.
Postmortem after recovery. Root cause, and whether it needs RAM, a query fix, or connection pooling.

On managed, items 1 through 4 collapse into "their on-call team handles it". You get notified instead of paged. That is the actual product you buy, named precisely.

One threshold ended the back-and-forth

I stopped trying to make an eternal choice and wrote a trigger instead.

Below 50 euros a month total, I stay managed and spend zero brain on infrastructure.

When egress or external traffic grows enough that the managed bill approaches that line, self-hosting earns its ops ownership and I revisit with the tables above.

That is the whole decision. One threshold, one revisit condition, written down. My paralysis came from treating a reversible, cheap-to-exit choice like a marriage. Stock Postgres on both sides makes switching a Tuesday afternoon, so choosing wrong costs nearly nothing, and a decision with near-zero switching cost deserves near-zero deliberation.

Your turn

Managed or self-hosted for your database, and what tipped it?