Skip to content
Process · · 7 min read

What actually happens on a discovery call?

Most people reach out expecting a sales pitch. Here's what we actually do instead — and what you should look for from any developer you're vetting.

You've sent an email. You've described what you do and what you think you need. A call is scheduled. Now what?

If you've never hired a developer or studio before, the first real conversation can feel a little opaque. You're not sure what you're supposed to prepare. You're not sure what they're going to ask. And you're definitely not sure if you'll be able to tell the difference between someone who actually understands your problem and someone who's just good at sounding like they do.

Here's exactly what happens on our discovery calls — and, more usefully, what to look for on anyone's.

Before the call: what we already did

When you send that first email, we don't just add you to a calendar. We look at your current site (if you have one), run a quick audit of the basics — page speed, mobile behavior, SEO fundamentals, hosting setup — and try to get an honest read on where things stand before we ever get on the phone.

We also read your email carefully. Not to pre-build a proposal, but to start mapping the gap between what you said you want and what you might actually need. Those two things are often related but rarely identical.

The goal of the call isn't to sell you something. It's to figure out whether there's a real problem we're the right people to solve.

The first ten minutes: we mostly listen

The call starts with a version of: "Tell us what's going on."

That's not a throwaway opener. The way you describe your business, your frustrations, and your goals tells us more than any intake form could. We're listening for a few specific things:

  • What's actually broken? Sometimes the problem is the website. Sometimes the problem is a workflow that the website can't fix. We need to know the difference before we scope anything.
  • Who uses the thing we'd build? Your customers? Your staff? Both? The answer reshapes the entire project.
  • What have you already tried? A lot of people who reach out to us have already been through one or two rounds of something — a template, a freelancer, a page builder — that didn't work. Understanding why it didn't work is often more important than understanding what you want next.
  • What does success look like? Not in vague terms like "a better website." In specific terms: more leads? Fewer manual steps? A thing your staff will actually use? We need a target that isn't just "nicer than what we have."

The questions we ask (and why)

After you've described the situation, we start asking questions. Some of them will feel obvious. Some might feel unexpected. Here are a few examples:

"Walk me through what happens when a new customer contacts you right now."

This is the single most important question we ask, and the one most developers skip. We're not asking about your website — we're asking about your business. The website (or app) we build has to slot into the way you actually work, or it'll sit there unused like the last one.

"What are you doing in spreadsheets or on paper that you wish was automated?"

This is where we figure out whether you need a website, an application, or both. A lot of businesses think they need a new site when what they actually need is a tool that handles intake, scheduling, or tracking — and the site is just the front door to that tool.

"Who on your team would be managing this after launch?"

If the answer is "nobody technical," that changes how we build it. If the answer is "me, but I don't want to spend more than ten minutes a week on it," that changes it differently. We're not going to hand you a system that requires a developer to update a phone number.

"What's your timeline, and what's driving it?"

There's a big difference between "we'd like to launch this quarter" and "our lease is up in six weeks and we need the new location's site ready." Both are valid. But the second one changes what we can realistically scope, and we'd rather have that conversation now than three weeks in.

"What's your budget range?"

We ask this directly because it saves everyone time. We're not trying to anchor to your number — we're trying to figure out if the project you're describing fits inside the budget you have. If it doesn't, we'll say so, and we'll either help you cut scope to fit or tell you honestly that we're not the right option at that price point.

What we don't do

We don't present a deck. We don't show a portfolio of unrelated work and hope something resonates. We don't quote you a price on the call. And we don't say yes to everything.

If we think you don't need a custom build, we'll say that. If we think a $300 Squarespace site would solve 80% of your problem, we'll say that too — and we'll tell you exactly how to set it up. We turn down projects regularly, and we refer people to other developers when the fit isn't right.

That's not altruism. It's practical. A project that shouldn't have been custom in the first place turns into a bad experience for both sides. We'd rather lose the work than build something that doesn't make sense.

After the call: what happens next

If it seems like a fit, we'll send you a short summary of what we heard — not a proposal yet, just a recap to make sure we understood you correctly. This is where misalignments surface early and cheaply.

If the summary looks right, we move into scoping: a written proposal with a clear description of what we'd build, what it would cost, and how long it would take. No surprises. No vague "it depends" pricing. A fixed scope and a fixed price for that scope.

If it doesn't seem like a fit — budget, timeline, type of project — we'll tell you on the call. No ghosting, no "we'll get back to you." You'll know where you stand before you hang up.

What to look for from any developer

Whether you end up working with us or someone else, here's what a good discovery call should feel like:

  • They ask more than they talk. A developer who spends the first call telling you what they'd build hasn't understood the problem yet.
  • They ask about your business, not just your website. If no one asks how a lead gets from your site to your inbox, they're designing a brochure, not a business tool.
  • They're willing to say no. A studio that says yes to every project is either desperate or planning to hand you off to a junior you've never met.
  • They give you a straight answer on budget. "It depends" is fine for early conversations, but if you can't get a ballpark after a 30-minute call, something is off.
  • You don't feel sold to. A discovery call should feel like a conversation with someone who's trying to figure out if they can help — not someone trying to close.

Ready to have one?

If you've been putting off the call because you're not sure what to expect — now you know. A short email describing what you do, what you need, and a rough timeline is all it takes. We'll do the rest of the homework before we ever get on the phone.

You can reach out here, or if you want to understand the kind of work we do first, start with our custom website projects or business application builds.

Layer Logic Studio is an independent New York area studio. We build custom websites and business applications for small businesses that want something built around how they actually work — not around a template.