Most enquiries arrive as a few lines in an email. “Can you quote for a delivery date picker on checkout?” “How much to move the shop to a new theme?” “We need stock to sync with the warehouse. Ballpark?”
I could reply with a number. Plenty of developers do, and I understand why. It’s quick, it feels decisive, and the shop owner asked a straight question. But after twenty years of freelancing, I’ve learned that a quote written from a three-line email is mostly a guess with a pound sign on it.
So I ask for something first: a quick call. Show me the shop, tell me what’s going on, and then I write the quote.
Here’s why, and why it usually works out cheaper for the person asking.
The email is never the whole job
That isn’t because anyone is hiding anything. Shop owners describe the job as they see it from the front of the shop. I need to see it from the back.
Take the delivery date picker. On paper it’s one field. On a call, the questions come naturally. Do some products take longer to make than others? Do you close over Christmas? Is there a cut-off time for next-day delivery? Does the date need to show on the packing slip, the order email, the courier label? Are there postcodes you don’t deliver to?
Each answer can change the job. Some make it smaller. Some make it bigger. All of them are things I’d rather know before I put a number on paper than discover halfway through the build.
That’s scope you only find by talking. I could send a form with twenty questions, and some people would fill it in. But a conversation finds the bits nobody thinks to write down, because to the owner they’re not features. They’re just “how we do things”.
The request isn’t always the problem
The second reason is subtler. Quite often, the thing someone asks for is their best guess at a solution, not the problem itself.
Here’s an illustrative example, pieced together from the kind of enquiry I see regularly rather than one particular client. Someone asks for a quote to build a custom report of orders by postcode. On the call, it turns out the real issue is that their courier keeps struggling with one remote area, and they want to catch those orders before they ship.
That might need a report. It might need a shipping zone, a short checkout notice and a tag on the order, which is a fraction of the work. Or there might be a plugin that already does it well, and all they need is an hour of setup.
If I’d quoted for the report, I’d have built a good report that didn’t fix their problem. They’d have paid for it, and been no better off.
What a guessed quote costs you
When a developer quotes without enough information, there are two ways to go, and neither is great for you.
They can pad it. Add a cushion for the unknowns, so if the job turns out bigger, they’re covered. You pay for the cushion whether it was needed or not.
Or they can quote tight and deal with the rest later. That’s where “ah, that’s out of scope” comes from, along with the extra invoice and the awkward conversation two weeks in, when the budget’s already spent.
A quick call replaces most of the guessing. I don’t need to pad for things I’ve already asked about. And the “while you’re in there, could you…” requests come up on the call, where they can be priced properly, instead of in the middle of the build.
What happens on the call
It’s informal, but there’s a rough shape to it.
- You tell me what’s wrong, or what you want, in your own words. No jargon needed.
- We look at the shop together if that helps. You can share your screen, or I’ll look at the public site while we chat. I don’t need logins at this stage.
- I ask the awkward questions. Deadlines, busy periods, what’s been tried already, who else has worked on the site, which plugins are involved.
- I tell you honestly what I think. Sometimes that’s “this is a small job”. Sometimes it’s “a plugin will do this better than custom code”. Now and then it’s “I’m not the right person for this”, and I’ll say so.
The call is with me. I take all my client calls myself. There’s no salesperson or account manager in the way, and the person asking the questions is the person who’ll write the code.
What you get afterwards
After the call, I write up what I heard, what I’m proposing, and a fixed quote for that piece of work.
If part of it can’t be pinned down yet, such as a bug nobody can reproduce or an old integration nobody has documentation for, I’ll say so plainly. Then I’ll suggest either a small, separate investigation first or an hourly estimate for that part.
Having it written down means you can check it. If I’ve misunderstood something, it’s cheap to fix in the quote. It’s expensive to fix in the code.
No obligation, genuinely
The call is free and it doesn’t commit you to anything. Some people come away with a quote and go ahead. Some realise the job is smaller than they thought and do it themselves. Some decide it can wait until after Christmas. All of that is fine.
I’d rather spend a quick call and not get the job than take on a job I’ve misunderstood. Misunderstood jobs are the ones that run over, get tense, and end with nobody happy.
Why a quick call and not a sales pitch
The call is an informal conversation: two people talking about a shop, not a pitch. You don’t need to prepare anything. Bring a list of things that bother you about the site if you have one. A vague feeling that checkout could be better is a fine place to start too.
Book a call
If you’ve got a WooCommerce job in mind and you’d like a quote you can actually rely on, book a free consultation call with me. Pick a slot that suits you, add a line or two about your shop, and we’ll take it from there.
If you’d like to know more about the kind of work I do first, have a look at how I work with WooCommerce shop owners.
Written by Connie, an AI, from Neil Matthews’ notes, archive, and direction. Neil directed and edited this piece. He did not write these words. Augmented publishing by Neil Matthews.