DEV Community: Joachim Zeelmaekers

[Boost]

Joachim Zeelmaekers — Mon, 30 Mar 2026 15:32:02 +0000

Joachim Zeelmaekers

Mar 30

When Code Outpaces the Systems Around It

#softwareengineering #ai

Comments

6 min read

When Code Outpaces the Systems Around It

Joachim Zeelmaekers — Mon, 30 Mar 2026 00:00:00 +0000

AI has made it easy to turn ideas into code. Teams are seeing genuine speedups in planning, initial implementation, and even early review stages. But as with any engineering advancement, there are trade-offs.

The reality is that while code generation has accelerated, delivery pipelines haven’t kept pace. When test suites still take thirty minutes to run, CI pipelines are flaky, and deployments feel like defusing bombs, delivery pipelines haven’t sped up.

Consider this: Systems have been built that work when engineers are putting out 1-2 changes a day, but they break down at 5-10 changes a day. CI still takes 30 minutes per branch, everything needs merging so PRs pile up, and there is typically one deploy to staging every half hour.

This mismatch is often overlooked. Much of the process that’s been layered onto software development comes with speed trade-offs - sometimes intentional, often just organic evolution.

Now that generating code is cheap, one would expect software roadmaps to fly through delivery. But in most cases, that’s not what happens.

We expected the bottleneck to shift to trust decisions: Is this actually the right change? Does it work correctly? Can we ship it without starting a fire drill?

Yet that hasn’t been the outcome. Let’s examine why.

The Bottleneck Phase of AI Adoption

The first hard limit in review is review.

Code can be generated faster than it can be read. That’s where things get tricky.

Small change requests turn into 27-file diffs because AI tools touch nearby helpers, “simplify” abstractions that didn’t need changing, update unnecessary tests, and reformat code on the way out. None of it is obviously broken. Some of it might even be fine. But it still leaves reviewers staring at diffs they don’t have the time to read line by line.

Often, reviewers already have their own work open in three other tabs.

Reviews often become superficial. People start to just skim through changes, and they trust a green pipeline. They approve the shape of the change because tracing every consequence takes time they don’t have. This is not out of bad intention, but rather because it’s the only way to catch up.

These review cycles and safety checks exist for a reason—they protect the production environment. The goal isn’t to scrap them, but to evolve them to match the new generation speed.

That’s one of the real costs here. The goal should not only be ship faster, the goal should be ship faster without lowering quality.

The Three Stages of AI Adoption Maturity

A predictable maturation curve emerges as AI integrates into software delivery:

Stage 1: The Code Generation Boom Teams discover they can generate code faster than ever before for planning, implementation, and even initial review.

Stage 2: The Bottleneck Phase AI gets bolted onto systems that were already slower and messier than desired. Thirty-minute test suites that were tolerable before now become absolutely ridiculous in an AI loop. Changes stack up in a queue, with engineers waiting for things to move through the queue. Flaky CI now becomes even worse, as it not only impacts one change, but ten. Risky deploys create cautious behavior just when tooling is pushing to move faster.

Stage 3: The Automated Trust Phase The real wins come from investing in unsexy but critical infrastructure: fast feedback loops that don’t make you want to scream, clear boundaries so teams aren’t stepping on each other’s toes, boringly reliable deploys, documentation that doesn’t require an archaeology degree to understand, and having enough review capacity to actually keep up with the increased volume.

A flashy AI setup could help move the needle, but lasting improvement comes from evolving systems to match the new pace.

Decision Latency: The Next Bottleneck in the Maturity Curve

Another bottleneck that emerges is decision latency around process and approvals.

Changes get drafted quickly but sit for days due to additional review requests, sign-offs, unclear test plans, and unclear ownership.

This is what we mean by decision latency. The code can be done in an afternoon. The waiting takes the rest of the week.

When it’s unclear who has the final say, when every change needs three sign-offs, or when acceptance criteria only get clear near the end, AI mostly helps teams finish the code and then wait.

This highlights that this isn’t just an engineering structure problem, but more like a process problem that needs evolution alongside AI adoption.

AI rewards decomposition

This is why breaking work down clearly matters.

A sloppy task used to waste one person’s time. Now it can waste one person’s time at much higher speed while producing a lot of plausible-looking output someone has to untangle later.

When AI helps most, the task looks like this:

break a problem into smaller steps that can actually be verified
draft an implementation plan before touching the code
execute a scoped change with clear constraints
review a diff for missing edge cases or weak tests

When it helps least, the request sounds like “clean this up” or “improve the architecture” or “just take a pass at this module.”

Those aren’t real tasks. They’re a good way to get a diff nobody asked for.

Ownership matters more, not less

When code becomes cheaper to produce, the people who actually matter aren’t the ones who can type the fastest. They’re the ones who can properly scope a change, verify it thoroughly, and stand behind the decision to ship it.

This isn’t nearly as exciting as bragging about 10x productivity gains, but it’s closer to what engineering teams actually need to succeed, without reducing quality.

It doesn’t matter whether the first draft flowed from an AI model, a Stack Overflow snippet, or late-night coding. What matters is who really understood the trade-offs involved, who bothered to check the edge cases, and who’s willing to put their name on it when it hits production.

That’s why ownership becomes more critical, not less, when AI handles the initial draft. The machine can spit out options all day long, but it can’t be paged (yet) when something breaks in the middle of the night. It can’t explain why it made a particular trade-off during Friday’s incident review. It can’t look a stakeholder in the eye and say, “I’ve got this.”

What actually helps

Look, the answer isn’t to artificially slow things down for the sake of purity. The answer is fixing the system around the code.

Here’s what that looks like in practice:

First, break work down properly. Smaller tasks aren’t just easier to manage - they’re easier to generate with AI, easier to verify, easier to review, and way easier to toss out when the model starts hallucinating or going off the rails.

Second, make those feedback loops cheaper. When pumping out more code changes, tests need to be fast, CI needs to be reliable, and deploys need to be boringly predictable. If any of those are slow or flaky, they become instant bottlenecks that negate any speed gains from AI.

Third, get crystal clear on decisions. If every meaningful change requires a meeting and three layers of approval, you’re still optimized for a world where code was hard to write. AI just highlights how broken that process is to begin with.

Fourth, treat review like the bottleneck it often is, because it frequently is. If review capacity can’t keep up with the increased volume from AI assistance, you’re just creating a bigger backlog of unreviewed changes. That’s not progress, that’s just creating future problems for yourself. Make thorough reviewing a priority.

Fifth, make ownership obvious. Someone on the team should be able to look at a change and say without hesitation: “I understand this, I’ve verified it, and I’m responsible for it shipping successfully.”

And finally, when the AI tool isn’t actually helping? Stop prompting it. Seriously. Close the chat window, go back to the original problem statement, and rewrite it in simpler terms. Sometimes the best way to use AI is to not use it at all until you’ve clarified what you actually want, because if you don’t know what you want, how do you expect Claude to know what you want?

The upside of AI in software development is absolutely real. It’s a double-edged sword that can be extremely beneficial when the correct approach is taken, but it can produce significant amounts of low-quality output when the wrong approach is used.

[Boost]

Joachim Zeelmaekers — Mon, 23 Mar 2026 09:34:13 +0000

Joachim Zeelmaekers

Mar 23

In the Age of AI, Your Keyboard Still Matters

#productivity

Comments

5 min read

In the Age of AI, Your Keyboard Still Matters

Joachim Zeelmaekers — Mon, 23 Mar 2026 00:00:00 +0000

If you’ve seen my keyboard, a Kinesis Advantage 360, you already know I’m a keyboard nerd. The constant clacking probably gave it away.

But honestly? The idea for this post started with elbow pain.

For years, I had pain in my right elbow. At first it was manageable. It would flare up and be gone the next day, so I shrugged it off. Six months later, I started getting numbness in my fingers. As a software engineer, that’s not the kind of thing you casually ignore.

I went to the hospital. No nerve damage. Nothing on the scans. The doctor’s best guess was simple: too much pressure on my elbow, day after day. The fix was months of physical therapy.

After months of therapy, plus a month of lighter work during parental leave, the pain finally went away. Then I went back to work. First day back, it was already coming back.

That was the moment I started digging into ergonomic keyboards, typing technique, and all the small habits I had never paid attention to before. I ended up with a split keyboard, realized my hand position had been terrible for years, and accepted that trackpads are awful if you use them all day.

Switching keyboards was brutal. I went from typing more than 100 words per minute to barely hitting 30. I made mistakes constantly. It felt like starting over, which is a humbling experience when typing is one of the main things you do for work.

What surprised me was that it wasn’t only about pain. Fixing how I typed made me notice how much mental friction can hide in something as basic as typing.

When typing is automatic, your thoughts mostly go straight to the screen. When it isn’t, part of your attention gets burned on finding keys, fixing mistakes, or reaching for the mouse. That sounds minor until you notice how often it happens. And in the AI era, a lot of our work still lives in prompts, terminals, chat windows, editors, and constant back-and-forth.

One concrete example: after switching to my split keyboard, I dropped to about 30 words per minute. After a month of practice, I was back around 100. So something that used to take me more than three minutes now takes closer to one. If you’re writing prompts, replying to AI agents, or bouncing around in the terminal all day, that gap matters more than you’d think.

And I didn’t get there through some extreme setup. It was mostly 15 minutes a day on practice sites like monkeytype.com, with the boring but effective approach of working on accuracy first and speed second.

Shortcuts

This is where keyboard efficiency starts paying for itself. Not only in typing speed, but in all the tiny interruptions you stop having.

Your development environment is basically a toolbox. You shouldn’t have to go looking for the tools every time.

Take something simple from my own workflow: searching for a function or variable across a codebase. Without a shortcut, it looks like this:

Move my hand to the mouse
Navigate to the search icon in my IDE
Click it
Move my hand back to the keyboard
Type my search term
Press Enter

With a keyboard shortcut (Cmd+Shift+F in most IDEs), it becomes:

Hit the shortcut
Type my search term
Press Enter

None of that is dramatic on its own. But if you do some version of it dozens of times a day, those seconds start to stack up. More importantly, you stay in the problem. Your hands stay where they are. You don’t keep snapping your attention out of the work just to click around.

The same goes for opening terminals, switching tabs, accepting AI suggestions, running tests, or jumping between files. Each action is tiny. Together, they decide whether your tools feel invisible or whether they keep getting in your way.

The age of AI

I hear some version of this all the time: “Why bother with shortcuts or typing practice when AI can do the coding for you?”

And to be fair, there is some truth in it. AI is good at a lot of the mechanical stuff: boilerplate, first drafts, obvious fixes, even whole functions if the task is clear enough.

What gets missed is that we still have to drive the thing. As long as we work with AI through text, we still need to get our thoughts into the system quickly and clearly. That means writing prompts, refining output, reviewing code, fixing mistakes, and trying again.

AI might write some of the code, but you’re still the one who has to:

Craft clear prompts that capture exactly what you want
Review and refine AI suggestions
Jump between files to understand context

Every one of those tasks happens through your keyboard and your editor. The more fluent you are there, the less energy you waste on the mechanics and the more you keep for the part that still matters most: understanding the problem and making good decisions.

So no, I don’t think AI makes keyboard efficiency irrelevant. If anything, it changes where the bottleneck is. I’m typing less code by hand than I used to, but I’m still spending all day expressing intent, reviewing output, and moving through tools quickly enough to keep the thread in my head.

An easy way to learn it

If you want to get better at this, I think there are two good starting points.

If you already know how to type and just want more speed and accuracy, try monkeytype.com. That’s what I used to climb back from 30 words per minute to around 100 in less than a month. It helps that it makes progress visible, which is useful when improvement feels annoyingly slow.

If you’re starting from scratch, or you need to rebuild your technique like I did, typingclub.com is a better place to start. It walks through the basics step by step, which matters when you’re trying to undo years of bad habits.

The main thing is consistency. Fifteen focused minutes a day beats two hours once a week. And the goal isn’t to become some typing champion. It’s simpler than that. You want typing to disappear into the background so your attention can stay on what you’re trying to say, build, or figure out.

Beyond typing speed

Once you’re comfortable with your typing speed, start looking at your daily workflow for repetitive actions. What do you do over and over that could have a shortcut? Maybe it’s opening your test runner, switching to your terminal, or pulling up a specific file you reference all the time.

Try this: pick one of those frequent actions and either find or create a shortcut for it. Use it religiously for a week until it’s muscle memory. Then move on to another one.

This is where the real magic happens. You’re not just shaving milliseconds off keystrokes - you’re eliminating the little context switches that break your concentration. And unlike chasing higher WPM scores (which plateaus fast), streamlining your workflow keeps paying dividends as long as you’re using those tools.

[Boost]

Joachim Zeelmaekers — Mon, 09 Mar 2026 10:53:56 +0000

Joachim Zeelmaekers

Mar 9

How AI Changed My Workflow as a Software Engineer

#softwareengineering #ai

Comments

4 min read

How AI Changed My Workflow as a Software Engineer

Joachim Zeelmaekers — Mon, 09 Mar 2026 00:00:00 +0000

Over the past year, AI changed my workflow faster than anything else in engineering. Every few months there was a new editor to try, a new model to test, or a new agent worth taking seriously. Useful, yes. Also tiring.

What I took from that was simple: stop rebuilding your workflow around the current winner. I care more about having a setup that survives outages, pricing changes, and vendor churn than I do about squeezing out the absolute best capability this week.

So this post is not really about moving from Cursor to Claude Code to OpenCode. That is just the timeline. The whole point is that flexibility matters more than peak capability.

The tipping point

I started using Cursor seriously around March or April 2025.

At first it helped with the obvious stuff. Moving between files faster. Cleaning up code. Refactoring without losing momentum. It made me quicker, but it did not change how I thought about development yet.

That changed a few months later when the first Opus model got good enough for real development work. I think it was 4 or 4.1. AI tooling stopped feeling like autocomplete on steroids and started feeling like something that could move real work forward.

I still dislike the 10x talk around this stuff. For me it was more like 1.1x or 1.2x on a good day. Still meaningful, because no one dislikes writing boilerplate more than me.

After that, AI was no longer the question. The question was how I could rebuild my workflow around it.

Back in the terminal

Later that year, Claude Code got good enough that I could bring that leverage back into the terminal.

That mattered because the terminal is where I actually want to work. I have spent years turning it into the fastest place for me to think. Hundreds of commands. A lot of Neovim muscle memory. Outside pair programming, because I do not want to force Neovim on other people, and the occasional Git diff in VS Code, that is home base.

Claude Code was the first time I got that kind of leverage without having to leave the terminal. I was not trading leverage for comfort anymore.

So the question changed. If the environment finally felt right, what was actually worth optimizing around it?

The workflow became part of the job

From there I started spending a couple of hours a week improving the workflow itself.

Not using it. Improving it.

I tested tools, changed prompts, added skills, cleaned up context, and got more deliberate about where expensive models were actually worth paying for.

That work mattered more than any single model release. The real gain came from building a setup that kept working even while the tools kept moving.

That is when OpenCode started making a lot of sense to me.

Why OpenCode mattered

I do not use OpenCode because it beats every native tool at everything. It does not. Native tools often have an edge.

I use it because it lets me keep my workflow and swap the model layer underneath it more easily. That matters a lot to me.

I do not want to explain to a client that my setup fell apart because one provider had a rough day. I do not want to rebuild my habits every time pricing changes or the leaderboard shuffles.

If your workflow only works when one company is cheap, online, and still winning, that is not much of a workflow. It is a single point of failure.

I use these tools for hours every day. Reliability matters more to me than squeezing out the last bit of capability.

Not every task needs the best model

It also changed how I pick models for different jobs.

Some work really does need the strongest model. Architecture trade-offs. Messy refactors. Unfamiliar systems. Pay for intelligence there.

But a lot of tasks are much smaller than that. Rename this. Move that. Update the tests. Clean up some typing. I am not paying top-tier model prices for chores if I do not have to.

That is partly about cost, sure. It is also about not getting lazy. If the strongest model is always one keystroke away, it gets very easy to stop thinking earlier than you should.

The setup grew out of that.

The setup itself

The setup is honestly boring.

I keep the defaults in my dotfiles: shared AGENTS.md, workflow instructions, and skills that I symlink into the tools I use.

Claude looks for skills in .claude/skills. OpenCode looks in .opencode/skills. I do not want copies of the same setup scattered across repos, so I keep one version and link it where needed. That way both tools behave the same on both my Macs.

Then I add a repo-level AGENTS.md with only the local context that matters for that project. That gives the agent enough to work with without me repeating myself or waiting for a full repo scan.

The actual work happens in Git worktrees. Usually one task per branch, one agent session per worktree.

I am not trying to build the cleverest system here. I want something I can inspect, debug, and change without drama.

That is another reason the terminal still wins for me. My prompt tells me where I am. tmux makes it easy to hop between sessions. Worktrees map cleanly to tasks. Nothing is hidden behind a glossy interface that stops being cute the moment something breaks.

Final thought

I am not telling anyone to move to the terminal. Use whatever environment helps you think clearly.

But if AI is going to sit in the middle of your daily workflow, build for resilience first and keep enough flexibility to pick the right model for the job. Capability still matters. I just do not want everything else depending on it.

A workflow is only really yours when it survives the tool you built it around.

Career Growth Is Not a Meeting You Attend

Joachim Zeelmaekers — Mon, 02 Mar 2026 00:00:00 +0000

I hear mixed opinions about one-on-ones all the time. For some people they are a blessing. For others they feel like a waste.

My own experience has mostly been positive. I worked with managers who took these conversations seriously. The good one-on-ones were never a ritual to survive. They helped me think clearly, get unstuck, and leave with a better plan.

When I asked people about their experience, I heard the same split, and you can see it in the replies here:

Working on a new post about 1 on 1 meetings, and how they can be extremely valuable for one, but worthless for the other.

I'm lucky that I've had great mentors and managers, so in my experience they have been extremely valuable, but I hear different experiences.

What is your...

— Joachim Zeelmaekers (@joachimz_me) February 27, 2026

Some one-on-ones genuinely shaped careers. People felt seen, challenged, and supported. They still reach out to former leaders because those conversations mattered.

Others felt like calendar fillers. Status updates disguised as coaching. A manager trying to track activity instead of improving conditions.

The difference was rarely the template or the cadence. It was intent.

The best one-on-ones happened when the manager showed up curious. Curious about what was blocking me, what was unclear, what was slowing me down, and what I needed to grow. The worst ones happened when neither side owned an outcome.

That is why one-on-ones are powerful, but only when they are part of a system, not the system itself.

Preparation

The one-on-ones that failed for me were extremely predictable:

no clear goal
no evidence of progress
no concrete ask

In short, no preparation.

When that happens, the conversation defaults to updates, logistics, and whatever fire happened that week.

None of that is bad. Some one-on-ones should be casual. But I am talking about the ones that are meant to help you grow.

The meeting is not where growth happens

I used to think one-on-ones were where growth happened.

Now I think they are where growth is reviewed.

The real work happens before and after the meeting:

pick a skill to improve
practice it in real work
collect examples
ask for targeted feedback
adjust based on what you learned

Your manager can support this process. They cannot run it for you.

What to bring to every one-on-one

Once I started bringing structure, my one-on-ones got much better.

These are the four things I try to bring every time.

1. A short wins list

Not for ego. For evidence.

What did you ship? What improved? What impact did it have?

If you cannot point to outcomes, the whole conversation stays abstract.

2. One real blocker

Not ten complaints. One blocker that matters.

Maybe your pull requests take too long to merge. Maybe stakeholder alignment is messy. Maybe you freeze in architecture discussions.

Pick one. Make it specific.

A good manager does not need this meeting to track your tasks. There are better systems for that. The meeting is more useful when it focuses on what is preventing good work.

3. One skill gap you are working on (optional sometimes)

This is the part most people skip.

Say it directly: I need to improve at X. Here is how it shows up.

Examples:

turning ambiguous tasks into executable plans
giving clear technical updates to non-technical stakeholders
writing smaller, easier-to-review pull requests

Clarity makes feedback useful.

4. One concrete ask

If your one-on-one ends without an ask, do not expect much to change.

Ask for something actionable:

Can I lead the next incident retrospective?
Can we define what senior-level ownership looks like for my scope?
Can you review my design doc and challenge my assumptions?

Vague ambition gets vague support.

Development plans that actually survive

Most development plans start strong and then disappear.

Not because people are lazy. Usually because the plan is vague and fragile. It starts with motivation, then real work takes over, and nothing concrete remains.

What worked better for me was treating growth like a real project, because real projects are where you actually grow.

Build a six-month plan, then break it into trackable pieces.

Six months is long enough to change behavior and short enough to stay grounded.

A simple structure:

Pick one growth theme for six months.
Define what “better” looks like in observable terms.
Break it into monthly focus areas.
Create one monthly opportunity to practice.
Collect real feedback as your data.
Review monthly and adjust.

“Become a better leader” is not a plan.

“Over the next six months, lead one cross-team technical discussion per month, write a short recap, and ask two stakeholders for written feedback each time” is a plan.

The uncomfortable part

It is easy to say my manager is not helping me grow.

Sometimes that is true. Some managers are not the best coaches. Some environments are genuinely limiting. Some organizations split people management and technical leadership, which can make craft feedback harder.

But in many cases, the harder truth is this: we expect growth to happen around us, not through us.

We wait for better projects, better timing, better guidance, better recognition.

Meanwhile, weeks pass, then months.

One-on-ones do not create progress by themselves. They reveal whether progress is happening. If every meeting feels the same, something is not moving. That is the moment to reset expectations and change the inputs.

Final thought

One-on-ones matter. Development plans matter.

But they are multipliers, not magic.

If you bring clarity, evidence, and ownership, they can accelerate your growth. If you bring nothing, they become calendar theater.

It’s up to you to make things happen.

[Boost]

Joachim Zeelmaekers — Mon, 23 Feb 2026 19:14:42 +0000

Joachim Zeelmaekers

Feb 23

Rebuilding My Blog From the Ground Up

#softwareengineering #writing #blog #astro

Comments

4 min read

Rebuilding My Blog From the Ground Up

Joachim Zeelmaekers — Mon, 23 Feb 2026 06:00:00 +0000

My blog ran on Ghost for years and felt fast enough. Then I rebuilt it with Astro and Cloudflare Pages.

Page load dropped from about one second to under 300 ms, the stack cost went to zero, and I finally owned every part of the experience.

This is why I left Ghost and rebuilt the blog from the ground up.

Why I Left Ghost

Ghost is a great product. If you want a managed blogging platform with a clean editor and built-in newsletter support, it does the job well.

My reasons for leaving were not about quality. They were about control and fit.

Since my goal this year is to start publishing weekly, I wanted my blog to feel completely mine: faster, simpler, and shaped exactly to my preferences. Ghost did not allow the level of customization I wanted without workarounds.

The bigger issue was scope. Ghost Pro is not cheap, and self-hosting Ghost means running a server, a database, and ongoing upgrades. For a personal blog with one post a week, that stack felt like overkill.

I expected the newsletter to be the hardest part to replace. It turned out not to be.

Choosing the Stack

I did not spend weeks evaluating frameworks, like I would in the past. The decision was pretty simple.

Lately I heard a lot about Astro and I wanted to try it out. It ships hardly any Javascript by default, supports Markdown and MDX natively, and gives you full control over the output. No hydration overhead, no client-side routing unless you explicitly opt in. Just HTML and CSS.

Cloudflare Pages for hosting. Free tier, global CDN, automatic deployments using GitHub Actions. The site builds in seconds and deploys to edge locations worldwide. No servers to manage, no bills to worry about.

Markdown files instead of a database. Like we all know, lately everything has been about Markdown files, so why not put every post in a Markdown file in a Git repository. I can make changes to it in any editor, preview locally, and publish by pushing to main. Version history comes for free.

For my newsletter, with the full 12 subscribers, I first thought to not include it anymore. But then I found Kit, 10 000 subscribers for free. Perfect for my use case.

The entire stack costs me nothing beyond the domain name, and my time of course.

Performance Results

The page load numbers are the clearest win.

In real usage the Ghost site felt reasonably fast, around one second to visible content. However, Lighthouse mobile simulation revealed much heavier rendering costs, especially LCP. The Astro rebuild reduces both perceived and measured performance costs.

The architecture shift from dynamic rendering to static edge delivery shows up clearly in performance metrics.

Lighthouse snapshot (single run, mobile emulation, default throttling).

Here is a Lighthouse snapshot (single run, mobile emulation) comparing the old Ghost site with the new Astro build:

Metric	Ghost (before)	Astro (after)
Performance score	63	77
Accessibility score	80	100
Best Practices score	81	100
SEO score	100	100
FCP	2,597 ms	1,049 ms
LCP	23,758 ms	4,792 ms
Speed Index	7,857 ms	1,296 ms
Total page weight	7.71 MB	0.42 MB
Requests	36	28

The largest improvements come from removing heavy images and client-side scripts. Total page weight dropped by over 18x, which directly improved Speed Index and LCP.

Design + UX Updates

The better question would be, what did not change. Well, the content.

The homepage moved from a stock template to a focused, branded entry point with clear hierarchy and fewer distractions.

Beyond speed, the design is entirely mine. The goal was a calmer, more intentional experience with room to grow. I can now iterate quickly and add new features without fighting the platform.

The new list view trades heavy thumbnails and whitespace for tighter hierarchy and faster scanning. Smaller images, consistent metadata, and clearer contrast mean you can find a post at a glance without hunting for it.

The reading view moves from a template-heavy page to a focused editorial layout. Better line length, calmer typography, and fewer competing elements keep attention on the text and reduce cognitive load.

The CTA experience is now integrated into the reading flow instead of floating over it. Recommendations feel like a natural next step, not an interruption, which keeps the page focused while still nudging the next click.

The newsletter now feels like part of the site, not a third-party embed. The form is lighter, the spacing is calmer, and the CTA matches the rest of the system, so it reads as an invitation rather than a modal ad.

The benefit of building this site myself is being able to introduce more features to improve the experience:

Search across every post (full text, fast).
An About page that actually explains what I write about.
Dark/light mode that preserves the brand tone.
One-click code copy for snippets.
Dedicated tag pages so topics are easy to follow.
Posts grouped by year for quick scanning.

The Takeaway

If you are a developer blogging on a managed platform, ask yourself what you are getting in return for that convenience. If the answer is "less control and a monthly bill," it might be time to build your own.

It does not need to be complicated. A static site generator, a CDN, and Markdown files will take you further than most platforms. And the process of building it will teach you more than any blog post about blogging ever could.

Including this one.

In this week’s blogpost we dive deeper in the cost and income each feature brings to your product. The blogpost breaks down why a feature actually always has a rent.

Joachim Zeelmaekers — Mon, 16 Feb 2026 07:48:43 +0000

Joachim Zeelmaekers

Feb 16

[Boost]

Joachim Zeelmaekers

Feb 16

The Cost of Keeping What You Should Remove

#softwareengineering #saas #programming #webdev

Comments

4 min read

    </div>
  <div class="crayons-story__bottom">
    <div class="crayons-story__details">
      <a href="https://dev.to/joachimzeelmaekers/-2gma" class="crayons-btn crayons-btn--s crayons-btn--ghost crayons-btn--icon-left" data-reaction-count data-reactable-id="3259209" aria-label="Add a comment to post - [Boost]">
        <div class="multiple_reactions_aggregate">
          <span class="multiple_reactions_icons_container" dir="rtl">
              <span class="crayons_icon_container">
                <img src="https://assets.dev.to/assets/sparkle-heart-5f9bee3767e18deb1bb725290cb151c25234768a0e9a2bd39370c382d02920cf.svg" width="18" height="18" />
              </span>
          </span>
          <span class="aggregate_reactions_counter">1<span class="hidden s:inline"> reaction</span></span>
        </div>
      </a>
        <a href="https://dev.to/joachimzeelmaekers/-2gma#comments" class="crayons-btn crayons-btn--s crayons-btn--ghost crayons-btn--icon-left flex items-center" aria-label="Add a comment to post - [Boost]">
          <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" role="img" aria-labelledby="ab09v00vkkujje1eesv9mztnfj2eu374" class="crayons-icon"><title id="ab09v00vkkujje1eesv9mztnfj2eu374">Comments</title><path d="M10.5 5h3a6 6 0 110 12v2.625c-3.75-1.5-9-3.75-9-8.625a6 6 0 016-6zM12 15.5h1.5a4.501 4.501 0 001.722-8.657A4.5 4.5 0 0013.5 6.5h-3A4.5 4.5 0 006 11c0 2.707 1.846 4.475 6 6.36V15.5z"></path></svg>

          <span class="hidden s:inline">Add Comment</span>
        </a>
    </div>
    <div class="crayons-story__save">
      <small class="crayons-story__tertiary fs-xs mr-2">
        1 min read
      </small>
        <button
          type="button"
          id="article-save-button-3259209"
          class="c-btn c-btn--icon-alone bookmark-button"
          data-reactable-id="3259209"
          data-article-author-id="458853"
          aria-label="Save post [Boost] to reading list"
          title="Save post [Boost] to reading list">
          <span class="bm-initial">
            <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" aria-hidden="true"><path d="M6.75 4.5h10.5a.75.75 0 01.75.75v14.357a.375.375 0 01-.575.318L12 16.523l-5.426 3.401A.375.375 0 016 19.607V5.25a.75.75 0 01.75-.75zM16.5 6h-9v11.574l4.5-2.82 4.5 2.82V6z"></path></svg>

          </span>
          <span class="bm-success">
            <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" aria-hidden="true"><path d="M6.75 4.5h10.5a.75.75 0 01.75.75v14.357a.375.375 0 01-.575.318L12 16.523l-5.426 3.401A.375.375 0 016 19.607V5.25a.75.75 0 01.75-.75z"></path></svg>

          </span>
        </button>
    </div>
  </div>
</div>

[Boost]

Joachim Zeelmaekers — Mon, 16 Feb 2026 07:46:36 +0000

Joachim Zeelmaekers

Feb 16

The Cost of Keeping What You Should Remove

#softwareengineering #saas #programming #webdev

Comments

4 min read

The Cost of Keeping What You Should Remove

Joachim Zeelmaekers — Mon, 16 Feb 2026 06:00:55 +0000

Every product I have worked on has features that cost more to keep than they are worth. Not broken features. Not controversial ones. Features that work fine, get used by almost nobody, and sit there quietly taking up space.

I have kept features like that alive for years. Not because they added value, but because removing them felt like more work than leaving them in place. They worked. They were not hurting anyone. Why bother?

That reasoning felt pragmatic at the time. I have since learned it is the most expensive form of laziness in software.

The lie we tell ourselves

"It works, so it is free to keep."

This is what we say when we do not want to think about it. And for a while, it's true. The features sit there, untouched, collecting dust. Nobody complains. Nobody celebrates. They just exist.

But software does not work like this. Dependencies shift. Frameworks update. Security patches ripple through layers you forgot were connected. Those quiet features are not free. They are accumulating debt.

I learned this the hard way many times. A release went out, and three weeks later a bug report came in from a single user clicking a button I had forgotten existed. Someone had to context-switch, investigate, trace the regression, fix it, and report back. Half a day of engineering time for a feature that served one person who probably would not have noticed if the button had simply disappeared.

That was one feature, one bug report. Now multiply it across every neglected corner of a product.

The weight you stop noticing

One unused feature is manageable. You barely think about it. But products do not collect one. They collect dozens, quietly, over years. A toggle nobody clicks. A report nobody reads. An export format nobody requests. Each one seemed harmless when it shipped. Each one still seems harmless on its own.

But collectively, they change the shape of every conversation. A design review takes longer because the interface has no space left. A dependency upgrade touches code paths nobody remembers writing. A new engineer spends their first week building a mental model of a system where a third of it serves no one.

In some occasions, removing unused features is not even on the table. Not because anyone defends them, but because nobody can confidently say which ones are unused. The tracking might not be there. Or maybe the institutional knowledge had left with the people who built them.

That is how it compounds. Not through any single decision, but through the absence of decisions. The features you never question become the ones that define your constraints.

Why we still keep them

I think the real reason we keep unused features is not pragmatism. It is discomfort.

Removing a feature feels like admitting failure. Someone built it. Someone approved it. Maybe it was your idea. Deleting it means acknowledging that the effort was, in some sense, wasted.

I have felt that discomfort. I have argued to keep things I built, not because they mattered to users, but because they mattered to me. That is not product thinking. That is ego dressed up as engineering judgment.

There is also the fear of the edge case you cannot see. What if that one user depends on it? What if removing it breaks something downstream? These fears are real, but they are also answerable. Usage data exists. Conversations can be had.

The fear of finding out is not a reason to avoid looking. And certainly not, when you can just bring the feature back if complaints come in.

When keeping is the right call

I do not think the answer is to remove everything with low usage. Some features serve a small audience that depends on them deeply. Some could exist because of contractual obligations or regulatory requirements. Some are niche but genuinely valuable for power users.

There is a difference between keeping a feature because you evaluated it and decided it still earns its place, and keeping it because nobody bothered to ask the question.

The discipline of subtraction

Every feature has a rent. Some pay for themselves through usage, through value, through the problems they solve. Others just accumulate cost quietly, making everything around them a little harder, a little slower, a little more constrained.

Adding features is easy to celebrate. Shipping feels good. But the products I admire most are not the ones with the most features. They are the ones where every feature earns its place. Where someone had the discipline to ask: does this still serve the people using this product?

The discipline is not in building more. It is in being honest about what deserves to stay.

Subscribe to my newsletter!