A guy called me last week. Said he wanted "an app for his business." When I asked what it should do, he paused for a second, then said: "You know — like the apps everyone has. Modern. Smart. Easy."
That was the entire brief.
I get this conversation about twice a month. A founder, a manager, an owner — someone with a real business and a real instinct that something needs to be built. They've imagined it for months. They've described it to friends at dinner. They know it'll change everything.
They just can't tell me what it does.
The dream vs. the spec
There's a difference between a vision and a specification, and that difference decides whether your software ships or quietly dies six months in with a blown budget and a stalled team.
A vision is "I want my business to run smoother."
A spec is "When a customer pays, the system marks the invoice paid, deducts the items from stock, emails a receipt, and flags the salesperson for commission."
Both are valid. Only one is buildable.
The vision is yours. It's what you carry around in your head, refined over years of running the business. It's emotional, intuitive, half-formed in places. That's fine — that's how every real idea starts.
The spec is what we put on paper before anyone writes a line of code. Without it, every developer in the room is building something different. Including the one in your head.
"You're the expert, just build it"
This is the line that ends projects.
It usually comes from a smart, busy person who has too much going on to sit through requirements sessions. They think they're delegating. They're actually abdicating.
Here's the problem: I don't know your business. I might know your industry — generally. But I don't know that your top customer pays in two installments. I don't know that one of your salespeople still uses paper receipts because of a 2017 dispute. I don't know that your shipping calculation has six exceptions, or that your inventory is split between two warehouses and one supplier's back room.
You know all of that. The software doesn't. And neither do I — until you tell me.
What a real spec actually looks like
You don't need a 200-page document. You don't need diagrams. You don't even need to use the right words. You need clarity on a small set of things:
- Who uses it — a manager, a cashier, a customer, an accountant? Different users mean different screens.
- What problem it solves — what's broken or annoying today, in one sentence, without naming a feature.
- What happens in the system — the actions, not the buttons. "Customer places order" is an action. "Big green button on the top right" is not.
- What rules apply — discounts, taxes, approvals, exceptions. Every business has these. Yours probably has more than you remember.
- What it replaces or talks to — the Excel file, the WhatsApp group, the ERP, the printer.
That's the minimum. Five questions. Most clients can't answer all of them clearly the first time, and that's completely normal. The point is to find out — before we agree on a price.
Why this is the #1 reason projects fail
It's not the technology. It's not the developer's skill. It's not the budget.
The projects that fail almost always fail the same way: someone decided to start building before everyone agreed on what was being built. Three months in, the client sees the demo and says "this isn't what I meant." The developer points to a chat message from week one. Both are right. Both lose.
The spec isn't bureaucracy. It's the contract you have with your future self about what you actually wanted.
Skipping the spec saves a week at the start and costs three months at the end. I've watched it happen on projects I didn't run. I've watched it happen on a few I did, early on, before I learned to refuse work until the requirements were honest.
The hardest conversation in this business isn't "your project will take longer than you think." It's "we have to stop building, because we don't know what we're building."
What to do before calling a developer
You don't need to write code. You don't need to draw screens. You don't need to know what's technically possible — that's our job, not yours.
You need to spend one quiet afternoon answering four questions:
- What does a normal day look like in the part of the business you want to fix?
- Who does what, in what order, with what tool — today, right now, before software changes anything?
- Where does it break — the part that frustrates you, your team, or your customers?
- What would have to be true for you to look at the new system in six months and say "yes, this works"?
If you can't answer those, that's not a failure. It just means you're not ready to brief anyone yet. A good developer will help you fill the gaps. A great one will refuse to start until they're filled.
