Build What You Know (Even If You Only Kinda Know It)

You don't have to be an expert. You just have to be familiar.

That's the whole bar. Not "have a computer science degree." Not "worked in tech for a decade." Just: know a subject well enough that you can smell when a solution is fake.

I'm 50. I don't code. My whole professional life is in areas that had nothing to do with software until, one day, they did. And the projects that have actually gotten off the ground for me are the ones where I lived the problem before I asked an AI to help me solve it.

The unfair advantage nobody talks about

Everyone thinks the advantage in building software is technical skill. It's not. The advantage is domain knowledge — knowing what actually matters to the person on the receiving end. AI can write the code. AI cannot know what it feels like to be the person who needs the tool.

A 22-year-old developer with no domain experience is going to build a slick app that misses the point. You, with your twenty or thirty years of scars in whatever industry you know, are going to build something ugly that people actually use. Guess which one wins.

"Familiar" is enough. Really.

You don't have to be the world's foremost expert. You just have to know:

What the current tools get wrong
What the workarounds are (because there's always a workaround)
What people complain about at 4pm on a Friday when nobody's around
What they'd pay to have solved and what they'd only shrug at

If you can answer those four questions honestly for one specific group of people, congratulations — you have a real project. Everything else, including the code, is negotiable.

The trap: solving a problem that isn't a problem

Here's where a lot of us go wrong (raises hand). We fall in love with the idea of building something before we check whether the problem is actually a problem for anyone but us.

Signs the problem is real:

You've personally been annoyed by it more than a dozen times
Other people, unprompted, complain about it too
The existing solutions are either expensive, clunky, or nonexistent
When you describe your fix, people say "wait, that doesn't exist already?"

Signs the problem is not real:

You have to explain, in three paragraphs, why anyone would care
Your best supporter is your mom
The existing solution is fine, you just don't like the color of the buttons
Nobody else in your life has ever mentioned this problem

Be brutally honest here. It saves you months.

Better, or nowhere at all

Once you know your problem is real, ask the harder question: can I do this better than what already exists?

"Better" doesn't have to mean prettier or more features. It can mean:

Simpler (the current tools are bloated)
Cheaper (the current tools are $200/month for something small businesses need)
Faster (the current tools take 40 clicks)
More honest (the current tools are secretly a sales funnel)
More specific (the current tools try to serve everyone and serve nobody)

If you can't finish the sentence "mine will be better because ______" without lying, don't build it. Or, better — go find a different angle on the same problem until you can finish that sentence.

What I'm not going to pretend

I'm not going to pretend I always did this. I have absolutely started projects because I got excited about a shiny idea and skipped the "do people actually need this" step. Those projects are all sitting in a graveyard folder somewhere. That's the tax you pay for being enthusiastic. It's fine. It's part of the process.

But the ones that survived were the ones where I could sit across from a real person, describe the tool, and watch them go, "wait, when can I use this?"

The takeaway

You don't need permission to build. You don't need credentials. You don't need to have "figured out AI" first.

You need one problem, in an area you know something about, that you can genuinely make better than the current best option.

That's it. That's the whole starting requirement. Everything after that is just a lot of prompts, a lot of coffee, and a surprising amount of yelling at your laptop.