Why I Don't Take Meetings (and Why My Clients Prefer It)

I don't take discovery calls before starting a project. Instead, I use a structured brief that covers everything a 60-minute call would — faster to complete and permanently on record. Most clients tell me it's a relief.

Why Most Web Developers Default to Discovery Calls

"Jump on a 30-minute call" is so standard it feels like the professional way to start a project. But the call isn't for your benefit. It's a workaround for a developer who hasn't built a proper intake process.

A Call Is Easier Than Building a Good Intake Process

When a developer doesn't have a structured brief, they ask questions live. You don't have the answers ready, the developer can't reference the conversation later without notes, and key decisions get forgotten or contradicted during the build.

A brief forces both sides to think clearly. You write what you need. I read it, ask specific follow-up questions in writing, and reference it throughout the project.

What Gets Lost in a 60-Minute Kickoff Call

Most kickoff calls cover the same ground a brief would — just slower. You spend 10 minutes on pleasantries, 20 minutes explaining your business, and 10 minutes on vague agreement about "the feel" of the site. Very little of it gets captured in a format anyone can build from.

If you write it down instead, you spend 15 minutes and I have something I can actually use.

What a Brief-First Process Actually Looks Like

You fill in the brief at /start. I review it and come back with a scope, a price, and a timeline — usually within 24 hours.

If I need more detail on anything, I ask specific questions in writing. You answer when it suits you, not at a time we both had to schedule around.

How the Brief Replaces the Kickoff Call

The brief covers what you're building, who it's for, which features you need, what assets you already have (logo, copy, domain), and what a successful outcome looks like. That's the same ground a kickoff call covers — written down and permanently on record.

I published the brief template I use if you want to see what it covers before you fill it in.

There's no specific time you need to be free. Everything you said is in the brief — easy to reference when the build starts.

What Happens After You Submit

Once scope is agreed, I send a project breakdown with line items, a timeline, and the first invoice. The project starts. All communication runs through a written project thread — threaded, searchable, and there whenever you want to read it.

If something genuinely needs a real-time conversation, I offer a 30-minute scheduled text session. Most projects never need it.

Is It Normal to Hire a Web Developer Without a Call?

For most agencies and freelancers, no — calls are the default. For async-first developers, it's standard practice.

The question worth asking is: what does the call actually accomplish that a brief doesn't? "It helps us get to know each other" isn't a project requirement. And if the goal is for the developer to understand what you need, a brief does that better — and it's on record.

Some clients are initially nervous about starting without speaking to anyone first. That's understandable. By the time scope is agreed, you have everything in writing and know exactly what you're getting — which is more reassurance than most calls provide.

How Async Communication Works Throughout the Project

Every project runs through a written project thread. I post updates when stages are complete, ask questions when something needs clarifying, and share previews for feedback.

You respond when you have time. No pressure to reply immediately. No scheduled check-ins to block out your calendar.

Where Decisions Get Made (and Documented)

All decisions happen in writing inside the project thread. No confusion about what was agreed, no "I thought we said..." moments later, and a clear record of every change request.

If scope changes, I reference the original brief. If you need to revisit a decision made in week two, it's right there.

What Happens When You Need to Talk in Real Time

If a project reaches a point where a real-time conversation is genuinely useful — usually during prototype feedback or a significant scope change — I offer a 30-minute scheduled text session. Both of us online at the same time, in writing.

No audio, no video, no "can you hear me?" No transcript needed — the conversation is already in the thread.

Why Solopreneurs Prefer the No-Meeting Approach

Most of my clients are running their business at the same time as building it. They're not free for calls during business hours. They're across different time zones, working odd hours, or in the middle of a client job when they want to check on progress.

Async communication means they engage on their schedule. A question about the nav structure goes into the thread at 11pm and gets a proper response the next morning — not a voicemail nobody actions.

Every message has a purpose. That's a feature, not a flaw.

Does No Meetings Mean Less Communication?

No — it means more useful communication. A written thread with 40 messages is more informative than four calls where half the conversation was scheduling the next one.

Every exchange is purposeful and documented. You can read back through the entire project history in 10 minutes. Clients say they felt more in the loop on async projects than on projects with weekly calls — because the thread is always there, not locked inside someone's notes.

How to Start a Web Project Without a Discovery Call

Fill in the brief at /start. It takes about 15 minutes.

I'll review it and come back with a scope, price, and timeline. If I have questions, I'll ask in writing. You'll know exactly what you're getting before anything starts — no call required.