There's a version of software that passes QA, launches on schedule, gets a press release, and then quietly fails in the field. Nobody's writing about that version. I've built it, and I've had to fix it.
Here's what I've learned.
The demo is not the product
When you're building for real users — not for a pitch, not for a portfolio — the gap between what works in a demo and what works in the wild is enormous.
The Michigan COVID assistance apps I worked on needed to handle people using their phones with cracked screens, in areas with spotty data, under extreme stress, in multiple languages, while also needing to actually output results that connected to government systems that themselves were barely holding together.
No demo captures that. You find out in the field.
The integration is the hard part
The feature is never the hard part. The integration is. Getting your system to talk to their system. Getting the output of one process to be the input of another without anyone losing information in between.
I spent more time on integrations on every major project than I spent on the actual feature work. This is true of government systems. It's true of franchise software. It's true of anything where you're not building in a vacuum.
If you're planning a project and your estimate doesn't have a big line item for integration complexity, your estimate is wrong.
If staff won't use it, it doesn't work
The most technically impressive thing I've ever built that didn't work: a case management tool with powerful search, flexible filtering, and a clean dashboard — that nobody used because it required three clicks to log a call and the previous system required one.
Three clicks. That was the delta. That was the whole thing.
You can be right about the architecture and wrong about the product. Know the difference before you build.
Feedback loops need to be short
The teams that shipped the best products I've worked on had one thing in common: they were talking to users every week. Not monthly. Not quarterly. Every week.
The teams that shipped the worst products had a common pattern: they'd go heads-down for months, emerge with something impressive, and discover that the most important thing had changed while they were building.
Short feedback loops feel slow. They're not. They're the fastest path to something that actually works.
More on this. I'm writing it as I go.