Small Companies Build Their Own Software Now. Most Can't Tell If the Developers Are Good.

A decade ago, a 15-person company bought software. Today that same company builds it. A custom internal dashboard. A customer portal. Maybe an AI feature their competitors don't have yet. None of it came from a vendor. One or two developers built it in-house.

This is new, and it's spreading fast. AI tools dropped the cost of writing code. A tiny team can now ship things that used to need a real engineering department. Founders love this. They get exactly what they want instead of bending their business around someone else's product.

Then the questions start. Is this code any good? Will it hold up when we have ten times the users? Is this developer actually strong, or do they just sound confident? Most founders building software for the first time have no way to answer.

Building got cheap. Judging didn't.

Here's what changed. Writing a working feature used to be the hard, expensive part. You needed someone who could turn an idea into running code, and that skill was scarce. So the bottleneck was building, and you could measure progress by whether the thing worked.

That bottleneck moved. With AI assistance, getting something to work is the easy part. A junior developer can ship a feature that demos well in an afternoon. The screen loads. The button does the thing. It looks done.

But "it works in the demo" and "it works" are different claims. The gap between them is where all the cost lives: the edge cases nobody tested, the database query that falls over at scale, the security hole, the code so tangled that the next change takes three weeks. None of that shows up in a demo. All of it shows up later, usually at the worst time.

Judging that gap is still a scarce skill. It always was. The difference now is that you can no longer use "does it work" as a proxy for "is this person good," because almost anyone can make something work.

Why AI makes this harder, not easier

You'd think AI would make weak developers obvious. It does the opposite. It hides them.

AI-generated code is confident and clean-looking. It uses the right patterns, names things sensibly, and reads like a competent person wrote it. A founder who can't read code sees output that looks professional and assumes the person behind it is too. Sometimes that's true. Often it isn't.

The new risk is a developer who can produce a lot of plausible code and can't tell when it's wrong. They accept what the AI gives them. They ship it. It looks fine. Six months later you're paying someone else to untangle it, and that bill is bigger than what you saved.

The signal you actually want isn't "can they produce code." Everyone can now. It's "can they tell good code from bad, including their own and the AI's." That skill doesn't show up in a portfolio screenshot. It shows up in how someone thinks.

What good actually looks like

A strong developer in this environment has a few traits you can spot without reading a single line of code.

They can explain their decisions. Ask why they built something a certain way and you'll get a real answer about trade-offs, not "that's just how you do it." Good developers know they chose one option over others and can tell you what they gave up.

They tell you what could break. Weak developers say everything is fine. Strong ones volunteer the risks: this part won't scale past a certain point, this depends on a service that could go down, we cut this corner to ship faster and here's when we'll need to fix it. Honesty about limits is a sign of someone who actually understands the system.

They treat AI as a tool, not a crutch. The best developers use AI constantly and review every line of it. They'll tell you where it saves them time and where they don't trust it. Someone who either refuses to use AI or accepts all of it blindly is showing you a judgment problem.

Their work survives contact with users. The real test isn't the demo. It's the second month, when real people use the thing in ways nobody predicted. Good developers build for that day. You can see it in how few fires they start.

What to ask when you can't read the code

You don't need to be technical to run a useful conversation. These questions surface judgment:

• "What part of this are you least confident about, and why?"
• "If we get ten times more users next month, what breaks first?"
• "Where did you use AI to build this, and where did you decide not to?"
• "What did you cut to ship on time, and what does it cost us later?"
• "If a new developer joined tomorrow, how long until they could safely change this code?"

You're not grading the answers on technical accuracy. You're listening for whether the person thinks in trade-offs and risks, or whether everything is "no problem." The first kind protects your business. The second kind hands you a bill you can't see coming.

What a non-technical founder can do

You can't evaluate code you can't read. So stop trying to, and build a process that doesn't depend on it.

Get a second technical opinion before you commit. A short paid code review by someone independent will tell you more than any interview. A good reviewer can look at a codebase for an hour and tell you whether you're standing on solid ground or quicksand. That hour is the cheapest insurance you'll buy.

Hire for judgment, not output speed. The developer who ships slightly slower but explains their reasoning and flags risks early will cost you far less over a year than the one who ships fast and leaves a mess. Speed is easy to see and the wrong thing to optimize for.

Watch what happens after launch, not during the demo. Count the fires. A developer whose work quietly keeps running is worth more than one with an impressive first showing and a stream of bugs behind it.

And when you can't tell good from bad yourself, work with people whose entire job is telling them apart. That's the part most small companies skip, and it's the part that decides whether building your own software was the smartest move you made or the most expensive.

The real risk

Building your own software is a real advantage. Companies that do it well move faster than competitors stuck waiting on vendors. We're not arguing against it.

The risk is assuming the hard part is over once something works. It isn't. The hard part is knowing whether the person who built it can be trusted with the next thing, and the one after that, as your business comes to depend on the software more every month.

AI made building easy. It made evaluating developers harder. If you're going to build, get serious about the second part. It's the one that's actually scarce now, and it's the one that decides how this ends.