The Demo Always Works. That's the Problem.

Here's a story I keep hearing some version of.

A small business hires a developer, or a small shop, to build a custom tool. Maybe it's a customer portal. Maybe it's a scheduling system that ties into the software they already use. The work moves fast. Three weeks in, the demo looks great. Everyone signs off, the invoice gets paid, the site goes live.

For about a month, nothing's wrong.

Then a customer calls because a form they filled out never showed up in anyone's inbox. The login page hangs on slow connections. A simple report takes forty seconds to run. Or, worse, a stranger emails to say they were able to view another customer's account without logging in, and would you mind fixing that before they go public with it.

You call the developer. They're three projects into someone else's work. They poke at it for a few hours and tell you it'll need to be "partially rewritten." That's the polite version of starting over.

AI is a multiplier on whoever's in the chair

I don't want to sound like the guy telling you AI is overhyped. I use these tools every day, and I wrote a fair bit about how big the productivity jump is in the last post. The speed gains are real. The way one engineer can cover ground that used to need a small team is real.

But the speed comes from amplifying whatever judgment is already at the keyboard. AI is great at writing the code you ask for. It's not the thing that decides whether the code you asked for is the right code. That part still belongs to the person driving.

A developer who already knows what production-grade software has to survive gets an enormous boost from these tools. They know what real users do to a system, what load does, what goes wrong at three in the morning. A developer who doesn't know any of that gets the same boost. Their output just looks done a lot sooner. The demo runs. The screenshots look right. Nothing is visibly wrong on the surface.

That's the problem. The demo doesn't tell you whether anyone in the room knows what they're looking at.

What "looks done" can hide

The kinds of trouble I'm describing aren't exotic. They're the same mistakes engineering teams have been making for decades. AI didn't invent them. It just made them faster to ship.

The first one is maintainability. Code that works the first time is not the same as code anyone can change later. I've watched builds go like this: the original developer gets the demo working, gets paid, walks away, and the first time the business needs a small change (a new field on the form, a different way of grouping customers) the next developer has to spend two days untangling what's there before they can write anything new. The cost of the second change ends up being higher than the cost of the original build. By the third or fourth change, the business is paying to rebuild the same feature twice.

The second one is stability under real load. A demo runs with one person clicking around. Production runs with twenty real customers using it at the same time, or with a database that's been growing every day for six months. Code that didn't think about either of those works fine right up until it doesn't. The kind of thing that's invisible during a one-week build and unmissable on a Tuesday afternoon when the page won't load and you have no idea who to call.

The third one is security, and it's the hardest one to spot from the outside, because the symptom is silence. A login that doesn't actually verify who you are. User-supplied data going straight into a database query in a way that lets a bad actor read whatever they want. Permissions checked only on the screen the user sees, not in the code behind it. You don't find out about any of this on launch day. You find out when somebody else does, and by then the conversation is about damage control, not features.

The bait-and-switch problem

There's a related thing worth knowing about the way custom software is sold. Some shops put a senior architect in the room to win the work, then hand the actual build to junior or contracted developers once the contract is signed. This isn't always shady. It's how a lot of larger agencies stay profitable. But the person who sold you on the project is not the same person making day-to-day judgment calls about your code, and that gap is where a lot of these problems live.

AI changes the dynamic in an uncomfortable way. The senior can still spot trouble in a code review if they're looking. The volume of code being produced has doubled or tripled, though, so there's more output to skim, less time to look closely, and a less-experienced developer using the same tools is now generating in an afternoon what used to take a week. The pace makes the gaps easier to miss, not harder.

If you ask a shop who's actually doing the work and you can't get a name out of them, that's information.

What to actually look for

You don't need to be technical to ask better questions during the sales process. A few that I'd want a friend asking before they signed:

Ask who specifically will be writing the code. Not "our team." A person, with a name, and ideally a sample of past work you can poke at. If you can talk to a previous client of theirs, do.

Ask what happens after launch. Does the same person stay on to maintain it, or do they hand you a zip file and disappear? When something breaks at 9 PM on a Saturday, who do you call?

Ask, in plain English, how they handle login security, what happens if your traffic doubles, and how they decide when something is ready to ship. A confident, plain-language answer to those questions tells you more than a slick deck does. If the answers are vague, or you get a wall of jargon designed to make you stop asking, that's also information.

The point isn't to catch anyone out. It's to find out whether the same person selling you on the work is actually doing it, and whether they've thought past the launch demo.

How I work, briefly

This is where I'll stop pretending I don't have a horse in this race.

Every project I take on at Wallman Solutions is scoped, built, hosted, and maintained by me. There's no handoff to a less-experienced team after the contract is signed. AI is a real tool that I lean on heavily, and it's a big part of why a one-person operation can do the work of a small team. Twenty years of writing software for production systems is what I lean on to keep that tooling honest. The combination is the whole point.

I'm not the right fit for every project. If you need a six-engineer team and a project manager, you don't need me. But if what you actually need is someone competent who picks up the phone, builds something that holds up under real use, and is still around in six months when the business has questions or a small change to make, that's the work I'm here for.

If you're reading this

If you're sitting on a prototype that looked great in a demo and is starting to wobble in production, or you're a few weeks away from signing a custom-software contract and you'd like a second set of eyes on the proposal before you do, that's a conversation I'd rather have before the rewrite than after.

Drop me a line.

— Nathan