What to tell your builder
about your business.
Most first calls go badly because the owner arrives with nothing a builder can use. Here is exactly what they need — and how to pull it together in an hour.
A builder's first call with an owner usually goes one of two ways. In the first version, the owner describes their business in broad strokes, the builder asks a lot of clarifying questions, and an hour passes without anything being decided. In the second version, the owner arrives with specific information and the builder spends the call designing rather than excavating.
The second version produces a better build, faster, for less money. The difference is not technical knowledge. It is preparation. Here is what to bring.
The one thing a builder actually needs to understand.
A builder is not trying to understand your business in the way a consultant would. They are trying to understand one specific thing: where does information arrive, what happens to it, and where does it need to end up?
Everything else — your history, your clients, your growth plans — is background. Useful background, but background. The question that drives every build decision is: what flows in, what should happen to it, and what should come out the other side?
If you can describe that clearly for the part of your business you want to improve, you have given the builder most of what they need.
Sandra · Solo immigration lawyer — she came to her first call with a single page describing how a new client inquiry turned into an opened file. Seven steps. The builder had enough to scope the project by the end of that call.
Five things to write down before the call.
You do not need a formal document. Notes on a phone are fine. The point is to have thought through these before the call, not to produce a report.
- The task that costs you the most time. Be specific. Not "admin" — "writing follow-up emails after client consultations." The more specific, the faster a builder can tell you whether an automation can take it over.
- Where the information for that task comes from. Email? WhatsApp? A form on your website? A voice memo you record in the car? The source matters because the builder has to connect to it.
- Where the output needs to go. Into an email draft? A Google Doc? A calendar entry? Your accounting software? Naming the destination is half the technical specification.
- What tools you already use. A list of every piece of software your business touches daily. Email provider, calendar, accounting app, CRM if you have one, any industry-specific tools. A good builder uses what you have rather than selling you a new stack.
- What cannot go wrong. Is there a type of error that would cost you a client, or create a compliance problem, or damage your reputation? Name it explicitly. A builder who knows the failure modes can build around them.
What you do not need to prepare.
You do not need to know anything about how the technology works. You do not need to understand what an API is, how AI models are trained, or what the difference is between a cloud and a local build. That is the builder's job. Your job is to describe the work.
You also do not need to have already decided what you want built. Arriving with "I want an AI that does everything" is fine as a starting point — it just means the first call will be spent narrowing, not designing. Arriving with the five things in the previous chapter is better.
You do not need a budget figure either, though having a rough ceiling in mind saves time. "I have no idea what this costs" is an honest answer and a builder worth hiring will give you a range before asking you to commit to anything.
The fifteen-minute exercise that replaces three calls.
Before your first call, do this once. It takes fifteen minutes and it will make every conversation with every builder you speak to sharper.
Pick the one task you most want an automation to take over. Walk through it as if you were explaining it to a new employee on their first day. Say out loud — or write down — exactly what you do, in order, from the moment the task starts to the moment it is done. Include the tools you touch, the decisions you make, and the things you check before you consider it finished.
That narration is a workflow description. It is the most useful thing you can hand a builder. More useful than a brief, more useful than a slide deck, more useful than an hour of back-and-forth on a call.
James · Building surveyor — he recorded a three-minute voice memo walking through how he turned a site visit into a client report. His builder listened to it twice and had a fixed-price quote ready the next morning.
Red flags in how a builder responds to what you bring.
-
Doesn't ask any follow-up questions about the workflow.
A builder who hears your workflow description and jumps straight to proposing tools hasn't understood the work. The workflow should prompt questions, not a sales pitch.
-
Tells you the tools before understanding the task.
If the first thing out of their mouth is a list of platforms they use, they are fitting your business to their preferred stack rather than the other way around.
-
Doesn't ask what cannot go wrong.
Every build has a failure mode that matters more than the others. A builder who doesn't ask what yours is hasn't thought about what they're taking responsibility for.
-
Treats your existing tools as a problem to replace.
If you use Gmail and Google Sheets and a builder immediately suggests switching to different tools, ask why. The answer should be specific and technical. "Better" is not an answer.
The short version.
A builder needs to know what task you want automated, where the information comes from, where the output needs to go, what tools you already use, and what cannot go wrong. Everything else is useful context. Fifteen minutes of preparation before a first call will save you three weeks of back-and-forth afterwards.
If you want to send me what you have and get a reaction before a first call, email below. I will tell you whether it is enough to scope something from.