Isometric illustration representing Two-panel split illustration: left side a developer at a clean desk building a simple tool, right side the same tool overwhelmed by tangled arrows from many client demands pointing at it. Editorial illustration, warm muted palette.
Operations

Vibe Coding Works. Then Clients Show Up.

L
Lam & Louie
5 min lezen

By Monday morning, the agency was using a task tracker its founder built over the weekend. Cursor, Claude, Postgres on Railway, a UI in Next.js. It did what the team needed and nothing it didn't. They migrated off the SaaS they'd been paying $99 a seat for.

A month later, he tried to build the client-facing version. Project status, deliverable approvals, an invoice tied to a phase the client had signed off on. He's still working on it.

That gap, between the version a team uses on Monday and the version a paying client logs into on Tuesday, is where the vibe coding argument quietly falls apart for agencies.

Not because the code gets harder. Because the problem changes.

"Good enough" depends on who's looking

Internal tooling has enormous tolerance for rough edges. A button fails silently? Refresh. The layout breaks on a narrow screen? Resize the window. Each bug costs one minute of your own time, and you already know the workaround because you wrote it.

Client portals invert that math. The client doesn't know the workaround. They don't want to know it. They want the portal to feel like a service that respects them, not a side project they're being asked to debug. A button that fails silently in front of a marketing director on a Tuesday morning becomes a story she tells her team at lunch.

This isn't about polish for polish's sake. It's about what your tooling says on your behalf when you're not in the room.

Three edge cases, each a quiet trap

File management at scale. Drag-and-drop upload is an afternoon. Three years into a recurring client relationship is a different problem. Hundreds of brand assets. Dozens of versions. Naming conventions that drifted twice. A junior designer asks where the blue logo variant from the Copenhagen rebrand is. The answer should be: type that sentence into a search bar, get the file. Building that involves AI-generated descriptions on every upload, vector embeddings across the project history, and a search interface that handles fuzzy intent. None of it is on the v1 plan. All of it is what makes the tool worth keeping after year three.

Design review. A comment box is an afternoon. What clients actually want — clicking the exact pixel of a hero image and saying "this shade reads cold to me" — is months. Then the harder problems arrive. Two reviewers leave overlapping annotations on the same area. A designer pushes a v2 that moves the element the comment was pinned to. A client opens v3 to find their feedback either floating above empty space or silently re-anchored to the wrong thing. Each scenario is a small trust event. Get one wrong and the next round of revisions starts with the client doubting the system.

Invoicing tied to project phases. Generating an invoice is trivial. Tying it to a milestone the client signed off on, handling a partial payment, tracking a dispute on a single line item, sending a reminder that doesn't read like a collections notice — that's years of work. The logic isn't in any tutorial. It comes from watching a couple dozen agencies handle the same awkward conversation and slowly converging on the version that doesn't make either side feel weird.

The part that builds in a weekend isn't the part that makes the tool real.

What we keep seeing

Agencies that try the DIY route follow the same path.

They ship the internal piece first. Project tracking, time tracking, maybe a dashboard. That part works. They tell their network about it.

Then they try to extend toward the client. Permission models. Data isolation between accounts. A login surface that doesn't make a five-person studio look like one person running a hobby app. Real-time updates so the client doesn't have to ping them on Slack to know where the project stands.

Most stall here. The realistic exits are bolting on a separate client portal product, or running the custom build in a permanently half-finished state. Either way, the original argument — consolidate the SaaS stack — has quietly reset to zero. Now there are two systems that don't share data, and the founder is maintaining both on weekends.

Why the gap is wider than it looks

Internal bugs cost an afternoon. Client-facing bugs cost trust, sometimes the engagement itself. A race condition that drops a request once a month is fine in a time tracker and lethal in an invoice approval flow. The reliability bar is set by the relationship, not by the codebase.

The other force is feature creep. A client likes the portal and asks for a thing. A second client asks for a slightly different version of the same thing. Six months in, the feature backlog is growing faster than billable hours, and there's no revenue stream from the software side to justify the work. You're now running an agency and a software company, with one customer.

The build is feasible. The maintenance, without a business model behind it, is not.

What we built

Oase exists for the part most agencies eventually outsource or live without: the layer between your team and the people paying you.

That meant design review where annotations are anchored to coordinates on the asset, with version awareness so feedback survives a redesign instead of floating above empty space. A file system that auto-describes uploads and lets you search across years of project history in one sentence, not by drilling through nested folders. Data isolation between client accounts as the default state, not a feature flag someone has to remember to enable. Client portals that live on a subdomain you control, so a client logs into your brand instead of a generic third-party shell.

None of it was on a spec when we started. It emerged from watching the same problems surface in the same order across studios of different sizes, and from building until the edge cases stopped being surprising.

The honest version of the question

For internal tools, vibe code away. Genuinely. If your team needs a sharper task board than the one you're paying for, build it. The economics are real and the risk is contained.

For the client-facing layer, the question isn't whether you can build it. The question is whether you want the next two years to be about discovering and fixing every edge case that surfaces when real clients use the thing every day.

If the answer is no — fair. Oase exists so someone else has already paid the edge-case tax for you.

L

Lam & Louie

Oase Team

Gerelateerde artikelen

Operations

What "Free" Actually Costs a Design Agency

Apr 29, 2026 · 6 min lezen
AI

Why 80% of AI Projects Fail: It's Not the Model. It's the Context.

May 7, 2026 · 5 min lezen

Ready to try Oase?

All tools included free. No credit card required.

Ontvang bureau-inzichten in je inbox

Geen spam. Eerlijke gedachten over het runnen van een designbureau, maandelijks verstuurd.