Production Got Faster. Judgment Didn't. The Real Design Bottleneck in 2026

A year ago, the bottleneck in most product teams was getting something built. Now it's checking whether what got built is actually right. That shift changes what a design process needs to spend its time on — and it's the reason I've restructured how much of my own process goes into evaluation versus production.

The bottleneck moved. It didn't disappear.

For most of the last decade, the expensive part of building a product was production: turning an idea into a working screen, then into working code. Whoever could produce fastest — the best design tool, the best dev workflow, the best handoff process — had an edge.

AI-assisted generation mostly closed that gap. A founder can describe a dashboard and get something that renders. A PM can prompt a working prototype in an afternoon instead of waiting a sprint. Production, the thing that used to take the longest, now often takes the least time in the whole process.

What didn't get faster is the part that comes after: deciding whether what got produced is actually correct. Not "does it look right" — does it hold up against real data, real permissions, real people using it in ways the happy path never anticipated. That's evaluation, and on the kind of data-heavy web apps I build — dashboards, internal tools, platforms with real business logic behind every screen — it was always the harder half of the job. Now that production is cheap, it's also the only half that's still expensive.

What "evaluation" actually means in practice

It's tempting to think of evaluation as QA — a pass at the end, checking for bugs before launch. That's not what I mean, and treating it that way is part of why teams get caught off guard.

Evaluation, done right, starts before a single screen exists. It's asking, in the room, before anything is designed: what happens with 40,000 records instead of the 12 in the demo data? Who else can see this screen, and does it need to look different for them? What happens the moment two people touch the same record? What does undo look like once other systems have already reacted to the first action? None of these questions show up in a prompt, because nobody describes the unhappy path first. They show up when someone deliberately goes looking for it — which is a discipline, not a tool.

Two places this showed up as real client work, not theory

I rebuilt WiSys's Agility Shipping app for warehouse teams and shipping clerks starting from a business-logic question, not a screen: the app had to run two ways — embedded inside WiSys's warehouse management system, inheriting a login automatically, and standalone, with nothing to inherit and multiple shipping clerks potentially sharing one terminal across shifts. That requirement didn't come from a feature request. It came from asking, early, what happens when the assumption behind the happy-path login doesn't hold. If I'd started from a prompt describing "a shipping label screen," I'd have gotten a screen that worked once, for one person, and broken the first week a second clerk logged in on the same terminal.

When I audited Steady's Income Passport — the tool gig workers use to verify income and access benefits that normally require paperwork they can't easily produce — the evaluation step was the entire engagement. The income report submission flow had been built around how a database wanted the data structured, not around how gig workers actually think about earnings across multiple platforms and pay schedules. Nobody had done anything wrong, exactly. Nobody had gone back and asked, after the fact, whether the flow matched how the people using it actually think. That's what an audit is: a dedicated pass at evaluating something that already exists, on the assumption that a first pass, however careful, misses things a second, deliberate look will catch. I rebuilt the error handling the same way — every message says what went wrong, why, and what to do next, right where the failure happened. For a product where a failed verification can mean a missed rent payment, that's not polish sitting on top of the feature. It's the evaluation of "what happens when this fails" made visible in the interface.

Why I build evaluation into the schedule, not the end

Internally, I think about my own process as roughly a third research and thinking, a third producing, and a third testing and evaluating — not a precise formula, more a reminder that the back third of a timeline isn't a buffer, it's load-bearing. Regular check-ins through a project exist for the same reason: not status theater, but a standing, scheduled evaluation point, so a wrong assumption gets caught in week two instead of week six.

That's the opposite of how most teams treat evaluation once production speeds up. The instinct is to spend the time saved on more production — another feature, another screen, another round of generation — because production is the part with a visible, countable output. Evaluation doesn't produce a new screen. It produces the absence of a screen breaking in production, which is much harder to point to in a sprint review, and much easier to skip.

What this means if your team just got faster

If AI has genuinely sped up how fast your team ships, the honest question isn't "what should we build next with the time we saved." It's "did we build in a matching amount of time to check what we just shipped, or did we just start shipping more." Those are very different outcomes from the same tool.

A few signs the evaluation side hasn't kept pace: nobody on the team owns asking what happens with realistic data volume before a feature ships; permission and role edge cases get discovered by users instead of designers; nobody's assigned to check what an AI-generated or vibe-coded screen does outside the happy path before it goes live. None of these require slowing production back down. They require treating evaluation as its own line item, with its own time on the calendar, instead of assuming it happens for free alongside faster building.

A closing thought

None of this is an argument against the tools generating faster. Faster production is a genuinely good thing to have, and I use these tools myself. The point is narrower: production speed and evaluation capacity are two different capabilities, they don't scale together automatically, and right now most teams have only invested in one of them. The team that also invests in the other is the one whose "shipped fast" doesn't turn into "shipped fast, then spent a month fixing it."

If you're building a data-heavy product and want a second pair of eyes on what your team's evaluation process is actually catching — or missing — that's the kind of working session I run before a build starts, not after a support queue tells you what got missed.

Gytis Markevičius
Founder, GytisMark Studio — gytismark.com