What We Look for Before Taking On a New Web Project

Not Every Project Is a Good Fit — And That's Fine

Agencies that say yes to everything usually end up doing a mediocre job on most of it. We'd rather turn down a project that isn't a good match than take the money and deliver something that doesn't actually solve the problem. Here's what we're actually weighing when a new project comes in, before we send a proposal.

Do We Understand the Actual Goal?

A surprising number of inquiries start with "we need a new website" and stop there. That's not enough to scope or price a project responsibly. We need to know what the site is supposed to do — generate booking requests, support a paid ad campaign, replace a template site that's become embarrassing, support a rebrand, or something else entirely.

If a prospective client can't articulate the goal past "it should look better," we spend time in the discovery conversation getting to a real answer before we talk about design direction or cost. We go deeper into how that conversation is structured in how we structure a discovery call before starting a project.

Is the Budget Realistic for the Scope?

We're upfront about the fact that a five-page brochure site and a custom booking platform with CRM integration are not the same category of project, even if both start as "we need a website." When budget and scope are far apart, we say so early rather than letting a client discover it three weeks into the project. Sometimes that means recommending a smaller first phase; sometimes it means being honest that the number they have in mind won't cover what they're describing.

We've written more on how quotes actually get built in how we price web development projects — scope and integration complexity move the number far more than page count does.

Do They Have Decision-Making Clarity?

Projects with a single clear decision-maker (or a small group that's already aligned) move faster and end in a better result than projects where every stakeholder has a different opinion and nobody has final say. We ask directly, early on, who signs off on design and copy. It's not about bureaucracy — it's that unclear ownership is one of the most common causes of stalled timelines and revision loops that never converge.

Is There Existing Content, or Does It Need to Be Created?

A website project is partly a design and development project and partly a content project — copy, photography, service descriptions, testimonials if they're real and available. Some clients arrive with all of this ready to go; others need help producing it. Both are workable, but they affect timeline and, depending on scope, price. We ask about this directly during discovery so it's factored into the plan rather than discovered mid-build when a page is sitting empty waiting on copy.

Does the Timeline Match Reality?

"We need it live in two weeks" for a multi-page custom build with integrations is a mismatch we'll flag immediately. Rushing a build doesn't just risk quality — it tends to produce sites with untested forms, missed redirects, or SEO basics skipped because there wasn't time. If a hard deadline is real (an event, a launch date already publicly announced), we scope down to what's achievable in that window rather than overpromise and cut corners quietly. Our usual breakdown of how a timeline is built is in what a website project timeline actually looks like.

Is This a Relationship or a One-Off?

Some projects are genuinely one-off builds — a landing page for a single campaign, a microsite for an event. Most of our work isn't that; it's an ongoing relationship that includes maintenance, iteration, and often marketing work after launch. We try to understand upfront which kind of relationship a client is expecting, because it changes how we structure the engagement, from hosting and maintenance plans to how much post-launch flexibility is built into the agreement.

What We're Not Looking For

We're not looking for the biggest possible contract or the most impressive logo to put on a portfolio page. We're looking for projects where our default approach — custom-built sites, a real discovery process, and honest scoping — actually maps onto what the client needs. If a business genuinely just needs a basic template site with minimal customization and no ongoing complexity, we'll say that plainly, even if it means recommending a lighter-weight option instead of the full custom build we usually default to.

What Happens When It's Not a Fit

Turning down a project isn't a rejection of the business — it's usually a mismatch in scope, timeline, or budget that would set both sides up for a frustrating engagement. When that happens, we try to be specific about why, and where possible, point toward what would need to change (budget, timeline, or scope) for it to work. Being direct about this upfront is a lot better for everyone than discovering the mismatch halfway through a project that's already underway.

Fit isn't about being precious. It's about the fact that good web development work requires a real working relationship between the people building the site and the people who'll run their business on it — and that only works when both sides are aligned from the start.