DEV Community: Info Inlet

I deleted 2,000 lines of code and shipped zero new features. It was the best thing I did all year.

Info Inlet — Mon, 02 Nov 2026 08:49:03 +0000

The biggest pull request I opened all year was two thousand lines long. And every single one of them was red.

No new feature. No new endpoint. Nothing a user would ever see. Just a minus sign in front of two thousand lines of code that already existed, that were running in production right now, that I was asking to simply delete.

I sat with my finger over the button for a long time before I opened it. Deleting code you didn't write, in a path you're not sure you fully understand, feels exactly like defusing something. Every line I was cutting was a line someone had added on purpose, once, for a reason — and if I was wrong about even one of them, I wasn't shipping a feature that didn't work. I was pulling out a guardrail that something real was leaning on.

I shipped it anyway. It was the most important thing I did all year, and it's not close. And the reason why is the exact opposite of how I'd spent the previous two years measuring my own work.

The pile

The two thousand lines weren't one person's mistake. They were sediment.

There was a write path in our app — the part that saves a user's work — that had been quietly flaky for as long as anyone could remember. Not broken. Flaky. Every few weeks someone would report that something they'd saved wasn't there, nobody could reproduce it, and the ticket would go cold.

And every time it flared, somebody did the reasonable thing. They added a retry. Then a second retry with a backoff. Then a cache, so the UI could still show the work even when the read came back empty. Then a try/catch that swallowed the error "so it wouldn't crash the page." Then a background job that reconciled the cache against the database every few minutes to paper over the gap. Each layer got written fast — a lot of it by an AI, prompted by someone just trying to make the bug report stop — and each layer was, on its own, a locally sensible patch.

Nobody was lazy. Nobody was stupid. The pile was built entirely out of reasonable responses to a problem no one had ever actually sat down and looked at. Two thousand lines of scar tissue grown over a splinter nobody had removed.

What was actually under it

I only started pulling the layers off because I was chasing that same cold ticket for the third time. And the way you come to understand code like that is you delete it — locally, one piece at a time — and watch what actually breaks versus what you were only afraid would break.

The retries came off. Nothing broke. The cache came off. Nothing broke — except now, with the cache gone, I could finally see the real behaviour instead of the smoothed-over version. And there it was, naked, the thing all two thousand lines had been built to hide:

The write path acknowledged the request before it had actually persisted the row.

It said saved! to the user — and to every layer stacked above it — the instant the request arrived, not the instant the data was durable. Ninety-nine times out of a hundred the row landed a few milliseconds later and no one noticed. But let a retry hit at the wrong moment, or the connection blip at the wrong moment, and the ack had already gone out the door. The user saw saved. The save never landed. Their work was gone, and the app had cheerfully told them it was fine.

That was the splinter. Ack-before-persist. Every retry, every cache, every reconciliation job was a layer of code added to survive a lie the system was telling at the very bottom. We had spent two thousand lines making the symptom quieter instead of spending twenty making the cause go away.

And it had hurt someone. Not hypothetically — there was a real user, months back, who had lost an evening of work to exactly this and sent a furious, and completely correct, message about it. We'd "fixed" it at the time by adding another layer. We hadn't fixed anything. We'd just buried the body deeper.

The fix was twenty lines

When I finally understood it, the actual fix was almost insultingly small. Move the acknowledgement to after the row is durably written. Let the write fail loudly if it fails. Then delete every single layer that existed only to cope with the fact that it used to lie.

Two thousand lines out. About twenty lines in. The PR did not add a feature. It removed the reason five features' worth of defensive code had to exist at all.

That red, featureless, two-thousand-line-deletion pull request was the best code I wrote all year. And for the two years before it, I would have been incapable of seeing that — because I'd been measuring myself, like most of us do, by the green. By lines added. By features shipped. By the size of the diff in the direction that feels like progress.

The part that isn't free anymore

Here's the reframe, and it's the whole point.

Adding code is free now. I don't mean cheap — I mean free. I can describe a feature to a machine and have four hundred plausible lines back before my coffee's cool. So can you. So could every person who added a layer to that write path. The part of the job that generates code got infinitely fast and infinitely tireless this year, and the proof is sitting right there in the pile: two thousand lines accrete a lot faster when adding them is nearly effortless.

But deleting a line is not free, and it never will be, because deletion is the one move you cannot make without actually understanding what the code does. To add the retry, you only had to believe it might help. To delete the retry, I had to know what it was holding up — what leaned on it, what would fall over without it, and what was only there out of fear. Addition runs on hope. Subtraction runs on understanding. That's the whole difference, and it's the entire reason one of them got free this year and the other one didn't.

Anyone can add a line. Deleting one means knowing what it was holding up. That's the part that was never free.

The machine wrote most of that pile in minutes. It took me three days to be sure which lines were safe to remove — and those three days, not the minutes, were the actual engineering. The gap between "I can generate this" and "I understand this well enough to take it away" is exactly the gap that stopped being automatable the moment generation stopped being hard.

To be clear — this is not "stop writing code"

I need to be fair here, because the lazy version of this post is "real engineers delete, juniors add," and that's garbage.

I am not anti-code. I add code all day. I let a machine write most of it, and I'd never go back — it's genuinely one of the best things to happen to this job. Adding is good. Features are the point. An app that only ever shrinks is a product dying on a schedule. Every one of those two thousand lines got written by someone trying, in good faith, to help a user, and most of the individual patches were reasonable the day they shipped. Writing code is not the problem and never was.

The point is narrower, and I think more useful: addition was never the scarce part, so getting faster at it didn't make me better — it just let me accumulate the expensive problem faster. The scarce thing — the only thing that turned that flaky write path from a two-year-old cold ticket into a solved problem — was the judgment to look at code that already existed and ask the question nobody adding a layer ever asks: does this need to exist, and what breaks if it doesn't? The machine made the output free and did absolutely nothing about that question. It can't. It generates confidently in whichever direction you point it — including straight onto the pile.

Why this is exactly how I build now

I build an agent platform now, and this one pull request is more or less the whole thesis of it.

The industry's reflex this year is to worship the author — the thing that generates. Look how much it ships! A whole feature from a sentence! But an author with no counterweight doesn't hand you a clean codebase. It hands you that write path: two thousand confident, plausible, locally-reasonable lines piled on top of a lie at the bottom, because generating the next layer was always easier than questioning the last one. I've watched it happen by hand. The author is how the pile gets built.

So the part I care about isn't the author — I already assume the author. Everyone has one now. What I'm hunting for is the skeptic and the human. The author writes the code, fast and free. The skeptic is the part that asks the question I didn't ask for two years — does this need to exist? what does it do under a retry? — and whose best possible output is often a giant red diff and nothing new. And the human is the one who owns the real person on the other end, the one whose evening of work quietly vanished, who can see the blast radius the model never will. Author, skeptic, human. That separation is the entire shape of xenition — and it's the same thing one deletion taught me the hard way: generating the thing is free and always will be; knowing what to take away, and what it costs the person on the other end if you're wrong, is the whole job, and the only part anyone ever actually pays for.

My best pull request last year added nothing and deleted two thousand lines. For two years I'd have called that a week with no output. It was the opposite. It was the week I finally did the part that wasn't free.

Next time you open a file you're afraid to touch, don't ask what you can add to make it better. Ask what's in there that nobody understands anymore — and what it might be quietly hiding.

I got rejected from 50 jobs. Then I deleted everything on my resume except one story — and the callbacks started.

Info Inlet — Sun, 01 Nov 2026 10:17:36 +0000

For about two months, the first thing I did every morning was refresh an inbox, looking for a word that wasn't there.

"Unfortunately." "We've decided to move forward with other candidates." "While your background is impressive." I could recite the rejection template from memory because I'd received roughly fifty versions of it. Some took three weeks. Some took an automated four minutes. A few never came at all, which is somehow the worst one.

And every time, I did the same thing: I opened my resume and made it more. Added the side project I'd shipped that weekend. Added a line for the framework I'd just learned. Bumped "familiar with" up to "proficient in." Reordered the skills so the hot one was first. Rewrote the summary at the top for the fourth time. The resume got denser and denser, a tighter and tighter brick of everything I had ever built.

Fifty applications. Roughly a dozen rewrites. Exactly zero callbacks.

And then, in a single week, it stopped being zero — not because I added a better project, a cleaner layout, or a stronger keyword. Because I deleted almost the entire thing and replaced it with one story. I want to tell you exactly what that story was, because it rewired how I think about my whole career, and it's the opposite of every "add more projects to your portfolio" post you've ever scrolled past.

The thing my resume actually was

Here's the uncomfortable reframe, and it took me fifty rejections to see it.

For two months, my resume was a list of output. "Built a full-stack app with X." "Shipped a feature that does Y." "Used these fourteen technologies." Every bullet was a real, true thing I had typed into existence. None of it was a lie. It was an honest, complete inventory of everything I had produced.

And output — the building, the shipping, the "I made a thing that exists" — is the part that got free. I was writing most of that code with an AI by then, spinning up a polished side project in a weekend. So was every other person applying to the same job. The hiring manager was looking at a stack of resumes that were all, functionally, the same wall of output, generated at roughly the same near-zero cost. Half of them were probably written by the same AI I was using.

A list of things you built is exactly as scarce as the ability to build them. Which is to say: not scarce at all anymore.

Because the thing standing between me and a callback was never another project. I kept treating the rejections as a volume problem — not enough shipped, not enough keywords, not enough proof-of-work — when it was never a volume problem at all. The hard part of hiring someone was never "can they produce code." It's "can I trust this person with the thing that can hurt us." I had compressed the easy part — making things exist — to almost nothing, and spent two months frantically doing more of it, while the part that actually gets people hired sat untouched at the top of the page in a summary nobody read.

I wasn't building a case for myself. I was building a very thorough inventory of a commodity.

The one thing I changed

I almost didn't send it. It felt insane. I cut the fourteen technologies down to a quiet line. I cut three of the four side projects. I cut the summary entirely. And in the space that opened up, I wrote about the single worst night of my short career.

Months earlier, on a tiny app a handful of real people actually used, I had shipped a bug. A write path that acknowledged the request before it had actually persisted the row. In my tests, in the demo, on my machine — flawless. It had been "flawless" for months precisely because no real weight had ever been on it.

Then one user leaned their weight on it. A retry hit at the wrong moment. The ack went out — saved! — and the save never landed. That person got locked out of their own account, with no record that they'd done the thing they'd just spent an evening doing. Ack-before-persist. Their work, gone, and the app cheerfully telling them it was fine.

The message came in late. It was furious, and it was right to be furious.

So on the resume, instead of a bullet that said "built and maintained a production web app," I wrote what actually happened: I found the bug, I understood why it was invisible for months, I fixed the write path so the acknowledgement could not possibly go out before the row was durably written, I recovered what data I could, and I replied to that person — not a templated apology, the real thing: here's what broke, here's why, here's exactly what I changed, here's what I could get back and what I couldn't.

One story. The one time something I built could hurt a real person, and what I did when it did.

Why one story beat fifty lists

The first recruiter who called opened with it. Not my stack. Not my projects. "Tell me more about the ack-before-persist thing."

Here's the line I wish someone had put in front of me on rejection number one:

A resume is a list of output. Output is free now. What gets hired is judgment — proof you can be trusted with the thing that can hurt them.

My fourteen technologies proved nothing, because fourteen technologies cost nothing to list and almost nothing to acquire. They couldn't lock a user out, lose someone's data, or get a 2am message. They were safe, which is exactly why they were worthless on the page — I was handing over proof I could do the free part, in a stack of resumes all proving the same free part.

The one story was the first thing on the page that showed I'd ever been in the room where something could go wrong on a real person — and that when it did, I didn't hide, didn't template, didn't ship away from it. That's not something you can generate. That's the one thing they were actually screening for the whole time, buried under everyone's identical wall of output.

That's the math nobody prints on the "build more projects" advice: fifty resumes full of output got me zero callbacks. One story about judgment got me the job.

To be clear — this is not "projects don't matter"

I need to be fair here, because the lazy version of this post is "stop building side projects," and that's wrong.

I am not telling you to stop building. Build constantly. Ship the side projects. Let an AI write most of the code — I do, it's the reason I could ship enough to have a worst night to write about. The projects are table stakes; you need them to get in the door at all. Building is fast and cheap and good, and you should do it.

What I'm saying is narrower and, I think, more useful: projects were never the bottleneck, so adding more of them was never going to move a number that was stuck for a completely different reason. The scarce thing — the only thing that was ever going to turn a rejection into a callback — was evidence of judgment: proof that I'd depended-on and been depended-on, broken something that mattered, and owned it. AI made the output free and did absolutely nothing about that. It can't. Nobody can generate your scar tissue for you.

So build. Build fast, with the machine. But know which part of your resume is the free part, and do not mistake fourteen lines of the free part for a case that you should be hired.

Why this is the exact reason I build the way I do now

Here's the part that goes one level up, because it's the same lesson wearing a different hat.

I build an agent platform now, and I read resumes and diffs from the other side of the table. The whole industry's reflex this year is to celebrate the author — the thing that generates. Look how much it ships! A whole app in a weekend, a resume in a prompt! But a wall of author output, with nothing checking it, tells me exactly what my fifty-rejection resume told those recruiters: that you can produce. I already assume you can produce. Everyone can produce now.

So when I read a candidate — or review a change — I'm not scanning for more output. I'm hunting for the skeptic and the human. The author is the part that writes the code, fast and tireless and free. The skeptic is the part that asks the question I didn't ask for months: what does this do if the write gets retried? And the human is the one who owns the 2am, who can see the blast radius the model can't. Author, skeptic, human. That separation is the entire shape of xenition — and it's the same thing fifty rejections taught me the hard way: generating the thing is free and always will be; being trustable with it when it can hurt someone is the whole job, and the only part anyone ever pays for.

My resume didn't get rejected fifty times because it was missing a project. It got rejected because it was all author and no skeptic, all output and no judgment, and nothing on it had ever been close enough to a real person to go wrong. The day one line finally was — and I'd stood in it — the number changed.

Put one thing on your resume that could have hurt someone. Then show them you stayed. That's where the callback is.

I made $0 from my side project for 8 months. Then one furious email at 2am changed everything.

Info Inlet — Sat, 31 Oct 2026 08:13:43 +0000

For eight months, the most-visited tab in my browser was a Stripe dashboard that said $0.00.

I'd open it first thing in the morning, the way other people check the weather. Refresh. $0.00. Refresh again, because maybe it hadn't loaded. $0.00. Then I'd close it, open my editor, and go do the thing I was sure would finally move that number: ship another feature.

I shipped a lot of features. Dark mode. A second onboarding flow because I didn't like the first. CSV export nobody asked for. A settings page with toggles for things that didn't need toggling. I posted on launch-day forums. I rewrote the landing page headline four times. I A/B tested a button color like the button color was the problem.

Eight months. Roughly thirty features. Exactly zero dollars.

And then, in a single week, it stopped being zero — not because of a feature, a growth hack, or a headline. Because of one furious email at 2am. I want to tell you exactly what that email changed, because it rewired how I think about building anything, and it's the opposite of every "just ship more" post you've ever scrolled past.

The thing I was actually doing for eight months

Here's the uncomfortable reframe, and it took me far too long to see it.

For eight months, I was producing output. A feature is output. A settings toggle is output. A fourth headline is output. Every one of those thirty things was a real, deployed, working piece of software that existed because I typed it into being.

And output — the typing, the scaffolding, the "make a thing that exists" — is the part that got free. I was writing most of that code with an AI by then, shipping faster than I ever had in my life. I could produce a polished feature in an afternoon. I was a one-person feature factory running at full tilt.

$0.00 is exactly what a feature factory running at full tilt is worth, if that's all it is.

Because the number on the dashboard was never waiting on another feature. I kept treating $0 as a production problem — not enough shipped, not polished enough, not enough toggles — when it was never a production problem at all. The hard part of a product was never the code, and it definitely isn't the code anymore. The hard part is a single stranger caring enough to depend on the thing, come back to it, and be genuinely hurt when it breaks. I had compressed the easy 20% — the building — to almost nothing, and spent eight months doing more and more of it, while the impossible 80% sat there untouched.

I wasn't building a business. I was building a very productive graveyard, one tombstone a week.

What the 2am email actually was

I had a free trial. A handful of people had started one over those months — I'd watch them poke around for ten minutes and vanish. Output going out, nobody depending on it. Fine. Zero.

Then one trial user did something none of the others had: they used it. For real. Put their actual work in it, came back the next day, and the day after. One stranger, finally leaning their weight on the thing I'd made.

And the thing I'd made had a bug I'd shipped months earlier and never noticed, because noticing it required someone to actually depend on it. I had a write path that acknowledged the request before it had actually persisted the row. In the demo, in my tests, on my machine — flawless. It had been "flawless" for eight months precisely because no real weight had ever been on it.

Then a retry hit at the wrong moment. The ack went out — saved! — and the save didn't land. This user got locked out of their own account, with no record that they'd ever done the thing they'd just spent an evening doing. Ack-before-persist. Their work, gone, and the app cheerfully telling them it was fine.

The email came in at 2am. It was furious, and it was right to be furious.

And I'll tell you the truth about how that felt, because it's the whole point of this post: it was the first time in eight months that anything I'd built had mattered enough to make someone angry. Thirty features, and not one of them had ever cost a real person a bad night. This one bug had. For the first time, there was a human on the other side of the glass who could be hurt by my mistake — and was.

What I did next was the only thing that ever moved the dashboard

I didn't ship a feature. I was awake anyway.

I found the bug — the ack-before-persist — fixed the write path so the acknowledgement could not possibly go out before the row was durably written, backfilled the data I could recover, and replied to the email. Not a templated apology. The actual explanation: here's what broke, here's why, here's exactly what I changed so it can't happen to you again, here's what I could recover and what I couldn't.

That user wrote back. Stayed. Converted when the trial ended. And — this is the part that still gets me — told two other people, both of whom became the first paying customers I ever got who weren't me testing my own Stripe integration.

The dashboard stopped saying $0.00.

Not because of a feature. Because for the first time I had done the one thing I'd avoided for eight months without even realizing I was avoiding it: I let a real stranger get close enough to hurt me, and then I stood in the consequence instead of shipping away from it.

Output vs. judgment — the distinction that was hiding in the whole thing

Here's the line I wish someone had put in front of me on month one:

Shipping a feature produces output. Shipping to a user who can hurt you produces judgment. Output is free now. Judgment is the entire game.

Thirty features risked nothing. Not one of them could churn, refund, rage-email me, or lock themselves out at 2am. They were safe, which is exactly why they were worthless — I was manufacturing output in a room where nothing could ever go wrong, and calling the $0 a mystery.

The bug was the first thing I ever built that could go wrong on a real person. And the fix — the staying, the reply, the standing-in-it — was the first time I made a judgment that cost me something. That single scar taught me more about my own product than the previous eight months of building combined. It also, not coincidentally, was the first thing that made anyone pay.

That's the math nobody prints on the "ship every week" poster: eight months of output that couldn't hurt me earned $0. One night of judgment that did earned the first real dollar.

To be clear — this is not "stop shipping"

I need to be fair here, because the lazy version of this post is "features are bad, slow down," and that's wrong.

I am not telling you to stop building. I ship constantly. I let an AI write most of my code and I would never go back — it's the reason I could produce thirty features in eight months, and I'm glad I can. Building is fast and cheap and good, and you should do it.

What I'm saying is narrower and, I think, more useful: features were never the bottleneck, so producing more of them was never going to move a number that was stuck for a completely different reason. The scarce thing — the only thing that was ever going to turn $0 into not-$0 — was a real person depending on the thing and me surviving the consequence when it broke. AI made the output free and did absolutely nothing about that. It can't. Nobody can generate another human's dependence on you for free.

So ship. Ship fast, with the machine, joyfully. But know which part is the free part, and do not mistake eight months of the free part for eight months of progress.

Why this is the exact reason I build the way I do now

Here's the part that goes one level up, because it's the same lesson wearing a different hat.

I build an agent platform now, and the whole industry's reflex this year is to celebrate the author — the thing that generates. Look how fast it ships! Thirty features in eight months, a whole app in an afternoon! But an author running at full throttle, with nothing checking it, produces exactly what I produced: infinite output, zero judgment, and a dashboard that says $0. My eight months were a one-person preview of what unchecked generation gets you.

So I never let the thing that writes the code be the thing that blesses it. There's an author that produces the diff — fast, tireless, free. There's a separate skeptic whose only job is to ask the question I never asked for eight months: what does this do if the write gets retried? And there's a human on the merge button who owns the 2am, who can see the blast radius the model can't. Author, skeptic, human. That separation is the entire shape of xenition — and it's the same thing the $0 dashboard taught me the hard way: generating the thing is free and always will be; deciding whether it survives contact with a real person is the whole job, and the only part anyone ever pays for.

My side project didn't make $0 because it was missing a feature. It made $0 because for eight months it was all author and no skeptic, all output and no judgment, and nothing in it could hurt me. The day one thing finally could — and I stood in it — the number changed.

Build one thing that can hurt you. Then stay for the 2am. That's where the dollar is.

6 Things AI Still Can't Do in 2027 — And Why They're Now the Only Skills That Pay

Info Inlet — Wed, 28 Oct 2026 11:48:45 +0000

For years the advice was simple: learn a language, learn a framework, build a few CRUD apps, get hired. In 2027 that advice is almost useless. AI writes the CRUD app. AI writes the boilerplate. AI writes the tests you were going to skip anyway.

So what's actually left for you? Here are the 6 skills that separate the developers who are thriving from the ones who are nervously refreshing job boards.

1. Problem framing (knowing what to build)

AI is great at answering questions. It's terrible at knowing which question matters. The hardest part of software was never typing — it was figuring out what the user actually needs versus what they said they want.

Why it matters: An AI will happily build the wrong thing beautifully. You are the one who decides it's the wrong thing.

How to get better: Before writing a single prompt or line of code, write one sentence: "This is done when ___." If you can't finish that sentence, you're not ready to build yet.

2. Reading code faster than you write it

In 2027 you generate more code than you can author by hand. That means your bottleneck shifts from writing to reviewing. The dev who can skim 400 lines of AI output and instantly spot the one sketchy auth check is worth 10x the one who just hits "accept."

How to get better: Read other people's PRs for fun. Review AI output line-by-line out loud. Treat "accept all" as a smell, not a workflow.

3. Debugging systems you didn't write

Most bugs in 2027 live in code no human fully remembers writing. Debugging is now archaeology: tracing behavior through layers of generated code, third-party services, and AI-authored glue.

Why it matters: This is the single skill AI is worst at, because real debugging needs context the model never had — the production logs, the weird customer, the thing that happened at 2am.

How to get better: Learn your observability tools cold. Logs, traces, metrics. Learn to bisect. Learn to reproduce before you fix.

4. Architecture and taste

AI gives you a thousand valid options. Taste is knowing which one won't become a nightmare in six months. Should this be a queue or a cron job? A new service or a function? AI can argue both sides — you have to decide and live with it.

How to get better: Study systems that lasted. Read postmortems. Ask "what breaks when this gets 100x bigger?" on everything you build.

5. Communication (with humans and with models)

Half your job is now written communication: clear specs, clear prompts, clear PR descriptions, clear async updates. Prompting is a communication skill — vague request in, vague result out. The clearest writer on the team is quietly becoming the most productive engineer.

How to get better: Write the ticket like the person reading it has zero context. Then prompt the model the same way.

6. Judgment about when NOT to use AI

The senior move in 2027 isn't using AI for everything — it's knowing the 10% where you shouldn't. Security-critical code. Anything touching money. Code where "mostly right" is a disaster. Knowing where the guardrails go is a skill, and it's rare.

How to get better: Keep a personal list of "I will always review this myself" categories. Auth, payments, data deletion, migrations. Grow the list every time something burns you.

What bootcamps are still teaching (and shouldn't over-index on)

Memorizing syntax → AI autocompletes it
Hand-writing boilerplate → generated in seconds
"Leetcode until you bleed" → still useful for fundamentals, oversold as the whole game
Framework-of-the-month → the meta-skill of learning any framework fast matters more

None of these are useless — fundamentals still matter. But they're table stakes now, not differentiators.

The one-line takeaway

In 2027, your value isn't that you can produce code. It's that you have the judgment to know what's worth producing, the eye to catch what's wrong, and the taste to keep it from rotting.

The tools got stronger. The thinking got more valuable. That's good news if you lean into it.

What skill do you think is most underrated for the next few years? Drop it in the comments 👇

AI wrote the first 90% of my app in an afternoon. The last 10% took three weeks.

Info Inlet — Tue, 27 Oct 2026 10:25:10 +0000

There's an old programmer's joke: the first 90% of the code takes 90% of the time, and the remaining 10% takes the other 90% of the time. I used to tell it as a joke.

Then I let AI write a whole SaaS — auth, Stripe billing, a dashboard, a public API — and the joke stopped being funny. Because AI made the first 90% genuinely instant. And the second 90% was still exactly where it had always been, waiting for me, untouched.

The demo worked in an afternoon. The product took three more weeks. This is a field report on the gap between those two things — the part no demo ever shows you.

The first 90% really is solved

Let me be fair to the machine, because the first part was astonishing.

"Set up a Next.js app with Postgres and Drizzle, auth, a billing flow, a dashboard, and a public API." It did it. Correctly. In close to one shot. The scaffolding, the CRUD, the Zod schemas, the table with sorting and pagination — the stuff I actively dislike writing — came out clean, first try, no notes. By the end of day one I had something I could click through and demo to a friend. It looked done.

That's the trap. It looked done because everything that's easy to build is also easy to show. The demo path is the happy path, and the happy path is the 90% that was never the hard part.

The rule: the speed you feel in the first afternoon is real — and it's measuring the wrong thing. "I can demo it" and "it's done" are separated by the entire job.

The last 10% isn't code. It's anticipation.

Here's what the remaining three weeks were actually made of. None of it showed up in the demo, because the demo was one well-behaved user doing exactly what I expected.

The empty state. Day one, the dashboard has no data. The AI rendered a table with headers and a blank void underneath — technically correct, and it makes a brand-new user think the product is broken. There's no "add your first client" nudge, because I never asked for one, because in my head the table always had data in it.
The error state. The checkout worked perfectly — with a card that approves. The first time a real card got declined, the button just… hung. No message, no retry, no path forward. The AI built the road and no guardrail, because I'd only ever described the road.
The double-click. A user on a slow connection clicked "Subscribe" twice. Two Stripe subscriptions, one customer. The happy path fires once; real humans mash buttons.
The race. Same record open in two tabs, both saved. Last write wins, the other silently gone. Fine in a demo where one person clicks one thing at a time.
The 2am weirdo. A session that expired overnight, a stale dashboard left open, one click in the morning → a 401 the UI had no idea what to do with → white screen. "Handles a user doing something weird at 2am" is a different product from "handles me, awake, clicking in order."
The public API with no armor. No rate limiting. No stable pagination. No idempotency key on the POST, so a retried request quietly created the thing twice. All the behaviors that aren't features — they're the absence of disasters.

Every one of these compiled. Every one passed the happy-path test. Not one of them was in the demo. This is the last 10%, and it's made almost entirely of things you only know to build because you've been burned by their absence.

The first 90% is construction. The last 10% is anticipation. AI is extraordinary at the first and has none of the second.

Why the AI can't close the gap

It's tempting to say "the model just isn't good enough yet." That's not what I found. The model built every single one of those fixes correctly the moment I described them. "Add an empty state." "Handle a declined card." "Debounce the submit." "Add an idempotency key." Done, done, done, done — perfectly.

The problem was never that it couldn't write the code. The problem is that it builds exactly what you describe, and the last 10% is precisely the stuff you don't think to describe. It has no scar tissue. It has never been woken at 2am by the empty state it forgot. So it will cheerfully hand you a demo and call it done, and it will be right that it's done — for the one user it imagined, who is always you, awake, behaving.

The rule: the AI closes the gap the instant you point at it. Knowing where to point is the whole job — and knowing where to point is just a list of every edge case that ever hurt you.

The uncomfortable part

So here's what actually happened to the shape of the work.

The first 90% — the part that felt like engineering, the typing, the construction, the thing that looks like progress on a screen share — collapsed to near zero. What's left is the part that never looked like much: sitting there cold, asking "what happens if they do this instead?" over and over until you've imagined every stupid, hostile, half-asleep thing a stranger will do to your software.

That part didn't get faster. If anything it got more exposed, because AI stripped away the busywork that used to disguise how much of the real job it always was. We told ourselves building software was mostly typing. It was mostly anticipating; the typing just took long enough to hide that.

And that's the senior skill. Not syntax. Not "knows the framework." The ability to look at a working demo and feel, in your gut, the nineteen ways it'll break in front of a real person. You don't get that from a model. You get it from having shipped the empty state that made someone think your product was broken, once, and never forgetting.

What I actually changed

I didn't stop using AI — I let it write 100% of the first 90%, and I'd never scaffold by hand again. I changed where I spend my attention, and how I define "done":

"Demo works" is the start of the work, not the end. The afternoon it clicks through is day one. I now budget the real schedule around the 10%, because that's the 90%.
I write the edge cases down before I build, not after they bite. Empty, error, loading, double-click, concurrent, expired, retried. It's a checklist now, because the model will never volunteer it and I will never remember all of it under pressure.
The thing that writes the code is never the thing that decides it's done. A separate reviewer, prompted to break the diff — "what does a hostile, half-asleep user do here?" — catches the missing states the author waves right past, because the author's mental model is the happy path by construction.

Author writes it, a skeptic tries to break it, a human owns the call on whether it's actually finished. That separation is the only reason I can hand the typing to a machine and still ship something that survives contact with a real user. It's also how we build Xenition — our AI workspace: describe the tool you want in plain language and it builds and deploys the working app, real database and real URL. The describing is instant now. The deciding-what-to-describe is still the job, and it always will be.

Would I do it again?

In a heartbeat. The first 90% in an afternoon is not a gimmick — it's the biggest change to how I build in a decade, and I'm never giving it back.

But I'd walk in knowing what the demo is lying about. "It works" means it works for the user you imagined. The last 10% is the work of imagining the ones you didn't — and that was always the whole job. AI just took away everything that used to hide it.

I Coded for 30 Days Using Only Claude Code — Here's What I Learned

Info Inlet — Mon, 26 Oct 2026 08:34:50 +0000

Not "AI-assisted." Not "copilot suggestions I edited." I made a rule: for 30 days I don't type application code. The AI does. My job is to describe, review, and approve.

I shipped a real product this way — a small SaaS with auth, Stripe billing, a dashboard, and a public API. It works. It's in production. And along the way I found out exactly where the "AI writes everything now" dream holds up and where it quietly falls apart.

This isn't a hype post and it isn't a doom post. It's a field report.

The rules

To keep myself honest:

I don't write application logic by hand. I prompt, the AI writes.
I can read every line, reject it, and ask again — but I can't fix it myself in the editor.
Config, secrets, and "click the button in the dashboard" steps are mine (the AI can't do those anyway).
If I get truly stuck for more than an hour, I log it as a "break" and write the code myself.

By the end I had 9 logged breaks. Those breaks are the interesting part.

What worked shockingly well

Let me be fair to the machine first, because a lot of this genuinely surprised me.

Greenfield scaffolding is basically solved. "Set up a Next.js app with Postgres, Drizzle, and auth" — done, correctly, in one shot. The first 40% of the project flew by faster than I've ever built anything.

Boilerplate it never gets wrong. CRUD endpoints, form validation, Zod schemas, a table with sorting and pagination. The stuff I hate writing, produced perfectly, every time, no notes.

It's a phenomenal rubber duck. "Why is this query slow?" got me a better answer than I'd have reasoned to alone — it spotted a missing index and an N+1 in the same breath.

For the first week I genuinely thought I'd write the "developers are obsolete" post. Then week two happened.

What broke — the 9 breaks, honestly

Break 1–3: It can't hold the whole system in its head

Brilliant at the file in front of it, blind to the one three folders over. It wrote a second formatCurrency helper because it didn't know the first existed. Re-implemented my auth check inline instead of the middleware I already had. Introduced a subtly different User type in a new module.

None of these are "bugs" — everything compiled, everything passed. They're architecture drift, and architecture drift is invisible until the day it costs you a week.

The AI optimizes locally. Coherence across a system is still a human job.

Break 4–5: It confidently writes plausible, wrong code

The scariest failures weren't crashes. They were code that looked right and ran fine on the happy path.

The billing webhook it wrote acknowledged Stripe events before persisting them. Flawless in testing. In production, one DB blip = a paying customer locked out, no record, no trail. I only caught it because I've been burned by exactly this before. A junior copying this output would not have caught it. That's the part that keeps me up.

Break 6: Debugging its own code is a hall of mirrors

When something broke that the AI couldn't see, asking it to fix it produced changes, not fixes. It would rewrite the function, swear the bug was gone, and reintroduce it two prompts later. Without dropping into the debugger myself to understand the real state, we'd have spun forever. Biggest time sink of the month.

Break 7–8: Taste, and saying "no, less"

Asked for a settings page, it gave me 14 options nobody wanted. Asked for error handling, it wrapped everything in try/catch and swallowed the errors. The AI's instinct is always to add. Knowing what to leave out — the product-design part of engineering — it has none.

Break 9: The last 10% is still 90% of the work

"Demo works" took a week. "Handles a real user doing something weird at 2am" took the other three. Edge cases, race conditions, the empty state, the error state, the double-click state — the AI does none of it unless you know to ask, and knowing to ask is the job.

The uncomfortable synthesis

AI didn't replace me. It replaced the *tasks I used to give juniors.* The scaffolding, the boilerplate, the first draft — the exact work a junior becomes a senior by doing. So if the AI does all the entry-level work, where does the next senior come from? You can't skip the 10,000 hours; you can only move where they're spent.

The skills that mattered every single day were senior ones: knowing the code was subtly wrong, knowing what not to build, holding the whole system in my head to catch the drift. AI didn't flatten the hierarchy — it made the top more valuable and sawed off the ladder to get there.

What I actually changed

I didn't stop using AI — I use it for 100% of the typing now and always will. I changed the guardrails, and every one maps to a break above:

The thing that writes the code is never the thing that reviews it. A separate reviewer, prompted to refute the diff, catches the plausible-but-wrong code the author always waves through.
Nothing merges without a human who can see the blast radius the model can't.
"It compiles and the tests pass" is the start of review, not the end — the model writes tests that agree with its own wrong mental model.

Author here, skeptic there, human on the merge button — that separation is the whole reason I could hand the typing to a machine and still sleep. It's also exactly how we build xenition: agents that do the work, a different agent that tries to tear it down, and a person who owns the decision.

Would I do it again?

For a prototype? In a heartbeat — I'd never scaffold by hand again. For production? AI for 100% of the typing and 0% of the thinking. The typing was never the hard part. It just felt like it was.

I Replaced My Whole SaaS Stack With One App I Described in a Sentence. Here's What Happened.

Info Inlet — Sun, 25 Oct 2026 06:21:51 +0000

For two years my business ran on four tools. Notion for notes and docs. Airtable for the client database. Zapier to move data between them. Typeform for the intake form on my site. Each one was the best at its job. Together they cost about $90 a month, and I'd have told you, proudly, that I'd built a "stack."

Last month I replaced all four with a single app I described in one sentence. I lost a few things I genuinely miss. But I gained the one thing none of those four tools could give me, and I didn't understand what it was until it was gone.

The subscriptions were never the real cost

When people complain about SaaS, they complain about the bill. That was never my problem — $90 a month is cheap for software that runs a business. The real cost was somewhere I never looked: the glue.

Notion didn't talk to Airtable. Airtable didn't talk to the form. So between every pair of tools sat a Zap — a little automation I'd wired up at some point, that moved a row here when a thing happened there. By the end there were eleven of them. And here's the part that should have scared me more than it did: my actual business process didn't live in any of the four tools. It lived in the glue between them. The Zaps were the company. And nobody, including me, could see them all at once.

The rule: a stack isn't four tools. It's four tools plus the invisible logic connecting them — and that connective tissue is where your real process lives, unversioned, undocumented, and understood by exactly one person.

The day the glue broke silently

Here's what happened, and it's the whole reason I'm writing this.

One of my eleven Zaps stopped firing. Not with an error — Zapier emailed me nothing, because from its point of view nothing failed. A field I'd renamed in Typeform no longer matched the field the Zap was looking for, so it just... quietly did nothing. New leads came in through the form, landed in a void, and never made it to the Airtable database I actually looked at every morning.

I found out three weeks later, when a client emailed to ask why I'd never followed up on her enquiry. There were nineteen more behind her.

That's the failure mode of a stack. It doesn't crash. It leaks. And it leaks in the seams between tools, which is precisely the place no single tool is responsible for watching.

The rule: every tool in your stack is reliable on its own. The risk isn't in the tools — it's in the gaps between them, and the more tools you add, the more gaps you're quietly betting your business on.

What I actually replaced it with

So I did something that two years ago would have sounded absurd. I described the whole thing in a sentence — "an intake form clients fill out, that drops them into a database I can see and sort, with a dashboard showing this week's new enquiries" — and had a working app built and deployed from that description. One thing. One place. The form, the database, and the dashboard were no longer three products with glue between them; they were one app where the data never had to cross a border.

The eleven Zaps didn't get migrated. They stopped existing. There was no "between" left for them to live in.

The rule: the fix for fragile glue isn't better glue. It's removing the seams — when the form and the database are the same app, there's no automation to silently break, because nothing has to be moved from one place to another.

Be honest about what I lost

I'm not going to pretend this was free. A stack of best-in-class tools gives you things a single purpose-built app doesn't, and if I skip that part you should stop trusting me.

Notion's editor is still better than anything I'd describe into existence. For long-form writing, I still open Notion. I didn't replace that; I replaced the part of it that was pretending to be a database.
I lost the ecosystem. Templates, integrations, the Zapier library of 6,000 apps — when you leave the stack, you leave all of that. If I need to connect to some third-party service tomorrow, I have to build that, not click it.
The community and the muscle memory are real. Two years of knowing exactly where everything is in Airtable is worth something, and I threw it away on purpose.

So this isn't "SaaS is dead, delete your subscriptions." It's narrower and truer than that: a general-purpose tool bends your work to fit a shape built for everyone. That's a fair trade when you're starting and don't know the shape yet. It stops being fair the day you know exactly what your process is — because then you're paying, in glue and in leaks, to keep using a tool that was never built for you.

The thing I actually gained

Here's what I couldn't see until the stack was gone. For two years I'd been bending my business to fit my tools — structuring the client data the way Airtable wanted, shaping my intake around what Typeform could ask, routing everything through what Zapier could connect. I thought I was building a process. I was mostly negotiating with four products.

The app I described does exactly what my business does and nothing else. There's no field I'm not using, no feature I'm working around, no seam for a lead to fall through. When my process changes, I change the app — in another sentence — instead of re-wiring five automations and praying the glue holds.

The rule: a stack is a pile of tools built for everyone. An app is one tool built for you. For a long time you can't tell the difference, because the stack works — right up until the day the glue leaks and you realize you never actually owned your own process.

How I'd think about it if you're running a stack right now

I'm not telling you to burn it down this afternoon. I'm telling you to go find your glue.

Count your automations. If you have more than a handful of Zaps / Make scenarios / scripts holding your tools together, that count is your real complexity. Not the number of tools — the number of seams.
Ask where a lead could leak. For each seam, ask what happens if it silently stops. If the answer is "I wouldn't find out for weeks," you've found the thing that's actually at risk.
Notice where you've bent to the tool. Any place you've shaped your work around what the software can do, rather than the other way around, is a candidate for replacement — not because the tool is bad, but because it was built for someone who isn't you.
Replace a seam, not everything. You don't have to leave the whole stack. Collapse the two tools with the ugliest glue between them into one app first. That's where the leak was anyway.

The tool I built this on is Xenition — our AI workspace, a Flutter app on iOS and Android. I describe the tool I want in plain language and it builds and deploys the working app, real database and a real URL, no stack to wire together. It didn't make me more organized; I was plenty organized. It removed the seams where "organized" used to leak.

Two years of stack ran my business and lost me twenty leads in a gap I couldn't see. The one app I described in a sentence has never had a gap to lose them in — because there's no between left.

What's the silliest thing your stack's glue ever broke, and how long did it take you to notice? I'll go first in the comments. 👇

I Shipped 12 Apps in a Year. Only One Mattered — and It Wasn't the Good One.

Info Inlet — Sat, 24 Oct 2026 06:05:16 +0000

I shipped twelve apps last year. I can tell you, instantly, which one I'm proudest of — clean architecture, actual tests, a Lighthouse score I'd put on a business card. And I can tell you which one actually changed my career. They are not the same app. They're not even in the same postcode.

The good one did nothing for me. The one that mattered had a bug in production on day two. For a long time I had that exactly backwards, and it cost me most of a year.

Quality is something you control. Mattering is something a user does to you.

Here's the thing nobody tells you when you're grinding through your "build projects" phase: those are two completely different variables, and you can max out the first one while scoring zero on the second.

The app I was proudest of was a project management tool. I architected it properly. I wrote the tests first. The commit history reads like a textbook. And it was used by exactly one person — me — who already knew exactly how it worked and would never, ever do anything it didn't expect. It was a beautiful, sealed terrarium. Nothing could get in to break it, which is another way of saying nothing real ever touched it.

The app that mattered was a scheduling tool I threw together for a friend who runs a small studio. It was ugly. No tests. I'm fairly sure the state management was a crime. But a real person opened it every morning, did things I never planned for, and when it fell over — and it did — I was the one who had to fix it before her day started.

The rule: a polished app with no users is a demo. A rough app with one real user is a product. The gap between those two words is the entire thing employers, clients, and your own skills are actually measuring — and you cannot cross it by polishing harder.

The "good one" was good because I controlled all the variables

That's the trap, and it's a comfortable one. When you build the thing only you use, you are both the developer and the entire user base, so of course it never breaks. You've quietly removed the one force that produces learning: a stranger doing something you didn't imagine.

I thought I was leveling up by making cleaner and cleaner versions of apps nobody used. I was really just getting better at building terrariums. More tests, more structure, more polish — all of it defending against a reality I had carefully kept out of the room.

The rule: if you're the only user, you're not testing your code — you're testing your own assumptions, and they always pass. Real usage is the only thing that disagrees with you, and disagreement is where every real skill comes from.

I couldn't tell in advance which one would matter

Here's the part that stings, because it kills the clean narrative. I did not ship the scheduling tool because I knew it would be the one. I shipped it because it was Tuesday and my friend needed it. If you'd lined up all twelve in advance and asked me to bet on which would change my career, I'd have pointed at the pretty one. I'd have been wrong.

You cannot predict the app that matters. The factors that make it matter — a real person, a real need, a real failure — live entirely outside your editor. All you can control is how many times reality gets to take a shot.

The rule: you don't find the app that matters by thinking harder about which one to build. You find it by shipping more of them, faster, and letting real users pick. Throughput beats prediction, because the thing that makes an app matter isn't in your hands — it's in theirs.

That reframes the whole game. The goal in year one isn't one perfect app. It's twelve live apps and one real user each, so reality has twelve chances to hand you the thing you can't manufacture: a war story, a client, a reference, a bug that taught you more than any course.

So the only real bottleneck is the gap between idea and live URL

If throughput is the strategy, then the thing slowing you down isn't your code quality — it's everything between "I have an idea for a tool" and "a real person can open it." The scaffolding. The auth. The database. The deploy. The hours of plumbing you've written fifty times that stand between you and the only part that teaches you anything: a stranger using it and breaking it.

That gap is exactly why I started building with Xenition — our AI workspace, a Flutter app on iOS and Android. I describe the tool I want in plain language — "a booking tool for a studio, owner can see the day, clients can request a slot" — and it builds and deploys the working app, real database and a real URL, in the time it used to take me to set up the repo. The learning is still all mine: the stranger still breaks it, and I'm still the one who gets up and fixes it. But the week I used to lose to plumbing before anyone could even touch it is gone. More shots on goal, same me.

The rule: the faster you can turn an idea into a thing a real person can break, the faster reality can hand you the one app that matters. Shorten that gap and you're not a better coder yet — but you're giving yourself far more chances to become one.

If you're shipping your terrariums right now

Stop optimizing the apps nobody uses. One more test on a project with zero users is a rounding error.

Ship for one real person, not for your portfolio. Your friend's bookings, your own invoices, the spreadsheet your team is drowning in. One real user outranks a hundred GitHub stars.
Get it live embarrassingly early. A rough live URL beats a flawless local repo, because only the live one can break on a stranger.
Ship more of them than feels reasonable. You can't pick the winner, so buy more tickets. Twelve live apps, one user each, beats one perfect app with none.
Keep what breaks. Every "it fell over and I fixed it" is worth more than your entire skills list — and you only get those from the ugly one that mattered.

The app I was proudest of is still the best code I wrote that year. It also did nothing for me. The one that changed everything had a race condition and a single user who kept showing up. If I'd known that in January, I'd have shipped the ugly ones faster.

What's the roughest thing you ever shipped that ended up mattering more than your polished stuff? I'll go first in the comments. 👇

How I Built a $0 Blog That Gets 100k Views

Info Inlet — Wed, 21 Oct 2026 10:05:06 +0000

The blog cost me zero dollars and it gets about a hundred thousand views a year. Both of those are true, and the gap between them is the whole story — because the free part took an afternoon, and the views took a year.

I'm writing this because every "build a blog" post sells you the afternoon. The stack. The deploy. The green checkmark. And the stack genuinely is free now, in a way it wasn't five years ago — I'll give you the exact one I run, link by link, and none of it will cost you a cent. But if you stop reading there, you'll do what I did the first three times: stand up a beautiful empty blog, publish twice, and watch it get forty views, thirty of them your own.

So this is in two halves. The stack that costs nothing. Then the thing that actually bought the traffic, which also costs nothing and is much harder to spend.

The $0 stack, link by link

Here's what's running this blog right now. Every line is a free tier I'm actually on, not a trial.

Hosting — Cloudflare Pages. Static sites, unlimited bandwidth, a global CDN, deploy on git push. The free tier isn't a teaser — it's unlimited requests and bandwidth, with a cap on builds per month you will not hit as one person. GitHub Pages does the same job if you'd rather; I moved for the faster edge and the branch previews.

The site itself — Astro. It builds to plain static HTML, so it's fast by default and there's no server to pay for or patch. I write posts in Markdown, Astro turns them into pages. If you prefer, Hugo and Eleventy land in the same place for the same price: $0.

Comments — giscus. Comments backed by GitHub Discussions. No database, no Disqus ads, no monthly bill — it stores the threads in your own repo's Discussions. Your readers sign in with GitHub, which for a dev audience is a feature, not a wall.

Newsletter — Buttondown's free tier. The free plan covers you until you have a few hundred subscribers, which is further away than you think on day one. The point isn't the tool. The point is that an email list is the only audience you actually own — every other number on this list is rented from a platform that can change its algorithm on a Tuesday.

Analytics — Cloudflare Web Analytics. Free, no cookies, no banner, doesn't sell your readers. It tells you the one thing that matters — which posts people actually land on — without you becoming the thing you'd unfollow.

Search — Pagefind. A full-text search index that's generated at build time and runs entirely in the browser. Static, free, and it makes a big archive feel like a real site instead of a pile of posts.

Fonts — Fontsource. Self-hosted open-source fonts, so no third-party font request slowing the first paint and no tracking. Pennies of bandwidth, which on Cloudflare is still zero.

Images — my own screenshots, plus Unsplash and Pexels for the occasional header. Both have genuinely free tiers; credit the photographer and you're done.

Total: $0.

The one honest asterisk: a custom domain costs about ten to fifteen dollars a year, and that's the only line item in the entire operation. You can skip even that and ship on the free *.pages.dev subdomain — it ranks fine, it just looks less like yours. I pay for the domain because it's the one cost I'd defend to anyone; it's the address the whole thing is built on, and it's mine no matter which host I'm on this year.

That's the afternoon. If a free stack was the thing standing between you and a hundred thousand views, you'd be done now. It isn't, and you're not, and here's the part that matters.

The views were never in the stack

I had this exact stack live, polished, fast, for most of a year before it got meaningful traffic. The theme was better than the writing. I'd spent my building energy on the Lighthouse score and almost none on the thing the Lighthouse score was supposed to deliver — somebody reading.

Three things turned it around, and not one of them is a tool.

1. I wrote for a question, not for myself. My early posts were "thoughts on" — thoughts on testing, thoughts on a framework. Nobody searches "thoughts on." They search "how do I fix CERTIFICATE_VERIFY_FAILED in Python," and if you've written the clear answer to a question real people type into a search bar, that post works for you at 3am for years. The posts that make up most of my hundred thousand views are four or five of these. They didn't go viral. They just answer a thing, and people keep needing the thing answered.

2. I stopped waiting for readers to find my site and went to where they already were. This is the lever almost nobody pulls, so here it is plainly: cross-post every piece to dev.to, Hashnode, and Medium — with a canonical URL pointing back to your own site. The canonical tag is the whole trick. It tells Google "the original lives over here," so you borrow those platforms' enormous built-in audiences without getting penalised for duplicate content, and the SEO credit still accrues to your domain. dev.to has a canonical_url frontmatter field. Hashnode has a canonical setting per post. Medium lets you import with the original as canonical. One piece, written once, now lives on four doorsteps instead of one empty room.

3. I accepted that the spike is luck and the baseline is work. Yes, one post hit the dev.to front page and another got a few hours on Hacker News, and those days were a rush. But a spike is a day. Search traffic and an email list are every day. If you build your strategy around going viral you've built it around a lottery ticket; if you build it around answering real questions and owning your list, the spike becomes a nice bonus on top of a number that doesn't reset to zero on Monday.

None of those three cost money. They cost the one thing a free tier can't provision for you: a post a week, for a year, when nobody is reading yet.

The part that actually breaks you

Here's what I didn't understand until I'd lived it: the blog was never the bottleneck. Consistency was. And consistency doesn't die because writing a post is hard — it dies in the second hour, the one after you finish writing, when the real job turns out to be turning that one post into the five places it needs to live.

Because "cross-post everywhere" is easy to say and quietly brutal to do. The same idea has to become a dev.to article with the right tags, a Medium version with the canonical set, a couple of posts for X that don't read like a press release, maybe a short script if you're doing video. That's not writing. That's an hour of reformatting the thing you already wrote, every single time, and it's exactly where my weekly cadence went to die. I'd write the post, feel finished, and never do the distribution that was the entire reason the post would be read.

That second hour is the gap we built Xenition to close — our AI workspace, a Flutter app on iOS and Android. You hand it the piece you wrote and describe where it's going — "a dev.to version with these tags, a Medium version pointing back here as canonical, three posts for X, and a short script" — and it drafts each surface in the right shape, so the distribution is a conversation instead of the chore that quietly ends your blog. The writing is still yours. The hour that used to kill the cadence isn't.

That's the honest shape of a $0 blog that gets 100k views. The stack is free and it's the easy afternoon. The traffic is also free and it's a year of showing up, most of it in the unglamorous work of putting one good post everywhere a reader already stands.

Build the free stack this afternoon — it really is that quick now. Then write the first post for a question somebody is actually typing, cross-post it with the canonical set, and do that again next week. The views don't come from the stack. They come from the week after you stopped expecting them to.

What's your $0 (or nearly $0) blogging stack — and the one tool you'd actually pay for? Drop it in the comments; I'm always looking to cut the last line item.

How I landed a dev job with no degree

Info Inlet — Tue, 20 Oct 2026 10:32:45 +0000

I don't have a computer science degree. I have a job writing software, and I've had one for a while now. For about a year before that, I did almost everything you're "supposed" to do to make up for the missing degree — and I want to tell you that it worked, because then this would be a nicer story. It didn't. The things I did to compensate for not having a degree were a dead end, and the thing that actually got me hired had nothing to do with the degree at all.

Here's the part that took me far too long to understand: a degree is not the thing employers want. It's a stand-in for the thing they want. And I spent months building a worse stand-in instead of just handing them the real thing.

What I thought "no degree" meant (and what it actually meant)

When you don't have the degree, the whole world tells you the same thing: you have a gap, so go fill it. So I did. I collected certificates — the free ones, then the ones with a logo people recognize. I started a LeetCode streak because a forum told me that's how you prove you're "rigorous" like the CS grads. I enrolled in enough of a bootcamp to get a bootcamp line on my résumé.

Every one of those was me trying to build a replacement credential. A thing I could point at and say: see, I'm as legitimate as the degree. I was playing the degree's game, just with cheaper pieces.

And it got me nothing. Not one interview traced back to a certificate. Not one interviewer asked about my LeetCode. The bootcamp line never came up in a room where someone decided whether to hire me. I had spent months manufacturing proof of the wrong thing.

The rule: when you don't have the credential, the instinct is to build a substitute credential. That's the trap. A certificate is a weaker copy of a degree, and nobody was ever going to want your weaker copy of the thing they already don't fully trust.

The question the degree is actually answering

Here's the reframe that changed everything, and it's the whole article, so I'll say it plainly.

When an employer sees a CS degree on a résumé, they are not thinking "ah, four years of theory." They're a human being trying to de-risk a hire, and the degree answers exactly one question for them:

"Will this person take something hard and ambiguous, with no syllabus and no answer key, and actually finish it?"

That's it. That's what the degree buys. Four years of someone being handed vague, difficult problems and grinding them to completion whether they felt like it or not. The employer doesn't care about the compiler-theory exam. They care that you've got a track record of finishing ambiguous hard things, because that's the entire job, and hiring someone who can't do that is expensive.

The degree is a proxy for finish-ability. A decent one — which is why it works as a filter. But it's a proxy. And once I saw that, the move was obvious and it was not "get a better proxy."

The rule: you cannot out-credential a degree. You will always lose that fight. So don't have it. Skip the proxy entirely and hand them the thing the proxy only gestures at — direct, checkable evidence that you finish hard things nobody scoped for you.

A certificate is also a proxy for finish-ability — a much weaker one, because everyone knows a course is scoped so you can't fail. That's precisely why it carries no weight. I'd been trying to beat a strong proxy with a weak proxy. The answer was to stop competing on proxies and show up with the real signal.

What the real signal looks like

The real signal is embarrassingly simple to describe and genuinely hard to fake: something you built that a stranger uses and that broke on you and that you kept running anyway.

That sentence has three load-bearing parts, and a tutorial project has none of them:

A stranger uses it. Not you, not the instructor's spec — a person who does things you didn't plan for. A course project can't have this; the scope is fixed so you always win.
It broke. Real usage produces real failure. The todo app from a tutorial never breaks, because nobody's hammering it at 9pm on a Saturday with input you didn't imagine.
You kept it running. This is the finish. Not "I built it," which is the fun part, but "it fell over and I was the one who had to get up and fix it with no next-lesson button." That is the exact thing the degree was vouching for.

When you have that, the degree question doesn't just get answered — it stops being asked. Which brings me to the room.

The moment it actually stopped mattering

I'll give you the specific interview, because it's where the abstract thing became real.

Interviewer looks at my résumé, no degree line, and asks the question you're dreading — some polite version of "so, no formal background?" The old me would have gone into defense: listed the certs, mentioned the bootcamp, talked about how much I'd studied. Defending the weak proxy. It reads as exactly what it is — an apology.

Instead I said: "Right — let me tell you about the booking tool I built for a small business. It double-booked two real customers on a Saturday because of a race condition in my code, the owner called me, and I found it and fixed it that morning before they reopened." And I watched the question evaporate. We spent the next twenty minutes on the race condition. Nobody came back to the degree, because I'd just answered the only thing the degree was ever a proxy for, with a story that was checkable and specifically mine.

The rule: you don't win the "no degree" conversation by defending the gap. You make the gap irrelevant by answering — before they can even finish asking — the one question the degree was standing in for. A real war story closes that door in a sentence. A certificate reopens it.

The difference between "I studied this" and "this happened to me and I handled it" is the difference between a proxy and the real thing. One of them is a vibe. The other is checkable, and in the room, checkable wins.

The uncomfortable part: how I shipped enough real things in time

Here's the bit that stings, and I'd rather say it straight. You cannot produce that signal from reading. The signal only exists on the other side of shipped and used, and you need more than one, and you don't have four years. There's a brutal chicken-and-egg here: the evidence that gets you the job can only be made by doing the job, and nobody's employing you to do it yet.

The only way I got through it was to stop treating "build the app" and "understand the app" as the same task. I'd get something live as fast as I possibly could — real database, real URL, a real person able to hit it — and then go back and read it, break it on purpose, and rebuild the parts I didn't understand. Backwards from how courses teach it. It's also the only order that produces a real user, because a thing that's live is a thing that can break on you, and a thing that breaks on you is the only thing that generates a war story.

The rule: a deployed app with one real user teaches you more in a week than a tutorial does in a month — because the user does the thing you swore nobody would do, and now it's your problem with no answer key. That problem is the curriculum, and it hands you the exact fundamentals you need in the exact order you need them.

I learned more real fundamentals debugging that live booking race than in every course combined. The point was never "don't learn." The point is that the live app was the learning, and it also happened to be the evidence. One activity, both outputs.

If you're where I was

You don't need my exact path and you definitely don't need my mistakes. Stop manufacturing proof of the wrong thing and start manufacturing the right one:

Quit collecting proxies. One more certificate will not move the needle. You are not trying to look as legitimate as a grad; you're trying to make legitimacy irrelevant.
Pick something one real person actually needs. Not a clone. Your cousin's bookings, your own invoices, the spreadsheet your team is drowning in. Small and real beats big and fake, every time.
Ship it before it's good. A live URL with one user beats a flawless repo with none. Deploy embarrassingly early — the point is to get it into the hands that will break it.
Then go understand what you shipped. Break it on purpose. Read your own code like a stranger wrote it. That's where fundamentals finally stick and where the war stories come from.
Keep the war stories. Every "it broke and I fixed it" is a sentence that answers the degree question and out-performs your entire skills list in the room.

The degree gets people past some automated filters, and I won't pretend it doesn't — I got rejected by plenty of them. But filters aren't where you get hired. You get hired in the room, by a human de-risking a decision, and in that room the only thing that moves is evidence you can take something ambiguous, make it real, and keep it running when it breaks.

The rule: the fastest way to look like a senior while you're still a junior — and the fastest way to make "no degree" a non-event — is to have already shipped something that survived contact with a real user. You can't fake that. And you don't need a degree to have it.

20 Free APIs You Didn't Know Existed (Bookmark This)

Info Inlet — Mon, 19 Oct 2026 10:05:27 +0000

Most of the backend code I've deleted this year wasn't deleted because it was bad. It was deleted because the thing it did was already a free API, and I just didn't know.

That's the quiet tax on building alone: not the stuff that's hard, but the stuff that's solved — solved by someone who put it behind a public URL and a free tier, and never crossed your feed. You write a currency-conversion endpoint. You scrape a weather site. You build a little service to turn a postal code into a city, and you maintain it forever, because you never found out that five people already did and gave it away.

So here are twenty I actually reach for. Not the famous ones everybody lists — not Stripe, not OpenWeather, not the GitHub API you already know. The ones that quietly save you an afternoon and a server. I've grouped them by the problem they solve, put a real example call next to each, and — because the one thing worse than not knowing an API exists is getting burned by its fine print — I've been honest about which ones need a key, which rate-limit you, and which ask for attribution.

A fair warning up front: "free" has edges. A free tier is a gift, not a guarantee. Several of these are run by one person or a small nonprofit, and the fastest way to kill a free API is to hammer it like it's yours. Read the one-line caveat next to each before you put it in production. With that said:

Data you'd otherwise pay for, scrape, or maintain forever

1. Open-Meteo — weather, with no API key at all.
The one that feels illegal. Full forecast, historical, and air-quality data, no sign-up, no key, free for non-commercial use.

GET https://api.open-meteo.com/v1/forecast?latitude=23.81&longitude=90.41&current=temperature_2m

That's the whole integration. No dashboard, no billing page, no "your trial ends in 14 days."

2. REST Countries — every country, one call.
Flags, capitals, currencies, calling codes, languages, borders, population. Every dropdown of countries you've ever hand-typed could have been this. Free, no key.

GET https://restcountries.com/v3.1/name/bangladesh

3. Frankfurter — currency exchange rates from the European Central Bank.
Open-source, no key, backed by official ECB reference rates. If you've been paying a FX API for a side project, stop.

GET https://api.frankfurter.app/latest?from=USD&to=BDT,EUR

Caveat: ECB publishes once per working day, so this is daily rates, not live tick-by-tick. Perfect for 95% of apps; wrong for an actual trading desk.

4. Nager.Date — public holidays for any country, any year.
"Is next Tuesday a holiday in Germany?" is a shockingly annoying thing to compute, and this answers it for free, no key, for most of the world.

GET https://date.nager.at/api/v3/PublicHolidays/2026/BD

5. Open Library — book metadata by ISBN.
Covers, titles, authors, publish dates, from the Internet Archive. If you're building anything with books, this is your catalogue. Free, no key.

GET https://openlibrary.org/isbn/9780140328721.json

Location & identity, without the geo-SaaS bill

6. Nominatim (OpenStreetMap) — free geocoding, both directions.
Address → coordinates and back. The thing every maps SDK charges you for after a few thousand calls.

GET https://nominatim.openstreetmap.org/search?q=Dhaka&format=json

Caveat — and this one's load-bearing: Nominatim's public server is max 1 request/second, requires a real User-Agent, and asks for attribution. It's run for the community, not for your bulk job. Respect it or self-host; abuse it and you're blocked, fairly.

7. Zippopotam.us — postal code to place, 60+ countries.
Postal/ZIP code in, city + state + coordinates out. No key.

GET https://api.zippopotam.us/BD/1207

8. ip-api.com — IP geolocation with no key.
Country, region, city, ISP, lat/long from an IP. Free for non-commercial use at 45 requests/minute, no sign-up.

GET http://ip-api.com/json/8.8.8.8

Caveat: the free endpoint is HTTP and non-commercial only; HTTPS and commercial use are the paid tier. Fine for internal tooling and demos, read the terms before it ships to paying users.

9. Sunrise-Sunset — solar times for any coordinate.
Sunrise, sunset, dawn, dusk, solar noon, day length. For anything that should behave differently at night, this beats guessing. Free, no key.

GET https://api.sunrise-sunset.org/json?lat=23.81&lng=90.41

Content, media & metadata

10. Free Dictionary API — definitions, phonetics, audio.
dictionaryapi.dev. Definitions, parts of speech, example sentences, even pronunciation audio. No key, no cost.

GET https://api.dictionaryapi.dev/api/v2/entries/en/serendipity

11. Wikipedia REST API — clean article summaries.
Skip scraping Wikipedia. There's a real API that hands you a clean summary, thumbnail, and extract for any title. Free; just attribute.

GET https://en.wikipedia.org/api/rest_v1/page/summary/Dhaka

12. Unsplash & Pexels — genuinely free stock photos, programmatically.
Both have real APIs with generous free tiers (Unsplash: 50 requests/hour on the demo tier; Pexels: 200/hour). High-quality images for placeholders, hero sections, or user-facing search — without a stock-photo invoice.

GET https://api.pexels.com/v1/search?query=mountains   (header: Authorization: <key>)

Caveat: both need a free API key and ask you to credit the photographer. Unsplash's demo tier is for building; you apply for production limits.

13. goQR (api.qrserver.com) — QR codes from a URL.
No SDK, no npm package, no key. The image is the endpoint — drop it straight into an <img src>.

https://api.qrserver.com/v1/create-qr-code/?size=300x300&data=https://xenition.com

14. Microlink — turn any URL into a rich preview.
Give it a link, get back the title, description, OG image, logo — even a screenshot. This is how you build link previews without writing a single scraper.

GET https://api.microlink.io/?url=https://dev.to

Caveat: the keyless free tier is rate-limited (around 50 requests/day). Enough to prototype; you sign up for more.

Dev plumbing — prototyping, testing & demos

15. JSONPlaceholder — a fake REST API that's always up.
Posts, comments, users, to-dos — real-shaped JSON for wiring up a frontend before the backend exists. The localhost:3001 mock server you keep rebuilding, already hosted. Free, no key.

GET https://jsonplaceholder.typicode.com/posts/1

16. Hacker News API — the whole site, as JSON.
Stories, comments, users, live updates, straight from Firebase. No key. Great for building a reader, a dashboard, or just a realistic data source with actual text in it.

GET https://hacker-news.firebaseio.com/v0/topstories.json

17. Open Food Facts — product data by barcode.
Scan a barcode, get ingredients, nutrition, allergens, images. A community food database the size of a commercial one, free and open, no key.

GET https://world.openfoodfacts.org/api/v2/product/737628064502.json

18. CoinGecko — crypto prices without an account.
Prices, market caps, historical charts for thousands of coins. The free "demo" tier works with no key for basic calls.

GET https://api.coingecko.com/api/v3/simple/price?ids=bitcoin&vs_currencies=usd

Caveat: the keyless path is rate-limited (roughly 30 calls/minute) and CoinGecko has been tightening it — grab a free demo key if you're doing anything real.

19. Agify / Genderize / Nationalize — predict age, gender, nationality from a name.
Three sibling APIs, same team. Feed in "Michael," get back a predicted age, likely gender, or probable countries. The best "wow, it guessed" demo you can build in one fetch. Free up to 100 names/day, no key.

GET https://api.agify.io?name=michael

A real caveat worth saying out loud: these are statistical guesses from name datasets. Fun for a demo, genuinely risky if you use them to make decisions about real people. Don't gate anything that matters on them.

20. Numbers API & Advice Slip — the fun that fills a demo.
numbersapi.com gives you a trivia fact about any number; Advice Slip hands you a random piece of advice. Neither needs a key. When you need something in the empty state of a prototype that isn't lorem ipsum, these are it.

GET http://numbersapi.com/42
GET https://api.adviceslip.com/advice

The thing the list doesn't tell you

Here's the part nobody puts in these roundups, and it's the whole game: knowing the API exists was never the bottleneck. You can bookmark all twenty and still ship nothing. The gap between "oh neat, a free weather API" and a working feature is reading the docs, matching the auth, shaping the response into your UI, and handling the call that fails at 2am — and that gap is where side projects quietly die.

That gap is the reason I keep this list at all. Over the last year I stopped treating each integration as a project and started treating it as a sentence: "when someone enters a city, show them the forecast." Say the outcome, wire the one endpoint that delivers it, move on. The apps that shipped were the ones where I refused to rebuild what twenty strangers had already given away for free.

That's also the gap we built Xenition to sit in — our AI workspace, a Flutter app on iOS and Android. You describe the thing you want — "an app that turns a postal code into the local weather and a map" — and it drafts the app with the free endpoints already wired in, so the integration is a conversation instead of an afternoon. The list above is the raw material. The skill is spending none of your day on the part that was already solved.

Bookmark the twenty. Then go build the one feature you actually opened the laptop for.

Your App Store Screenshots Are Selling Features. Nobody Installs a Feature.

Info Inlet — Sun, 18 Oct 2026 08:31:33 +0000

A stranger spends somewhere around six or seven seconds on your App Store page before they install or swipe away. Most of that is the first screenshot.

Not your description. Nobody reads the description until after they've half-decided. Not your feature list — that's below the fold on a screen they already left. The first one or two screenshots are the whole pitch, and for most apps that pitch is some version of:

here is our diagram canvas, here is our notebook, here is our 3D view

A tour. A product menu. Every screen says look what we built, and not one of them says look what you get.

We shipped exactly that for Xenition — our AI workspace, a Flutter app on iOS and Android. Five screenshots, each a clean, honest tour of a feature. They were nice. They did nothing.

So we threw them out and rebuilt the set around one question the old ones never asked: what does this person's life look like after they install? These are the seven rules we now run every single screenshot through before it ships.

I'll be straight about the thing everyone wants and I can't honestly give you: a clean before/after conversion number. We changed too much at once to pin a percentage on any one move. What I can give you is the framework, and the one test that tells you in ten seconds whether a concept is going to work.

1. The first screenshot is the entire pitch — so lead with the value, not the UI

Screen one has one job: make a stranger understand, instantly, why this app is worth their next thirty seconds. Everything after it is for the 20% who swiped. Screen one is for everyone.

Which means the most expensive mistake is spending it on your prettiest UI instead of your clearest promise.

And here's the part that stung: we couldn't write a good screen one until we admitted we didn't actually know, in one sentence, what we were promising. We'd been describing the app to ourselves — "it's an AI workspace with a canvas and a notebook and—" — a feature list wearing a value prop's clothes.

The rule: you don't start screen one in a design tool. You start it by finishing the sentence "after you install this, you can finally ___." If you can't finish it, no amount of design saves the screenshot.

That sentence comes from research — your reviews, your support tickets, the words real users use — not from a meeting where everyone already knows what the app does.

2. Sell the outcome, not the feature

Nobody wants an AI calorie tracker. They want to lose fifteen pounds without thinking about it. Nobody wants a meditation app. They want to stop lying awake at 2am. Nobody wanted our notebook. They wanted to stop pasting half-finished thoughts between four different apps.

The feature is the how. The outcome is the why, and the why is the only thing a stranger is shopping for.

This is the one that quietly rewrites every other decision. Once you know the outcome you're selling, the headline writes itself, the visual picks itself, and whole screenshots delete themselves because they were selling a how nobody asked about.

The rule: write the outcome first, in the user's words, then ask what to show to prove it. Never the other way around.

3. One screenshot, one message

The strongest concepts are almost always the simplest. Every screenshot gets exactly one primary message, and everything else on it exists only to support that one message.

You're allowed secondary information. You are not allowed a second thing that competes for the eye. The test is brutal and useful: if a stranger looked at this screen for one second and then you took it away, what's the one thing they'd remember? If the answer is "a few things, I guess," you have three weak screenshots glued into one.

The rule: one idea per screen, loud enough that it survives a one-second glance. If two ideas are fighting, that's two screenshots.

4. Make the idea legible with every word hidden

People look before they read. Always. The image lands in the eye before the headline gets a vote, which means if your concept only makes sense after someone reads the copy, you've already lost the ones who didn't.

So we do one exercise on every concept, and it's the most valuable ten seconds in the whole process:

Cover every headline and every caption. Can you still roughly tell what the app does?

If yes, you have a real visual hook and the copy is a bonus. If no — if the screenshot collapses into a meaningless UI mockup the moment the words disappear — there's a stronger visual idea you haven't found yet. Go find it. The copy should make a clear idea clearer. It should never be the thing carrying the idea.

The rule: hide the text. If the screenshot stops making sense, the problem was never the copy.

5. Put a human in it

Our eyes are wired to find other people. In a wall of near-identical app listings, a face, a hand, or a real-life moment grabs attention faster than one more floating phone mockup — every time.

A human element does something a UI screenshot can't: it lets the viewer picture themselves using the app instead of just inspecting it. There's a difference between "here is a dashboard" and "here is a person getting their evening back because of this dashboard," and the second one is the one that converts.

The rule: wherever it honestly fits, show the person, not just the product. Relatable beats impressive.

6. Earn trust with signals you didn't fake

Running underneath every install decision is one suspicious question: can I actually trust this?

Trust gets built in small signals — ratings, real reviews, download counts, an award, a press mention, a recognizable logo. These are usually treated as an afterthought, a badge slapped on screen five. Pulled forward and shown honestly, they can change how the entire app is perceived.

The word that matters is honestly. If you don't have the numbers yet, do not invent them or stretch a claim. A fake "4.9★ — 2M users" on a two-week-old app reads as exactly what it is, and the one thing worse than no trust signal is a transparently fake one. Credibility and honesty are themselves a trust signal — arguably the strongest one you own early.

The rule: show the real proof you have, prominently. Show no proof you don't. Never the middle option.

7. Fewer words, and make the ones left bigger

Founders try to cram the entire pitch into one headline. The best headlines go the other way: the shortest ones win.

Short copy is easier to read, easier to remember, easier to scan at a swipe — and the real payoff is mechanical. Shorter copy lets you make the words bigger. On a phone-sized tile in a scrolling list, a three-word headline at huge size beats a clever two-line sentence squeezed into eight-point type, and it isn't close. Size is attention.

And don't try to sound smart. Use the exact words your users use. "Stop losing your notes" beats "Unified knowledge persistence" in every test a real human has ever run.