Should you have to tell your web vendor what to do?
You should have to tell them what you need and why, not how to build it. Say the request is a FAQ section: an expert takes that, asks about the goal, and comes back with a designed recommendation. A ticket-taker comes back with a questionnaire: how many items, what layout, what goes in each. The moment every request bounces back as 'tell me exactly what you want,' you've stopped hiring judgment and started doing the design work yourself, at your own expense, on top of the invoice.
What it usually means
The distinction underneath is what the vendor believes they sell. An expert sells outcomes: give them 'buyers keep emailing us the same six questions' and they return a structure, a layout, and reasons. A production shop sells execution: they build exactly what you hand them, competently, and the handing is your job. Both are real businesses. The problem is being billed like the first while working with the second, because then the gap between goal and specification, which is most of the actual expertise, is being closed by you.
The innocent explanation is common: plenty of vendors were trained into spec-taking by clients who insisted on dictating everything, or they priced the work as pure build time and never claimed to design. Neither makes the arrangement wrong; it makes it mislabeled, and the confirm steps below establish which one you have.
The cost compounds in a way that's easy to miss: when you write the specs, the website's ceiling is your own web-design knowledge. You hired expertise precisely because you don't do this all day, and yet every grid count, field choice, and layout call is yours. The expert you're paying for never actually shows up in the work.
What it costs while it stays this way
The visible cost is your time: every new section becomes a specification document you were never supposed to be writing, and requests sit unmade because nobody on your side has the hours to design them first. The less visible cost is that the site converges on what your team already knows to ask for. Improvements that require web expertise to even imagine, the ones an expert would have proposed unprompted, never enter the queue at all, and the site quietly accumulates the technical debt nobody was watching for.
There's also a quality cost with a mechanism. When the vendor executes your spec, nobody in the loop is responsible for whether the thing works: you weren't qualified to design it, and they'll point out it's exactly what you asked for. Outcome ownership quietly falls between the two of you, and 'we built what you requested' becomes the answer to why the new section isn't producing anything.
And the pricing stops making sense. Expert rates are justified by judgment; execution rates are lower for a reason. If you're supplying the judgment and paying rates that assume they are, you're overpaying by exactly the difference, on every project, indefinitely.
How to confirm it yourself
- Replay your last request for something new. Find the email where you asked for a new section, page, or feature. Read what came back first: questions about your goal and your buyers, or a questionnaire asking you to specify layout, counts, and contents? The first reply is the diagnosis in one artifact.
- Count who made the design decisions. For the last thing they built, list the real decisions: structure, what's displayed, how many, in what order, what it looks like on a phone. Mark each one yours or theirs. A vendor whose column is empty built it; they didn't design it.
- Look for anything you didn't ask for. In the last delivery, find one thing that wasn't in your request: a suggestion, a caught problem, a better structure than you specified. Its presence is judgment showing up; its absence, across several projects, is the pattern.
- Run the goal-shaped test. Next request, hand over a goal instead of a spec: 'buyers can't find pricing answers; fix that.' An expert comes back with a proposed approach. A ticket-taker comes back asking what you want built. You'll have your answer in one reply, on real work.
- Read the agreement for what was actually sold. Check the proposal or contract language: design, recommend, and propose describe an expert engagement; implement client-provided specifications describes production work. If the paper says production, the mislabel is yours to fix, not their deception.
What the vendor's answers actually mean
The replies that define this arrangement are consistent enough to translate.
“Tell me exactly what you want.”
The flagship. For a print run or a code port, a reasonable request. For a new section on your website, it's the expert's core job, handed back to you. What an expert asks instead: what are you trying to accomplish?
“Just send over the content and the layout you'd like.”
Content is genuinely yours to provide; you know your business. The layout is not. This sentence bundles your half of the work with theirs and mails you both.
“We built exactly what you asked for.”
Offered as a defense when a section underperforms, it's actually the confession: execution happened, judgment never did. An expert would have pushed back on a spec they believed wouldn't work, before building it; that pushback is half of what a website audit formalizes.
“We can do whatever you'd like, just let us know.”
Endless flexibility sounds like service and is its opposite: no opinion, no recommendation, no stake in the outcome. Whatever you'd like means the thinking is yours.
What actually fixes it
The working arrangement is a clean division: you bring the goal, the raw material, and the constraints; they bring the design and the reasoning. 'We need a FAQ section because support answers the same questions daily' is a complete request. What comes back should be a proposed structure with a rationale, not a form to fill in. You then judge the proposal against the goal, which is a conversation two parties are qualified to have.
One honest self-check belongs in that conversation: state the goals at the start, and then evaluate suggestions against the goals you stated. Advice anchored to a goal you've since quietly replaced will feel wrong without being wrong. If you find yourself repeatedly disliking direction from a vendor who is demonstrably reasoning from your stated goals, the cheapest fix is restating the goals, not replacing the vendor.
If the test and the paperwork say you have a production shop, decide with open eyes: keep them for execution at execution pricing and add design judgment elsewhere (the trade-offs are laid out in in-house vs. agency), or move the whole engagement to a vendor that sells outcomes. What doesn't survive the diagnosis is the middle state: expert invoices, spec-taker replies, and you doing the design work in the gap.
The message to send with your next request
This resets the dynamic on real work instead of arguing about the relationship. Their reply settles the diagnosis.
Hi [name],
We'd like to add a FAQ section. The goal: our team answers the same handful of questions by email every week, and we want the site doing that instead.
Rather than us specifying the layout, we'd like your recommendation: structure, what to include, and how it should work, based on that goal. We'll supply the questions and answers.
Could you send your proposed approach by [date]? If this kind of recommendation sits outside our current arrangement, let us know what it would cost.
Common questions
Is it normal for a web agency to ask me to spec everything?
It's common, and it's normal for exactly one kind of engagement: production work, where you bought execution of your specifications at execution prices. It isn't normal for a design engagement, which is what most established companies believe they're buying. The tell isn't the occasional clarifying question; it's every request for something new bouncing back as a questionnaire.
What should I have to provide for a new section or feature?
Three things: the goal (what the addition should accomplish and for whom), the raw material (your content, your products, your questions and answers), and the constraints (brand, budget, deadlines, anything regulatory). Structure, layout, item counts, and interaction patterns are the vendor's deliverable. If you're routinely supplying the second list, you're doing the design work.
What if I don't like what they design?
Judge it against the goal you stated, out loud: 'we asked for fewer support emails; walk me through how this gets there.' That keeps feedback anchored where both of you are qualified. One honest check before overruling an expert repeatedly: make sure the goals you're steering by are the ones you actually stated, because advice aimed at last quarter's goal will feel wrong without being wrong.
Isn't dictating the details just being a good, clear client?
Clarity about goals and material is being a good client. Dictating layouts and item counts is doing the vendor's job, and it quietly caps the work at your own web-design knowledge while transferring outcome responsibility to you. The best client in an expert engagement is demanding about outcomes and open-handed about how; that split is also what separates a [custom website from a template](/compare/custom-website-vs-template/).
Is production-only work ever the right arrangement?
Yes, knowingly: if you have design judgment in-house, a spec-executing shop at honest production pricing is efficient. The arrangement fails when it's accidental, when expert-level invoices meet spec-taker replies and nobody named the difference. The confirm steps and the contract language tell you which one you're in; the pricing should match.