Most developers build software by reading requirements documents. They get a spec, they build to the spec, they hand it back. If the spec was wrong — or more commonly, if the spec missed how the operation actually works at 7 AM on a Monday when three people called in sick — the software misses it too.
I didn't start as a developer. I started as a bench technician, testing electronics on a warehouse floor. Over 14 years at the same company, I worked my way from that bench to Operations Director — responsible for a 100,000 square foot warehouse, 35–50 people on the floor, and a tracking operation handling over 900,000 devices.
Along the way, I built the software we needed. Not because I was hired to code — because nobody else understood the operation well enough to build what it actually required.
That sequence matters. I ran the operation first. I built software because I understood what was breaking, what was slow, what was falling through cracks that a developer who'd never stood on that floor would never see.
What that actually changes
Here are the things I learned running operations that change how I build software today — not as abstract principles, but as the specific ways a project turns out differently when the builder has lived inside the problem.
Lesson 1: The real workflow is never the official workflow
Every operation has two versions of how things work: the one on paper and the one that happens at 6:45 AM when the first truck shows up.
In 14 years managing a floor, I watched the gap between those two versions cause more problems than any bug ever did. Someone builds software for the documented process. The team uses the actual process. The software becomes an obstacle they work around instead of a tool they work with.
When I scope a project, I don't start with your documentation. I start with "walk me through what actually happens on a typical Tuesday." The ugly, honest version — the workaround, the sticky note, the spreadsheet someone made six years ago that somehow holds the whole operation together. That's what the software needs to serve.
Lesson 2: Access control isn't a feature — it's a survival requirement
In a warehouse tracking 900,000+ devices with pricing information attached to every one, the wrong person seeing the wrong number at the wrong time isn't a "nice to have" problem. It's a real financial risk.
I built a system with three access roles — techs who could see inventory but not pricing, managers who could see both, and admins who controlled who saw what. Not because a spec said "add roles." Because I'd watched what happens when a tech accidentally sees a number they shouldn't, or when a customer-facing employee has access to internal cost data.
When I build access control for a client today, I'm not implementing a checkbox on a feature list. I'm thinking about the specific moment when the wrong person logs in and sees something that causes a problem. That's a different conversation than "how many roles do you want?"
Lesson 3: Software that doesn't match the physical reality gets abandoned
I watched this happen more than once: a company buys software designed for a "clean" version of their operation. The software assumes you scan things in a certain order, or that your inventory is always correct, or that people enter data the moment something happens instead of three hours later when they finally sit down.
The physical reality is messier. People forget. Things get scanned out of order. The truck shows up before the receiving ticket. A device goes to the wrong shelf and nobody notices until someone needs it.
Software that breaks when reality is messy doesn't survive in a real operation. It gets abandoned, worked around, or replaced with the spreadsheet it was supposed to replace.
When I build inventory systems, scheduling tools, or operational dashboards today, they're built expecting the mess. Because I lived in it. I know what gets skipped on a busy day. I know what data entry happens three hours late. I know what breaks when someone's in a hurry.
That's not a feature list. That's 14 years of watching what actually happens.
Lesson 4: The tool has to be faster than the workaround — or it loses
Every operation has workarounds. The spreadsheet that's technically wrong but faster than the "real" system. The whiteboard that everybody checks because the software is four clicks deep. The text message that replaces the communication tool nobody uses.
Workarounds win because they're fast. The official tool loses because using it correctly takes longer than doing it the old way.
When I build something for a client, the question I'm constantly asking is: is this faster than the current workaround? If it's not — if it takes more clicks, more steps, more thought — it won't get used. Doesn't matter how "correct" it is architecturally. Doesn't matter how clean the code is. If the sticky note is faster, the sticky note wins.
That's not something you learn from a requirements document. It's something you learn from watching a team ignore the software you built because the old way was two seconds quicker.
Lesson 5: You don't know what you need until you've operated without it
The best features I ever built were the ones nobody asked for — because nobody knew they needed them until the operation had been running long enough for the gap to become painful.
In 14 years, I had the luxury of time. I could watch a process fail slowly, understand why it was failing, and then build the exact tool to fix the exact problem. No guessing. No "maybe they'll need this." Just: this broke, here's why, here's what fixes it.
When I work with a client today, that's what I'm trying to compress. I can't spend 14 years inside their operation — but I can spend enough time watching, asking, and understanding to identify the real pain points instead of building for imagined ones. Because the software that matters is the software that solves the problem you actually have, not the one a salesperson convinced you that you have.
What this means if you're looking for a developer
If you're running an operation and you need software built for it, you have two kinds of developers available:
The one who builds from a spec. Give them clear requirements and they'll execute well. The skill is technical. The output matches what you described. If what you described was right, you get what you need.
The one who's run an operation. They'll question your spec — not because they're difficult, but because they've lived inside the gap between "how we say it works" and "how it actually works." They'll build for the messy version, the 6:45 AM version, the version where someone forgot to scan something and the system needs to not break.
I'm the second one. That's not better or worse — it's a different tool for a different job. If you need a marketing site or a standard e-commerce build, you don't need my background. Hire a specialist and save the money.
But if you're running a real operation — inventory, logistics, scheduling, access-controlled systems, anything where the physical reality is complex and the software has to survive contact with humans who are tired and in a hurry — that's where 14 years on a warehouse floor changes what gets built.
→ See real projects built from operations experience
Matt Ebersole · 20+ years in web and systems development · 14 years managing a 100K sq ft warehouse tracking 900,000+ devices · $300/hr flat · MattCreates.com/contact
Constraints honored
- Credibility-bridge role maintained — CTA hands off to MattCreates.com/contact (no contact form on MattEbersole)
- Real numbers only: 14 years, 100K sq ft, 900K+ devices, 35-50 people, $300/hr flat
- Company name NOT mentioned (anonymized per CLAUDE.md)
- No fabricated testimonials or sub-metrics (no "reduced X by Y%")
- No manufactured urgency
- Anti-SaaS not directly relevant here but ownership philosophy woven in (you own the software you get built)
- "Consultant": 0 mentions — Matt is framed as an operations specialist / builder
- Church name: not applicable
- Honest "you might not need me" section — if a standard build is all they need, he says so