Service Support — Web Development
Website Projects We Turn Down
We turn down web development projects on platform, timeline, ownership, or budget fit — see the exact web development project fit criteria we screen for.
We turn down a meaningful share of the website enquiries that reach us — not on budget size, but on web development project fit. The projects we decline share a pattern: a platform requirement we won’t build on, a timeline that can’t fit real testing, an account structure that locks the client out of their own site, or a scope with no single person positioned to approve decisions. None of that is about being precious. A mismatched project almost always costs the client more in rework and delay than it would have cost to sort out fit before the contract was signed.
Key takeaway
- Most declines aren’t about budget size — they’re about fit signals we check before quoting: platform requirements, timeline, account ownership, and who can actually approve decisions.
- Saying yes to a bad-fit project rarely saves the client money; it usually costs more once the mismatch surfaces mid-build, in the form of rework or a stalled launch.
- The same checklist applies to every enquiry regardless of account size, which is why the answer is consistent whether the prospect is a solo founder or an established company.
Signs A Web Development Project Isn’t A Fit
- Accounts must stay agency-owned — Ownership. Client wants hosting, domain, or analytics kept under our login instead of theirs.
- Platform is locked to a page builder — Platform. Brief specifies Elementor, Divi, or a similar drag-and-drop tool we won’t build on.
- Timeline skips QA and testing time — Timeline. Launch date is fixed but doesn’t leave room for pre-launch checks.
- No single approver for content or structure — Scope. Sign-off is split across people with no agreed decision-maker.
- Budget assumes a template swap, not a build — Budget. Quote expectations match a theme install, not a researched, coded site.
- No plan for what happens after launch — Longevity. No budget or owner named for maintenance, updates, or measurement.
What actually makes a web development project a bad fit?
It’s rarely one single factor. In the enquiries we screen, a decline almost always traces back to two or more of six recurring signals: accounts the client wants kept under our name instead of theirs, a page-builder platform we don’t build on, a timeline with no room for testing, no single approver for decisions, a budget sized for a template swap rather than a coded build, or no plan for what happens after launch. Any one of these alone is often workable. Two or three stacked together is the pattern that tells us the project will fight itself no matter how carefully we run it.
We check for this pattern before quoting, not after signing. A discovery call typically surfaces most of it — asking who owns the hosting account, what platform the client has in mind, and what the launch date is actually tied to (a trade show, an investor deadline, nothing in particular) tells us most of what we need within thirty minutes. See what you need to provide before a build starts for the full list of things we ask for upfront — it’s the same list that surfaces most fit problems early.
Why do we decline projects that require a page-builder platform?
We build in native WordPress blocks or hand-coded templates, and we don’t build client sites on Elementor, Divi, or similar drag-and-drop tools. When a brief specifically requires one of those platforms — usually because an internal team is already trained on it, or the existing site was built that way — we’re not the right shop for that build, and we say so directly rather than take the project and quietly do it our way. Forcing our platform choice onto a client with a considered reason to want a page builder doesn’t serve them; it just creates friction we could have avoided in the first call.
This isn’t a case of one platform being universally wrong. It’s a case of us being consistent about what we can stand behind. A page-builder site can be a reasonable choice for a business that plans to manage every page in-house and isn’t chasing long-term organic performance. Our stack is built for sites meant to load fast, stay lean, and hold up over years of edits and handovers — and we’d rather decline than build something we can’t fully vouch for.
What happens when the timeline doesn’t leave room for testing?
A fixed launch date isn’t automatically a problem — plenty of builds run against a real deadline, a product launch or a funding announcement, and we plan around it. The problem shows up when the date is fixed but the scope isn’t scaled to fit it, so something has to give, and the thing that usually gives first is pre-launch quality assurance. Skipping that step doesn’t just risk minor bugs; it risks broken forms, redirect mistakes that tank existing rankings, and mobile layout issues that only show up on real devices, not a laptop preview.
When we see a timeline compressed this way in an early conversation, we’ll usually propose one of two paths: trim the scope so the remaining work genuinely fits the date, or push the date to protect the QA step. A prospect who insists on both the full scope and the original date, with no flexibility on either, is one of the clearer decline signals we see — because the outcome of that combination is predictable, and it isn’t a good launch.
We’d rather lose the project in the first call than deliver a site we know is going to break in the first month. Declining is cheaper for everyone than the alternative.
Palash, Founder, PalV’s DM
Why does account ownership decide whether we take a project?
We build every site inside the client’s own hosting, domain registrar, and analytics accounts — never ours. When a prospect asks us to keep those under an agency-controlled login “for simplicity,” that’s a decline trigger on its own, no matter how good the rest of the brief looks. A business that doesn’t control its own hosting and domain doesn’t actually own its website; switching providers later becomes a negotiation instead of a formality. We’ve inherited enough sites from exactly that situation to treat it as a hard line rather than a preference. The reasoning behind this policy is covered in building in your accounts, not ours.
This connects to the approver question too. If a project has no single person on the client side who can sign off on content and structural decisions, ownership gets murky in a different way — not of the accounts, but of the decisions themselves. Design and copy reviews stall waiting on committee input, deadlines slip, and the person we’re actually building for keeps changing mid-project. We’ll ask directly, early on, who has final say — and a prospect who can’t answer that question is telling us something about how the rest of the project will run.
What if the budget is smaller than we’d like?
A smaller budget on its own is rarely a decline reason — plenty of projects we take on are lean, scoped-down builds for early-stage businesses. The decline signal isn’t the number; it’s a mismatch between the number and the expectation attached to it. A budget sized for a template install, paired with a brief that expects a fully researched, custom-coded site with SEO foundations built in, tells us the prospect and our pricing model haven’t met yet. The honest move is to explain what the budget realistically buys — sometimes a smaller, phased version of the site — rather than inflating the deliverable or quietly cutting corners to hit it.
Scope clarity up front prevents most of this. What’s included in a complete website build lays out exactly what sits inside a standard build versus what’s an add-on, so a prospect can see where their budget lands before a proposal goes out rather than after.
Does an existing site change how the fit conversation goes?
Yes — when a prospect already has a site, the first fit question isn’t platform or budget, it’s whether they actually need a full rebuild at all. Some enquiries asking for a “new website” are better served by a redesign of the existing structure, or by fixing a handful of specific problems rather than starting over. Recommending a smaller engagement than the one being asked for isn’t a common instinct in this industry, but it’s a more honest starting point than defaulting to the biggest scope on offer. We walk every prospect with an existing site through the same decision framework, laid out in redesign or rebuild: a decision framework, before any proposal is written.
The same logic applies to what happens after launch. A build with no budget or named owner for post-launch maintenance, monitoring, or content updates tends to decay within a year regardless of how well it was built — and we’d rather flag that gap in the first conversation than let a client discover it when the site starts falling behind.
What do we do instead of just saying no?
Declining a project isn’t the same as ending the conversation. We’ll usually explain exactly which fit signal triggered the decline and what would need to change for the answer to be different — a longer timeline, a smaller scope, or a different platform choice. Some prospects come back once those conditions shift: a fixed date passes, a decision-maker gets named, a budget gets revised. Others are genuinely better served elsewhere, and we’ll say that too. The goal was never to filter people out for its own sake — it’s to make sure every project we take on is one we can actually deliver well.
Key takeaway
- A decline is almost never one factor — it’s two or more of six recurring signals stacking together: ownership, platform, timeline, approver, budget mismatch, or no post-launch plan.
- These questions get asked in the first call, not after a contract is signed, so fit problems surface before either side has spent real time on the project.
- A decline usually comes with an explanation of what would need to change — some prospects come back once conditions shift, and that’s a fine outcome too.
See how we scope a website build that’s actually built to fit
Frequently asked questions
Does turning down a project mean the budget was too small?
Not on its own. Budget only becomes a decline factor when it’s mismatched against the expected deliverable — for example, a template-level budget paired with expectations for a fully researched, custom-coded site. Plenty of projects we take on are lean, appropriately scoped builds for smaller budgets.
At what stage do you decide a project isn’t a fit?
Almost always during the first discovery call, before any proposal is written. Questions about hosting ownership, platform preference, launch-date flexibility, and who approves decisions typically surface a fit problem within the first conversation, which is deliberately earlier than after a contract is signed.
Can a declined project come back later?
Yes, and it happens fairly often. If the specific issue that caused the decline changes — a fixed date passes, a decision-maker gets named, the budget or scope gets revised — we’re glad to pick the conversation back up. A decline is a statement about current conditions, not a permanent judgment on the business.
Do these fit criteria apply to redesigns, or only new builds?
Both. Ownership, platform, timeline, approver, budget match, and post-launch planning matter just as much on a redesign of an existing site as they do on a ground-up build — arguably more, since a redesign also has to work around whatever the existing site already has right or wrong.
Are smaller businesses declined more often than larger ones?
No — the same checklist applies regardless of company size. A large company with an inflexible timeline and no named approver gets declined just as readily as a small one with the same problem. Account size doesn’t override the fit signals; the signals themselves are what decide it.
