By Rami F. Community Manager, B2S · Updated September 15, 2026 · Reading time: 7 min
💡TL;DR : Most website projects don't fail because of bad design or bad code. They fail because an agency agreed to build something before anyone understood why it had to exist. Specifications written too late, no real user research, a scope validated before the objective is clear, person responsible for the architecture once the site is online. None of these are execution issues. These are sequencing issues, and the quickest way to spot them is to see if your agency asks the right questions before requesting a deposit.
The context: why this question comes up more and more
No-code tools and AI page builders have made getting online faster than ever. A landing page that took three weeks can now be assembled in an afternoon. This is actually helpful, and it's also why worthwhile agencies are now judged less on how quickly they get started, and more on their ability to slow you down first.
Execution speed has ceased to be the bottleneck for a while now. What hasn't changed is the sequence that determines whether the final site actually serves any purpose for the business: understanding who it's really for, defining what should happen once someone lands there, and knowing who is responsible for decisions once the site is live. Skipping this sequence and building quickly only means one thing: making mistakes quickly and expensively.
The problem with agencies jumping straight to design
An agency that says “yes” quickly and opens Figma on the first call may seem effective. In practice, this speed hides a series of blind spots which are revealed later, once the bill has already been paid:
Vague specifications remain a major historical cause of project failure. The Standish Group's original CHAOS report (1994) showed that only 16.2% of projects were delivered on time, on budget, with all planned features, while 52.7% were "compromised" and 31.1% never reached production. More recent editions of the same report show a clear improvement over the decades (around 30 to 37% success in the years 2010-2020), but the root cause identified as early as 1994, incomplete or poorly defined requirements and a lack of user involvement, remains cited as the number one risk factor even today.
A vague brief is information that you have before construction, not after. When a launched site doesn't convert, the root cause almost always goes back to a question no one asked in week one. The information needed to avoid it existed all along; it was simply never collected.
Too quick a “yes” often means the agency is optimizing for the down payment, not the outcome. Invoicing starts as soon as work begins. Asking difficult questions slows down the sale and risks scaring away the client, so weaker agencies jump straight to the deliverables.
Late fixes are significantly more expensive than early fixes. Boehm and Basili's (IEEE Computer, 2001) peer-reviewed analysis of large software projects showed that correcting a problem after delivery often costs about 100 times more than correcting it during the specifications and design phase, although on smaller, less critical projects this ratio is closer to 5 to 1. In all cases, the direction is the same: a poorly understood objective costs the least to correct in the first conversation, and becomes more expensive every week that passes.
None of this means we shouldn’t build. That means don't let anyone build the wrong thing for you, confidently and on time.
What an agency that asks questions first really brings
A quicker and cheaper way to find out if the brief is wrong. A short discovery conversation only costs time. Redesigning a site after its launch costs real budget and real momentum.
A brief that survives the meeting with a second interlocutor. When an agency interviews you correctly, the resulting scope reflects the company, not just the person on the call. This is the difference between a site validated once and for all and a site re-discussed at each meeting.
A plan for compromise, not just a "yes." Every project involves shortcuts somewhere, a launch date, a budget ceiling, a choice of platform. The difference between a manageable compromise and a costly compromise is if someone said it out loud before building, instead of finding it out in a meeting three months later.
Someone responsible for the site once it's live. Agencies that treat a site like a shipped deliverable, not a living asset, typically leave no one responsible for what happens next. Worthwhile agencies assign this responsibility from the first conversation.
Quick “Yes” vs. asks questions first: the comparison
Criteria | Agency that jumps straight to design | Agency that asks questions first |
|---|---|---|
Delay before seeing something | A few days, often from the first call | A structured discovery conversation first |
Risk that the brief is false | High, exposed only after delivery | Spotted and fixed before a single screen was built |
Cost if management needs to change | High, design and dev work is already swallowed up | Weak, a brief is easily revised, a construction not |
Who is responsible for the site after launch | Often blurry, or no one | Defined from the first conversation |
Best suited for | A request already validated and well-framed | The majority of real site projects and first commitments |
Bottom line: starting fast is not the problem. Building with confidence on a brief that has never been examined, and only realizing it once the bill is paid, that's it.
You don't know what your next web agency should ask you? Talk to our team → for a free 20-minute diagnosis.
How to evaluate an agency: the questions that matter
Before signing with anyone, check to see if they raise these five points, without being asked:
What should this site TO DO for your business? Not what it should look like. If the answer remains visual, the strategic work has not yet taken place.
Who will actually visit it, and what must these people believe before they act? A site designed for “everyone” is a site designed for no one in particular.
What happens right after landing on the home page? If no one can answer in one sentence, the site doesn't have a mission yet, it just has an appearance.
What has already been tried, and why didn't it work? An agency that doesn't ask this question is setting itself up to replicate a decision that you already know doesn't work.
How will we know if it works? Without an associated number, “success” becomes the opinion of the person who speaks the loudest in a meeting.
Our experience at B2S
At Be To Solutions, we see ourselves as a co-pilot for ambitious projects, not just an execution service provider. Our process takes place in four stages: Digital Audit (a complete reading of the existing), Strategy & Roadmap (a prioritized action plan with concrete milestones), Management & Monitoring (operational support during execution), and Optimization & Evolution, once the site is delivered, we do not disappear. We measure performance, collect real user feedback, and continue iterating.
On the projects that we have supported, site redesigns, product launches, platform constructions, the pattern repeats itself: sites that struggle almost never fail in terms of quality of execution. They fail because no one asked the founder Why before asking What, and the resulting brief answered the wrong question from the start.
You don't know if your brief is ready to be built, or if it needs a real discovery phase?
Discover our offer Digital Expert for end-to-end support, from audit to execution.
FAQ
What if an agency asks few questions but has a solid portfolio?
A strong portfolio proves that she knows how to execute someone else's brief well. That doesn't prove that she will spot if your brief is wrong. Ask what discovery process produced their best case study, a credible agency will be able to describe it precisely, not just say "we made a launch call."
How long should a real discovery phase last?
For most business sites, a few focused conversations over 1-2 weeks is enough, not months. The goal is a written brief that you both agree on, not a never-ending research project.
Isn't asking lots of questions just a way to bill for more hours?
It shouldn't cost you anything extra to be interviewed properly before a proposal, it's part of the normal framework of the work, not a separate paid phase. Be wary of agencies that only start asking questions once the contract is signed.
What if I don't have clear answers to their questions yet?
This is normal, and that’s exactly what a good discovery conversation is for. The problem isn't not knowing yet, it's an agency that doesn't notice that you don't know yet, and builds anyway.
Does this apply to a redesign, or only to new sites?
Both, and probably even more so in the redesigns. A site that already exists comes with data, what converts, what doesn't convert, why the previous version wasn't enough. An agency that skips questions about an overhaul ignores evidence that is already there.
Sources
The Standish Group, CHAOS Report (1994): 16.2% successful projects, 52.7% "compromised", 31.1% canceled, with incomplete requirements and lack of user involvement as main causes. Synthesized in Five Jars, The Hidden ROI of Discovery Phase in Software Development : fivejars.com/insights/the-hidden-roi-of-the-discovery-phase-in-software-development
Michael Arcidiacono, Comparative Research on IT Project Failure Rates: A 2025 Longitudinal Update, PM World Journal, January 2026: Standish Group 2020-2024 data showing a stable failure rate around 19% and a rate of "compromised" projects above 50%, three decades after the original 1994 report: pmworldjournal.com/article/comparative-research-on-it-project-failure-rates
Engprax / Junade Ali, 268% Higher Failure Rates for Agile Software Projects, Study Finds, May 2024: Study of 600 software engineers in the UK and US showing that clear requirements before development begins increase a project's chance of success by 97%: engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds
Barry Boehm and Victor Basili, Software Defect Reduction Top 10 List, IEEE Computer, January 2001: Correcting a problem after delivery costs about 100 times more than during the specifications and design phase on large projects, compared to about 5 times more expensive on small, non-critical projects. Full article available here: cs.umd.edu/~basili/publications/journals/J81.pdf