Checklist: "Is this idea worth a tech article?"

Posted on February 16, 2026 • 9 minutes • 1741 words

Table of contents

Real problem or shiny object?
Does it fix something… better than what you already had?
Passing fad or here-to-stay trend?
Is there enough meat… without turning it into a PhD thesis?
Can you tell at least one decent story?
Are you adding something… or just swapping the template?
Will your future self find it useful?
Quick checklist (the version you can paste into a README)
Sources and references

Most good technical articles are born the same way: someone got burned by a real problem and decided that, since they’d already bled, the least they could do was save others from tripping over the same spot. Then there’s the other kind: the one you end up writing after seeing yet another LinkedIn post claiming that “X is going to revolutionize software development” and thinking, “this smells like snake oil, but let me take a look just in case.”

This piece is about that: how to decide if an idea deserves an article (and your time), or if you’re better off closing the tab and getting back to your coffee. And, as a bonus, it doubles as a checklist for evaluating whether a “new” technology or pattern is actually worth the hype — marketing aside.

Real problem or shiny object?

The first question is almost existential:

“Does this solve a problem that I or my audience are already dealing with… or is it just a shiny thing I feel like tinkering with?”

If you can’t explain the pain without dropping the name of the framework or pattern, that’s a red flag. “We need Kafka” is not a problem; “our system is choking because we’ve shoved all async communication into a single homegrown queue with no ordering or delivery guarantees” is.

Think about really concrete things:

What’s being done by hand today that could be automated without building a Rube Goldberg machine?
Which part of the system causes the most grief every release?
Where are the complaints coming from — business, support, SRE, or your end users?

If the honest answer is “nobody actually has this problem yet, but I saw four really cool/convincing/spectacular conference talks”… you’re probably staring at a gorgeous shiny object, not a serious article topic.

Quick rule: if you can’t describe the problem in plain terms, without buzzwords or brand names, the problem is you, not the framework.

Does it fix something… better than what you already had?

Let’s assume there’s a real problem. Next filter:

“Does the new idea clearly improve something that already exists, or does it just redo it with a different logo?”

Before you go banging out 1,500 words about that amazing thing, ask yourself:

What will actually be better if I apply this? Will it make my life easier? Cut costs? Give me faster delivery speed ? Will I get fewer 3 a.m. wake-up calls?
What was the sensible alternative before? A decent CRUD, a bit of caching, a simple queue, a well-designed database?

Be suspicious of anything that can only be sold with words like “revolutionizes,” “transforms,” “disruptive,” but that nobody manages to illustrate with a recognizable “before/after” example. It’s the same pattern you see with a lot of AI washing : spectacular promises, concrete use cases… zero.

If the real advantage isn’t clear in a realistic scenario — an e-commerce platform, a SaaS product, an internal system — you don’t have material for a tech article yet; you have material for a meme.

Passing fad or here-to-stay trend?

This isn’t about being a professional cynic (although that helps). It’s about telling the difference between this quarter’s fad and something that’s going to be around in at least 3 to 5 years .

A few signs that something is probably a fad:

Nobody can agree on what problem it actually solves.
Everyone mentions it in slide decks; almost nobody uses it in production at scale .
The marketing is way ahead of the real war stories.

On the other hand, a solid trend usually comes with different signals:

There are reasonable case studies , with pros and cons — not just fireworks.
It’s not only vendors pushing it: regular teams talk about how they use it , what the limits are, and what pain it actually took off their plate.
It starts showing up in established ecosystems, rather than living as an isolated toy.

Here are a couple of examples:

Event Sourcing / CQRS : makes perfect sense in domains where auditability, traceability, and state reconstruction are critical (finance, payments, regulated systems). If you only want it because you saw an epic talk with hexagonal diagrams, maybe hold off.
AI everywhere: slapping “AI-powered ” on everything because it looks good on the roadmap isn’t a trend — it’s marketing on steroids . Using AI to reduce repetitive work (classifying, summarizing, smarter search) where it’s currently done by hand — that’s starting to look structural.

If you can’t tell which side your topic falls on, maybe the article you should write isn’t “X explained” but rather “what made me skeptical (or excited) about X.”

Is there enough meat… without turning it into a PhD thesis?

A good technical article is neither a cheat sheet of commands nor a 40-page academic paper. It needs balance:

A bit of context: where this idea comes from , what problems it was originally trying to solve.
One or two concrete use cases where it fits.
One or two situations where it doesn’t fit and will make your life harder.
Enough practical detail for someone to start trying it out with some sense of direction.

If all you can squeeze out of the topic is a list of marketing bullet points or a watered-down summary of the official docs, you don’t have an article yet — you have notes.

A simple test: in your first draft, can you write a paragraph — no hand-waving — about “when NOT to use this”? If you can’t, you still don’t understand it well enough. And that’s fine; it just means it’s too early to recommend it to others.

Can you tell at least one decent story?

The articles that get shared the most aren’t usually titled “Pattern X Explained.” They’re more like “How we stopped breaking production every Friday using X ” or “What we learned rewriting this module with Y .”

Simple but powerful stories:

“What problem we had.”
“What we tried before that didn’t work.”
“What happened when we applied X (the good and the bad).”

Ask yourself:

Do you have at least one realistic example with a before/after?
Or can you build one that works (a checkout flow, a payment pipeline, a queuing system) and that doesn’t look like it was ripped from a textbook exam?

If all you’ve got are definitions and generic diagrams, you probably haven’t had enough hands-on time with the problem. In that case, the best next step isn’t publishing — it’s trying: a prototype, a controlled experiment, a proof of concept that will eventually produce an article with more substance.

Are you adding something… or just swapping the template?

Unless you’re about to invent a whole new field of computer science, you won’t be the first person to write about almost anything. That’s fine: your value isn’t being first, it’s being useful.

Things that actually add value:

Grounding the idea in everyday problems: duplicate payments, queues that fill up, unreadable logs, missed SLOs.
Comparing it honestly with simpler alternatives: do you really need CQRS, or would a solid CRUD with domain events do the job?
Sharing real trade-offs: what it gave you, what it took away, what it made harder.
Bringing experience from less-traveled domains: nuclear, healthcare, regulated banking, etc., where the requirements are very different from those of a typical SaaS startup.

If you reread your draft and think, “well, you could replace this with a link to the official page and the reader wouldn’t miss much,” you’re probably lacking your own angle. Better to wait until you have one than to publish the same thing with a different WordPress theme.

Will your future self find it useful?

This last criterion is selfish — and most of the time it’s my main criterion, precisely because I think it’s an excellent one:

“Will this article be useful to ME as a reference a year from now?”

If the answer is yes, it will almost certainly be useful to someone else too:

Because it documents a tough decision (“why we did NOT migrate to microservices in 2025”).
Because it condenses information from several scattered sources into one coherent guide .
Because it captures screw-ups you don’t want to repeat — and that others would be spared by reading about your stumbles.

This filter is especially useful for:

The framework-savior of the month.
Advanced patterns that are fascinating to play with… and exhausting to maintain (Event Sourcing , CQRS , Data Mesh ).
Trendy stuff like no-code/low-code, AI-powered features , or the latest magical cloud service.

If not even you believe you’ll revisit that link a year from now, what you’re writing might be for an algorithm, not for people.

Quick checklist (the version you can paste into a README)

Before deciding “I’m going to write a tech article about…,” hit it with these questions:

What real problem does it solve, and who’s feeling the pain?
Does it genuinely improve something existing, or is it the same dog with a different collar?
Does it look like a lasting trend, or just the latest slide-deck fashion?
Can I also explain when NOT to use it?
Do I have at least one concrete, realistic example?
Am I adding something beyond what the docs and generic blog posts already say?
Would I personally come back to this a year from now?

If most answers are “yes,” you’ve probably got material for a solid article (and for making a sound technical decision). If you’re getting a lot of “hmm… not really,” maybe all you have is the urge to play with a new toy. And that’s wonderful — play, tinker, learn — but not every toy needs to become a manifesto on Medium or LinkedIn.

The idea is simple: write less about fads, and more about decisions.

Your readers — and your future self — will thank you.