9 Web Agency Services AI Cannot Provide (And Why Clients Still Pay Us for Them)

A client called us last spring, half-apologetic, asking whether they even needed us anymore. They had been prompting an AI tool for two weeks and had a landing page that looked, in their words, “basically fine.” We told them to keep it. Then we asked what they were actually trying to do, which turned out to be present a legally sensitive historical archive in a way that would hold up under scrutiny from three different constituencies who disagreed on the facts. The landing page conversation ended there. This article is about the web agency services AI cannot provide, written from the projects where that line became obvious, not from a whiteboard.

TL;DR

• AI IS A DRAFTING TOOL, NOT A DECISION-MAKER: Generative tools are genuinely good at producing plausible components, copy and code fast. What they cannot do is own a judgment call under real constraints, and most of what clients actually pay an agency for is the judgment, not the typing.
• OUR POSITION: The value has moved, not disappeared. We think the standard “agencies are dead” take is wrong. After building sites for a UN mechanism, a national news portal at 425M monthly page views, a 200,000-item museum and a government IP office, the hard parts were never the parts AI touches: stakeholder alignment, editorial judgment on contested facts, performance under real ad tech, accountability when it breaks.
• WHAT TO PRIORITIZE: If you are starting out, spend your money on problem definition and accountability, not on polish AI can already do cheaply. If you are auditing something that exists, measure Core Web Vitals and information findability first, because those are where the AI-built shortcuts quietly fail.

Quick Comparison

#	Service	Primary Value	Setup Effort	Expected Impact
1	Institutional & contested-narrative storytelling	Judgment on sensitive content	High	Engagement +78% (UN Mechanism)
2	Core Web Vitals at real-world scale	Ranking + speed under ad tech	High	97% avg CWV score (Kurir)
3	Information architecture for dense content	Findability across huge archives	Medium-High	Docs in a few clicks (ZIS)
4	Design thinking on the human need	Reframing the actual problem	Medium	200k+ items surfaced (Ethnographic Museum)
5	Stakeholder alignment & sign-off	Getting a decision made	Medium	Prevents rebuilds
6	Accountability & a name to call	Someone owns the outcome	Ongoing	Reduces downtime risk
7	Platform & migration judgment	Choosing what not to build	Medium	Avoids dead-end stacks
8	Accessibility & legal defensibility	Compliance you can prove	Medium	Reduces legal exposure
9	Long-term maintenance & iteration	Compounding improvement	Ongoing	Sustained results

We ordered these by the impact we have actually seen in client work, strongest first. Storytelling and performance lead because those are the two engagements where the gap between an AI draft and a shipped result was widest and most measurable.

1. Institutional and Contested-Narrative Storytelling

The clearest example we have of a service AI cannot provide is the project we built for the United Nations International Residual Mechanism for Criminal Tribunals: a storytelling website presenting the facts of what happened in Srebrenica in July 1995. The client came to us with an enormous archive of images, recordings and documents and a problem no generative tool can solve, which is that the facts are contested and the presentation itself carries moral weight. You cannot prompt your way out of that. Someone has to decide, and be accountable for deciding, how to hold opposing accounts side by side without flattening them into a single tidy narrative.

Our approach was to present every event from three angles: the perspectives of victims, of perpetrators, and a neutral account, carried by an interactive map with pins and a dynamic timeline. We chose a visual language that embraced the sentiment of the subject: darker tones, grayscale archival imagery, restrained accents of red. As our founder put it during the work:

“Our goal was to develop a website that felt intentionally unexpected with a visual language that embraced the overall sentiment of this subject.” – Vladeta Radovanovic, Founder & CEO, Presta

An AI would have optimised for engagement and clarity by default, which is exactly the wrong instinct here. The first thing we do on a project like this is throw out the conversion playbook. The trade-off we accepted was deliberately slowing the visitor down, making them sit with material, rather than pushing them toward an action.

KEY FEATURES:

• Three-perspective structure: Every event rendered from victim, perpetrator and neutral viewpoints, never merged.
• Interactive map with pins: Geographic anchoring of events so the archive has place, not just chronology.
• Dynamic timeline: Historical context carried by time, letting the visitor move at their own pace.
• Integrated multi-format archive: Images, recordings and documents unified into a single navigable experience.

ADVANTAGES:

• Handles contested facts without editorialising into a single voice.
• Emotional register matched to subject rather than to conversion goals.
• Accountable editorial decisions that can withstand external scrutiny.
• Archive made navigable instead of dumped as a file list.

LIMITATIONS:

• Slow to scope: the perspective structure alone took several rounds of alignment before a line of code.
• Not repeatable: nothing about this transfers cleanly to a commercial project.

Complexity: High. Best for: institutions, museums, NGOs and government bodies presenting sensitive or contested material. Client result: visitor engagement increased by 78% and time spent on the page was up by 2.5 minutes.

Checks we run on a storytelling engagement:

• Perspective audit: Is every contested claim attributed to a viewpoint, not stated as flat fact?
• Sentiment fit: Does the visual language match the gravity of the subject, or default to cheerful UI?
• Archive integrity: Are source documents linked, not paraphrased away?
• Pacing intent: Are we speeding the visitor up or slowing them down, and is that deliberate?
• Sign-off chain: Who at the institution owns the final editorial call?

2. Core Web Vitals Performance at Real-World Scale

The second service that exposes the AI gap is performance engineering under production conditions. AI can generate clean component code all day. What it cannot do is stand inside a national news portal, where page weight, ad tech and constant publishing fight you at every turn, and get the numbers up without breaking revenue. We ran exactly this for Kurir, one of Serbia’s largest news portals, from October 2024 to December 2025.

Kurir has been the most-read portal in Serbia for 78 consecutive months, roughly 10M unique visitors, 76M visits and 425M page views a month. At that scale every millisecond is multiplied and the Core Web Vitals ranking impact is direct, not theoretical. The lesson we keep relearning: the constraint is almost never code quality. It is ad tech, third-party scripts and the sheer volume of continuous publishing. A tool that generates a fast static page has solved a problem the client does not have.

KEY STEPS:

• Baseline under load: Measure real field data, not lab scores on an empty page.
• Ad tech triage: Identify which third-party scripts cost the most and negotiate what can be deferred.
• Publishing-safe patterns: Build performance into templates editors use daily, so speed survives the next 400 articles.
• Continuous monitoring: Track the score month over month because a single new ad partner can undo six weeks of work.

ADVANTAGES:

• Direct ranking benefit in a search-driven traffic model.
• Improvements survive continuous publishing rather than a one-time cleanup.
• Revenue-aware: performance gains that do not gut ad income.
• Measurable in the field, not just in a lab.

LIMITATIONS:

• Never “done”: we saw scores dip when new ad partners were added mid-engagement.
• Requires ongoing access to production, which some clients hesitate to grant.

Complexity: High. Best for: high-traffic publishers, marketplaces and content sites where speed maps to money. Client result: increased Core Web Vitals score to 97% on average. For teams moving from a prototype into this kind of load, our prototype to production scalable web apps checklist covers the groundwork before performance work even starts.

Checks we run on a performance engagement:

• Field vs lab: Are we optimising the number users experience or the one that looks good in a demo?
• Third-party budget: Which scripts are we willing to defer, and who owns that call?
• Template-level fixes: Will this survive the next thousand articles?
• Regression monitoring: Is there an alert when the score drops?
• Revenue guardrail: Does any speed gain cost ad income, and is that acceptable?

3. Information Architecture for Dense, High-Stakes Content

AI is good at generating content and terrible at organising a mountain of pre-existing content that must not be lost or misfiled. That distinction ran the Intellectual Property Office of Serbia (ZIS) engagement. We redesigned and rebuilt the national IP office site, where the core challenge was combining an enormous volume of content, documents, data and registers while still letting a visitor find exactly what they came for, on a tight deadline.

Our principle here is structure before visuals: learn what visitors actually search for before making any design decision. We do not let anyone open a design tool until we understand the users, their pain points and the specific problems they arrive with. As our senior designer framed the intent:

“The main idea behind the design was to give ZIS a solid identity and a really good user interface, but not something that would overwhelm the viewers.” – Marijana Subotic, Senior Designer, Presta

We delivered a colour-coded navigation system, advanced filterable tables for documents, laws and fees, and integration of a complex set of external services into one presentation. The surprising part, and the part AI cannot infer, was how many visitors arrived knowing exactly one fee or one register they needed. The whole architecture bent toward getting them there in a few clicks, not toward showcasing everything the office does.

KEY FEATURES:

• Colour-coded navigation: Categories made visually distinct so dense content stays scannable.
• Filterable tables: Documents, laws and fees reachable by narrowing, not by scrolling.
• External service integration: Multiple complex backends presented as one coherent surface.
• Search-driven structure: Architecture built from real query intent, not from the org chart.

ADVANTAGES:

• Turns an overwhelming archive into a findable resource.
• Reduces support load because visitors self-serve.
• Scales as new documents and fees are added.
• Works across devices for citizens and professionals alike.

LIMITATIONS:

• Front-loaded discovery: the research phase felt slow to a client on a tight deadline.
• Only as good as the taxonomy: a wrong category decision early is expensive to unwind.

Complexity: Medium-High. Best for: government, legal, financial and any site where findability beats aesthetics. Client result: all required documents, laws and taxes reachable within a few clicks on any device. If you are wrestling with the content side specifically, our notes on the content phase of a new website go deeper.

Checks we run on an information architecture engagement:

• Query mapping: What do visitors actually type or ask before they land?
• Single-item paths: Can someone who needs one document get there in under three clicks?
• Taxonomy stress test: Does every content item have one obvious home?
• Colour logic: Is the colour system meaningful or decorative?
• Mobile parity: Does the dense-content experience hold up on a phone?

4. Design Thinking Anchored on the Human Need

The most consistent thing AI cannot do is ask the right question before answering. It answers whatever you type. A design thinking process exists precisely to reframe the problem the client thinks they have into the problem they actually have. We ran this on the Ethnographic Museum Belgrade, one of the oldest museums in the Balkans, custodian of over 200,000 collection items and one of the region’s richest specialised libraries.

The stated business need was to increase knowledge of the collections and activities. The human need underneath it was simpler: people wanted to know what was on, when, and how to get a ticket, without wading through institutional history. Our process reframes and defines the problem, generates many ideas in ideation sessions, takes a hands-on approach in prototyping, then develops the solution. That reframe changed everything downstream.

KEY STEPS:

• Reframe and define: Separate the business goal from the underlying human need.
• Ideate broadly: Generate many candidate solutions before committing to one.
• Prototype hands-on: Build rough versions to test the reframe against reality.
• Develop the solution: Only then commit engineering to the validated idea.

ADVANTAGES:

• Solves the real problem, not the requested feature.
• Surfaces ideas a spec sheet would never produce.
• Reduces expensive late-stage rework.
• Keeps the whole team aligned on why, not just what.

LIMITATIONS:

• Feels indulgent to clients who “just want the site built.”
• Hard to fixed-price because the problem can shift during discovery.

Complexity: Medium. Best for: cultural institutions and any client whose stated brief is a symptom, not the cause. Client result: 200,000+ collection items surfaced through the new structure. The calendar we built shows the payoff: it combines the two ways people actually browse events, a monthly grid and a chronological list, opened from a sticky always-visible button into a modal so the visitor never loses their place, with every event type in its own colour so time slots are separable at a glance. That design did not come from a prompt. It came from watching how people actually plan a museum visit. Our writeup on the design phase of a new website walks through this in more detail.

Checks we run on a design thinking engagement:

• Need vs request: Have we named the human need behind the stated brief?
• Idea volume: Did we generate enough options to reject most of them?
• Prototype before polish: Have we tested the concept before styling it?
• Behaviour observation: Did we watch real users, not just ask them?
• Reframe sign-off: Does the client agree the reframed problem is the right one?

5. Stakeholder Alignment and Getting a Decision Made

Here is a service that never appears on a feature list but eats half of most large projects: getting a room full of people who disagree to commit to one direction. AI cannot sit in a meeting with a legal team, a communications team and an archivist who all have veto power and broker a decision everyone can live with. On the UN Mechanism project, the three-perspective structure was not just a design choice, it was the mechanism by which we got sign-off from parties who would never have agreed to a single narrative.

We disagree with the standard advice that says “just build fast and iterate.” After doing this for institutional clients, we think that is wrong for anything with real stakeholders, because iterating on the wrong direction with five approvers is slower and more painful than aligning first. The first thing we check when a stakeholder-heavy project lands is who actually holds sign-off, because the org chart lies about this constantly.

KEY STEPS:

• Map the approvers: Identify who can say no, not just who is in the meetings.
• Surface disagreement early: Get the conflict onto the table before design, not after.
• Offer structural compromises: Sometimes the architecture itself resolves the deadlock.
• Document the decision: Write down what was agreed and who agreed to it.

ADVANTAGES:

• Prevents late-stage rebuilds triggered by an approver nobody consulted.
• Turns political conflict into a design constraint you can work with.
• Builds trust that makes later decisions faster.
• Produces a paper trail that protects everyone.

LIMITATIONS:

• Time-consuming and impossible to fully automate.
• Requires a senior person, which raises the cost.

Complexity: Medium. Best for: institutions, agencies of record, and any project with more than two decision-makers. Presta estimate: in our scoping, alignment work on a multi-stakeholder institutional project usually consumes 20 to 30 percent of the timeline before real production starts, and it is the cheapest insurance we know. Our overview of the functional specification phase shows how we pin these decisions down in writing.

Checks we run on stakeholder alignment:

• Veto map: Who can kill this, and have we talked to them?
• Conflict surfaced: Are the disagreements documented before design starts?
• Decision owner: Is there one person who makes the final call?
• Written record: Is every major choice logged with who approved it?
• Escalation path: When approvers deadlock, who breaks the tie?

Where an Agency Earns Its Fee (and Where It Does Not)

If you are a founder or operator reading this to decide whether to hire us or keep prompting, here is the honest cut. Bring in Presta’s web development team when the cost of getting it wrong is high, the stakeholders are many, the content is dense or contested, or the thing has to perform under real load. That is where the web agency services AI cannot provide actually pay for themselves. Do not hire us to make a simple marketing page you could ship yourself this afternoon; you would be paying senior rates for something AI drafts in minutes.

If your project has real stakes, real stakeholders, or real scale, talk to our team and we will tell you honestly whether it needs an agency or not.

6. Accountability and a Name to Call When It Breaks

AI does not answer the phone at 2am when the site is down before a launch. It does not sign a contract, carry liability, or owe you anything. Accountability is a service, and it is one clients undervalue until the day they need it. When Kurir’s Core Web Vitals dipped after a new ad partner went live, there was a team on the hook to fix it, not a chat window that had forgotten the context.

The candid admission here: early in our history we underestimated how much of our value was accountability rather than output. We scoped a project once as pure build, priced it lean, and then spent weeks absorbing “who owns this bug” arguments we had not budgeted for. Now we price ownership explicitly and name the person responsible for each area. It changed our client relationships more than any technical improvement did.

KEY FEATURES:

• Named ownership: A specific person accountable for each part of the system.
• Contractual liability: A legal entity that stands behind the work.
• Context retention: A team that remembers why a decision was made a year later.
• Incident response: A path to reach a human when it breaks.

ADVANTAGES:

• Someone is genuinely responsible for the outcome.
• Institutional memory survives staff turnover on your side.
• Faster resolution because context is not re-explained each time.
• Legal and reputational cover.

LIMITATIONS:

• Costs more than a tool subscription, obviously.
• Only worth it above a certain stakes threshold.

Complexity: Ongoing. Best for: anyone whose downtime or errors carry real cost. Presta estimate: we typically budget a retainer for accountability separately from build, because bundling them hides the real value. If you are weighing this against doing it yourself, our comparison of freelancers vs agencies for startups lays out the trade.

Checks we run on accountability setup:

• Ownership map: Does every system component have a named owner?
• Response path: How does the client reach a human, and how fast?
• Liability clarity: Who is legally responsible for what?
• Context capture: Are key decisions documented for future team members?
• Escalation ladder: What happens when the first responder cannot fix it?

7. Platform and Migration Judgment (Knowing What Not to Build)

AI will happily build whatever you ask, including things you should never build. The judgment to say “do not build a custom CMS, use this platform” or “do not migrate yet, your data is not clean” is a service in itself, and it is negative work: the most valuable thing we do some weeks is talk a client out of something. A tool optimising for a helpful answer will not tell you no.

On the ZIS project, integrating a complex set of external services could have tempted a rebuild of each one. We judged the opposite: present them as one surface, integrate rather than replace, because a government body on a tight deadline could not absorb the risk of rebuilding working systems. That was a trade-off, not a limitation, and it shipped on time.

KEY STEPS:

• Audit before building: Understand what already works before proposing to replace it.
• Match platform to team: Choose a stack the client can actually maintain.
• Sequence the migration: Move data in a validated order, not all at once.
• Say no when needed: Recommend against features that add risk without value.

ADVANTAGES:

• Avoids dead-end stacks nobody can maintain.
• Reduces migration risk through sequencing.
• Saves budget by not rebuilding what works.
• Matches technology to the client’s actual capacity.

LIMITATIONS:

• Requires broad experience to make the call confidently.
• The value is invisible: nobody thanks you for the disaster you prevented.

Complexity: Medium. Best for: any migration or platform decision with legacy systems in play. Presta estimate: our rough estimate from past projects is that a proper platform audit adds one to two weeks up front and routinely saves months later. For the deeper version of this thinking, see our guide on how to build a scalable web platform and, for teams weighing app strategy, our take on native, cross-platform or progressive web app.

Checks we run on platform and migration judgment:

• Legacy audit: What already works and must not be broken?
• Maintenance fit: Can the client’s team run this after we leave?
• Migration order: Is data moving in a validated, reversible sequence?
• Kill list: Which requested features are we recommending against, and why?
• Rollback plan: If the migration fails, how do we revert?

8. Accessibility and Legal Defensibility

Accessibility is where AI output quietly fails, because a page can look correct and be unusable with a screen reader or non-compliant with WCAG. For public sector and institutional clients, this is not a nice-to-have, it is a legal requirement you have to be able to prove. On the ZIS government project, accessible, device-agnostic access to laws and fees was part of the mandate, not a bonus feature.

The thing AI cannot do is take responsibility for the claim that a site meets a standard. We test with real assistive technology, document conformance, and stand behind it. A generated component might have an alt attribute; it will not have been checked by a person navigating with a keyboard against a legal baseline the client can cite in an audit.

KEY FEATURES:

• Assistive tech testing: Real screen reader and keyboard navigation checks.
• Conformance documentation: A record of what standard was met and how.
• Semantic structure: Markup that machines and assistive tools parse correctly.
• Contrast and legibility: Verified against the standard, not eyeballed.

ADVANTAGES:

• Reduces legal exposure for regulated clients.
• Widens the actual audience who can use the site.
• Provides documentation for audits and procurement.
• Improves general usability as a side effect.

LIMITATIONS:

• Manual testing is slow and cannot be fully automated.
• Standards evolve, so conformance is a moving target.

Complexity: Medium. Best for: government, education, healthcare and any client with a compliance obligation. Client result: on ZIS, all required documents, laws and taxes were reachable within a few clicks on any device, which is accessibility and findability working together.

Checks we run on accessibility:

• Screen reader pass: Has a person navigated the full flow with assistive tech?
• Keyboard-only test: Can everything be done without a mouse?
• Contrast audit: Do colours meet the standard, verified not guessed?
• Semantic markup: Is the structure meaningful to machines?
• Conformance record: Can we prove compliance if asked?

9. Long-Term Maintenance and Compounding Iteration

The last service AI cannot provide is time. A generated site is a snapshot; a maintained one improves. The Kurir engagement ran from October 2024 to December 2025, more than a year, because performance at that scale is not a project you finish, it is a relationship you sustain. Every new ad partner, every traffic spike, every algorithm change is a reason the work continues.

We disagree with the “set it and forget it” framing that AI-built sites encourage. In our experience, the sites that win are the ones someone keeps improving quarter after quarter, watching the numbers and adjusting. That is boring, unglamorous, and exactly where compounding results come from. A tool gives you a starting point; it does not give you the discipline of iteration.

KEY STEPS:

• Establish baselines: Know the numbers you are trying to move.
• Monitor continuously: Watch for regressions before users notice them.
• Iterate on evidence: Change based on measured behaviour, not hunches.
• Report and adjust: Review results on a cadence and reprioritise.

ADVANTAGES:

• Results compound rather than decay after launch.
• Regressions caught early instead of after a ranking drop.
• Priorities stay tied to real data.
• The site adapts as the business changes.

LIMITATIONS:

• Requires ongoing budget many clients resist.
• Slow to show dramatic wins; the gains are incremental.

Complexity: Ongoing. Best for: any site whose performance directly affects revenue or reach. Client result: Kurir’s Core Web Vitals reached 97% on average, held through continuous publishing across the engagement. Our notes on progress tracking through a website project show how we keep this visible for clients.

Checks we run on maintenance and iteration:

• Baseline set: Do we know the starting numbers for every key metric?
• Regression alerts: Will we know before the client does when something slips?
• Evidence trail: Is each change tied to observed data?
• Review cadence: Is there a regular schedule to reprioritise?
• Business alignment: Do the metrics still match what the business cares about?

Our Framework: The Human-Need-First Delivery Loop

Across every project above, the same shape recurs. We call it the Human-Need-First Delivery Loop, and it is how we actually run this work, not an invented acronym.

1. UNDERSTAND THE HUMAN NEED: Before touching design or code, we separate the stated business goal from the underlying human need. The museum wanted “more engagement”; visitors wanted to know what was on this weekend. Name the second one.
2. DEFINE AND ALIGN: Reframe the problem, map the approvers, and get disagreement onto the table. On the UN project this is where the three-perspective structure was born.
3. STRUCTURE BEFORE VISUALS: Learn what people actually search for and build the information architecture first, exactly as we did for ZIS. Design serves structure, not the other way around.
4. PROTOTYPE AND TEST: Build rough, test with real behaviour, and be willing to throw it out. The museum calendar went through this before it earned its sticky button.
5. DELIVER AND ITERATE: Ship, measure against baselines, and keep improving, the way Kurir’s performance work ran for over a year.

The loop is the part AI cannot run for you, because every step is a judgment call under constraints only a human who understands the stakes can make.

Measuring Success: 30 / 60 / 90 Day Outcomes

We tie every engagement to outcomes we can measure, drawn from what we actually tracked on these projects. Here is the honest cadence.

Timeframe	What we measure	Example from our work
30 days	Baselines and quick wins: field Core Web Vitals, findability of key pages, initial engagement	Kurir baseline CWV captured under real ad load
60 days	Structural improvements taking hold: navigation working, dense content reachable, early engagement lift	ZIS docs reachable in a few clicks; museum calendar in use
90 days	Sustained, compounding results attributable to the work	UN Mechanism engagement +78%, time on page +2.5 min

By day 30, we expect clean baselines and a couple of visible wins, nothing more. Anyone promising transformation in a month is selling. By day 60, structural changes like new information architecture or performance patterns should be measurably holding. By day 90, we look for sustained movement in the metric that matters: engagement, findability, Core Web Vitals, whatever the human need pointed to. On the UN project, the 78% engagement increase and 2.5 extra minutes on page were the proof the three-perspective structure worked. On Kurir, the 97% average score was the proof performance survived continuous publishing.

Checks we run on measurement:

• Right metric: Does the number map to the human need, not vanity?
• Clean baseline: Was the starting point measured under real conditions?
• Attribution: Can we tie the movement to a specific change we made?
• Field data: Are we measuring real users, not lab conditions?
• Cadence honesty: Are our timeframe promises realistic, or hype?

To close the loop on the UN Mechanism project: it shipped, engagement rose 78%, time on page rose 2.5 minutes, and the three-perspective structure held up to the scrutiny it was designed for. What would we do differently now? We would budget even more alignment time up front. The perspective structure that made the project work also made it slow to agree on, and we underestimated that in early scoping. That lesson now shapes how we quote every institutional project.

If you are just getting started, prioritise problem definition and accountability over polish, because polish is exactly what AI already does cheaply and the other two are where projects fail. If you are auditing something that already exists, start by measuring Core Web Vitals in the field and testing whether a real visitor can find the one thing they came for, because those are the two places AI-built shortcuts quietly break.

Next Steps:

• Run a field Core Web Vitals check on your existing site and compare it to the lab score you have been trusting.
• Write down the single human need behind your project in one sentence, then check whether your current site serves it.
• If your project has real stakes, stakeholders or scale, book a scoping call and ask us to tell you honestly whether you need an agency.

Frequently Asked Questions

What can web agencies do that AI tools cannot?

The short answer is judgment under constraints and accountability for the outcome. AI is excellent at producing plausible drafts of copy, layouts and code, and we use these tools ourselves to move faster. What AI cannot do is decide, for a contested historical archive, that opposing perspectives must be shown side by side rather than merged, then take responsibility for that decision in front of a legal team. On the UN Mechanism project that single judgment was the whole engagement.

The pattern holds across every project. AI answers what you ask; an agency asks whether you are asking the right thing. It cannot sit in a room and broker agreement among five approvers, it cannot own liability, and it cannot maintain the context of why a decision was made a year later. Those are services, and they happen to be the expensive, high-stakes parts of the work.

What value does a web agency add beyond web building?

Most of the value, honestly. The building itself is increasingly commoditised, and we are the first to say so. The value is in the layers around it: reframing the problem so you solve the real thing, as we did for the Ethnographic Museum where “more engagement” really meant “help people plan a visit”; organising dense content so a citizen finds one fee among thousands of documents, as on ZIS; and sustaining performance under real load for over a year, as on Kurir.

Beyond that, there is accountability, which is invisible until you need it. A tool does not stand behind its output. When something breaks before a launch, you want a named person on the hook, not a chat window. We learned to price that separately because bundling it hid how much clients actually relied on it.

Are there services only agencies can provide?

Yes, though we would frame it as services only accountable humans with experience can provide, and agencies are how that gets organised. Contested-narrative storytelling is one: presenting facts under moral and legal scrutiny is a judgment no tool can own. Performance at national-publisher scale is another: the constraint there is ad tech and continuous publishing politics, not code, and it takes a team negotiating with real stakeholders to move the numbers.

Accessibility with legal defensibility is a third. A generated page can look accessible and fail a real screen reader test or a compliance audit. Someone has to test with assistive technology, document conformance, and stand behind the claim. For a government client, that accountability is the deliverable, not the markup.

When does it make sense to bring in Presta’s web development team?

Candidly, not always, and we will tell you when it does not. If you need a simple marketing page or a basic brochure site, AI tools and a template will get you there, and paying agency rates for that is a waste. We would rather you keep that budget.

The threshold where it becomes worth it is when the cost of getting it wrong is high. That means real stakeholders who can veto each other, dense or contested content, a compliance obligation, performance under serious load, or a migration with legacy systems that cannot break. When any of those are in play, the web development services we provide exist precisely to absorb the risk and the judgment that AI cannot. If your project has one or more of those, it is worth a scoping conversation. If it has none, you probably do not need us yet.

Will AI make web agencies obsolete?

We do not think so, and we have skin in the game saying it. AI has made the drafting parts of our work faster and cheaper, and that pressure is real. But it has raised, not lowered, the value of the parts it cannot do: problem definition, stakeholder alignment, performance under real constraints, accountability and long-term iteration. Those got relatively more valuable as the commodity work got cheaper.

The agencies that struggle will be the ones whose only offer was building the thing. The ones that thrive are the ones already selling judgment. Our recognition as a top web development company in Serbia by Clutch came from outcomes on hard problems, not from typing speed, and those problems are not going anywhere.

How do you use AI in your own work if you argue it has limits?

We use it constantly, and there is no contradiction. AI accelerates the parts that are genuinely acceleratable: first drafts of copy, boilerplate code, generating options to react to during ideation. On a project like the museum calendar, having AI throw out variations early speeds up the divergent phase of design thinking.

Where we stop is the judgment. AI does not decide the three-perspective structure, does not choose to slow a visitor down deliberately, does not negotiate which ad script gets deferred. We treat it as a fast, tireless junior that never gets to make the final call and is never accountable for it. That division is exactly the argument of this whole article.

What should I audit first on an existing site to know if it needs an agency?

Two things. First, run a Core Web Vitals check on field data, not the lab score, because the lab score on an empty page lies about what your real users experience under ads and scripts. If your field numbers are poor and traffic matters to you, that is a signal. Second, pick the single most important thing a visitor comes for and try to find it as a stranger would. If it takes more than a few clicks, your information architecture is working against you.

If both of those pass, you may not need an agency at all, and we would say so. If either fails and the stakes are real, that is where the website redesign roadmap and a scoping conversation earn their keep. The audit itself is cheap; the rebuild you avoid by doing it is not.

Sources

• Web Vitals – web.dev
• WCAG – W3C Web Accessibility Initiative