Every system has a gap. Sometimes that gap is a missing feature or a bad integration. Sometimes it's something so obvious that nobody thought to question it.
Ours was this: nobody was following up on customers who didn't pay their bill.
Not because anyone was negligent. Not because anyone made a bad decision. It just fell through the cracks. Our CRM tracked everything — events, payments, customer interactions, the full lifecycle of a client relationship. But when a payment didn't come in, nothing happened. No flag, no follow up, no process. It was just assumed the money would show up eventually.
It didn't. And when someone finally noticed, we had delinquent accounts spanning years.
So we built something.
---
I'm fully remote. I've been remote for a long time and I'm good at it. But when I understood the scope of what we needed to build — a system that would track unpaid balances against payment schedules, manage communications between accounts receivable and clients, connect our payment processors and accounting, and give everyone one cohesive place to actually collect what we were owed — I made a decision.
I went to the office.
Not because I had to. Because it was the fastest path to getting it right.
We spent eight hours in a room together. Stakeholders, pizza, notebooks. The kind of session that's equal parts exhausting and clarifying. I wasn't just taking notes — I was stress testing every requirement in real time. Asking what happens when this edge case hits. Asking what the exception looks like. Asking what we're assuming that we shouldn't be.
That's where the gaps show up. Not in the requirements document. In the room, when someone says "well obviously it would work like this" and you say — would it though?
One of those moments changed the whole collection process. We use Authorize.net as our payment processor, and I caught that we weren't taking advantage of a feature we were already entitled to — storing cards on file for future payments when clients had agreed to it. For a business that runs on a deposit and final payment model, that gap was making collection significantly harder than it needed to be. We fixed it before a single line of code was written.
That's the thing about requirements sessions done right. You're not just documenting what people want. You're finding what they didn't know they needed and what they didn't know was broken.
---
The build took about a month. It was fast and intense and it worked almost immediately.
Were there changes after deployment? Sure. Usability tweaks, edge case exceptions, the normal things. But there was no scope creep. No fundamental rethinking. No discovering halfway through development that we'd built the wrong thing. Because we'd already had that conversation — we'd just had it in a conference room over pizza instead of in a GitHub issue three weeks into the sprint.
We have since collected on hundreds of accounts. Some of them years old. Money that was just sitting there because there was no system to go get it.
The system works. But the reason it works isn't the code.
It's the eight hours before the code.
---
If there's one thing I'd tell any developer or technical lead about to scope a complex internal tool: don't underestimate the requirements phase. Not as a formality. Not as a box to check before the real work starts. As the actual work.
Get the stakeholders in a room. Ask the uncomfortable questions. Find the gaps before they find you.
The code is the easy part. Knowing exactly what to build is the hard part. And it's worth every hour you spend on it.
June 5, 2026