A guy reached out yesterday. Accountant, works remotely for a business in Africa. Needed a custom tool to make his workflow better. Solid use case, smart person, real problem.
Then he asked: "Can you show me something similar you've done for this domain? Some samples, maybe a demo?"
I told him: I'm not a cloth shop.
He paused. I explained. This post is that explanation.
The cloth shop vs. the tailor
When you walk into a clothing store, you browse a rack. You find something close to what you want, try it on, decide if it fits, and buy it. The product already exists โ you're just choosing which one.
A tailor works differently. There's no rack. You walk in, they measure you, ask questions โ your height, your build, the occasion, how you like things to fit. Then they build something that didn't exist before. For you. Specifically.
Custom software development is the tailor. Not the store.
When someone asks me to show samples of similar work so they can evaluate, they're thinking store. They want to browse the options, check the quality, pick the closest match. But there's no rack. The thing I'd build for you doesn't exist yet โ that's the entire point.
Why samples from other clients don't help you
I've built accounting tools before. Financial dashboards, reconciliation systems, audit reporting modules. None of it tells you anything useful about what I'd build for you.
Here's why: an accountant managing payroll for a 200-person manufacturing company has a completely different workflow than an accountant reconciling multi-currency transactions for a trading firm. Same job title. Completely different software. The domain overlaps โ the problem does not.
What I built before was designed around someone else's workflow, someone else's edge cases, someone else's team. Even if I could show it to you โ which I can't, clients don't share their internal tools with strangers โ you'd be looking at the wrong thing. A suit made for someone else's body.
What the process actually looks like
You tell me what you need. Not technical specs โ just what your day looks like, what you're trying to do, and what's broken or missing right now. I ask questions. A lot of them, probably. Some will seem obvious. Some will make you think about things you hadn't considered.
Then I go away. I study the problem โ the scope, the architecture, what it actually takes to build this, what the risks are, how long it realistically takes. I come back with a proposal: what I'll build, how long, what it costs.
That's the process. Discovery, then proposal. Not browsing, then checkout.
The process is the sample. How I ask questions, whether I understand your domain, whether I come back with something that reflects what you actually described โ that's the proof of whether I can do this.
Why this protects you too
The guy asking for samples wasn't being unreasonable. He wanted to know if I can actually build what he needs before he commits time and money. That's a completely fair thing to want.
But samples from other projects don't answer that question โ not for a custom build. What answers it is how I engage in the discovery conversation. Do I ask the right questions? Do I understand the domain? Does my proposal reflect what you actually described, or is it a generic document with your name on it?
A developer who shows you impressive demos but can't ask good questions about your specific situation is the wrong person for this. The portfolio isn't the proof. The conversation is.
And honestly โ if a developer hands you samples of other clients' systems before asking you a single question about your business, that's a red flag, not a selling point.
