What a Discovery Call Actually Needs From You Before We Can Scope a Project

Why we don't quote a price before we've talked to you

If you've booked a call with us, you might have noticed something: right after booking, you get a rough architecture outline — but no price. That's deliberate. A specific dollar figure generated from a form, before anyone has actually spoken to you, isn't a quote. It's a guess wearing a quote's clothes. We'd rather show you an honest starting point and give you a real number after an actual conversation than hand you a confident-looking figure that has no relationship to what your project will actually cost.

That means the discovery call itself is doing real work — it's not a formality before a sales pitch. Here's what it actually needs from you to be useful.

The problem, in your own words

The single most useful thing you can bring to a discovery call is a plain description of what's actually going wrong today. Not a solution — a problem. "We track jobs in six different spreadsheets and nobody can tell which ones are overdue" is more useful to us than "we need a dashboard," because it tells us what the system actually has to solve, rather than what it should look like.

If you already know you want specific features, tell us — that's useful context. But don't worry about arriving with a fully-formed spec. Most of the businesses we've built systems for came to the first call knowing something was broken, not knowing exactly what the fix should be. That's normal, and it's our job to help translate the problem into an architecture, not yours.

Who's actually going to use it

A system that works for the person who commissioned it but not for the people using it every day fails quietly, over months, as workarounds creep back in. So we want to know: who are the actual users? A field technician checking a job on their phone has completely different needs from an office admin reconciling invoices, and both are different again from an agency partner who should only see a fraction of what's in the system.

If your business has multiple types of users — customers, staff, partners, contractors — knowing that early shapes the whole architecture, including things like role-based access that are much harder to bolt on after the fact than to design in from day one.

What "done" looks like to you

This is the question people are least prepared for, and it's often the most important one. "Done" doesn't mean feature-complete — it means the specific outcome that would tell you the project worked. Fewer overdue jobs? Less time spent on manual data entry? A number your business actually tracks going up or down?

Vague answers here ("just make it better") lead to vague scoping, which leads to a project that technically ships but doesn't actually solve the problem it set out to solve. A concrete answer — even a rough one — gives us something real to build towards and check the finished system against.

Your timeline and budget reality — even if it's not what you think we want to hear

Tell us your actual constraints, not what you think sounds reasonable. If you need something working in six weeks because of a specific deadline, that shapes what we recommend building first. If your budget is tighter than the scope you're imagining, we'd rather know that on the first call and help you sequence the build — core workflow now, extras later — than find out three weeks into a project that's already been scoped too big.

We're not going to talk you into a bigger project than you need. A smaller system that actually gets used beats a bigger one that gets shelved halfway through.

What happens after the call

Once we've talked, you get a real proposal — not the automatic starting-point brief from the booking form, but a scope, timeline and price based on an actual conversation about your business. That's the document that means something, because by the time you see it, we've actually listened to what you need.

Ready to have that conversation? [Book a 30-minute call](/contact) — no pitch, just a real discussion about where things are stuck and whether a system would fix it.