sayeed.net
← back
5 min read

So You're a Vibe Coder and Want to Build a Real App? Here's My Approach

#ai#architecture#vibe-coding#llm#fullstack
Listen

So You're a Vibe Coder and Want to Build a Real App? Here's My Approach

There's a moment every vibe coder hits: the initial demo works, the AI scaffolded something impressive in an afternoon, and then you realize — this thing actually needs to run. In production. With real users. And suddenly the single file, everything-in-one approach starts to feel less like speed and more like a trap.

Here's what I've learned about building agentic applications that stay maintainable as they grow.

Keep the Stack Simple at the Edges

The temptation when building with AI is to reach for the most impressive tools. Resist it.

Frontend on Vercel is fine. Seriously. Don't overthink it. Let it handle chat, auth, file uploads, and approvals — the things users actually touch. It doesn't need to know what the agent is doing internally.

Your API should be stateless. Deploy it on Cloud Run, Railway, or Fly.io using FastAPI or Node. Stateless means each request is self-contained, which makes horizontal scaling trivial and debugging a lot less painful.

Let data live where it belongs:

| What | Where | |---|---| | Real application data | Postgres | | Session state & queues | Redis | | Files and uploads | Object storage (S3, R2, GCS) |

Tip: If your workflow is genuinely multi-step — planning, waiting, branching — then add something like LangGraph or Temporal. Otherwise, don't introduce orchestration complexity before you need it.

Don't Collapse Everything Into One Blob

This is the single biggest mistake I see in early vibe-coded systems: frontend, agent logic, memory, and business data all living together in one hidden layer.

That's what makes these systems hard to debug and even harder to trust.

A cleaner mental model looks like this:

┌─────────────────┐    ┌──────────────────┐    ┌──────────────────┐
│    Frontend     │───▶│    Backend API   │───▶│   Orchestrator   │
│  Chat, auth,    │    │  Validation,     │    │  Decides next    │
│  uploads,       │    │  routing,        │    │  step in the     │
│  approvals      │    │  logging         │    │  workflow        │
└─────────────────┘    └──────────────────┘    └────────┬─────────┘
                                                         │
                              ┌──────────────────────────┤
                              ▼                          ▼
                    ┌─────────────────┐       ┌─────────────────┐
                    │   Tool Layer    │       │    Memory       │
                    │  Search, email, │       │  Explicit, not  │
                    │  DB access,     │       │  buried in      │
                    │  file parsing   │       │  prompts        │
                    └─────────────────┘       └─────────────────┘

Each layer has a single responsibility. The frontend doesn't make agent decisions. The agent doesn't write to the database directly. Tools are isolated from the core flow. Memory is explicit.

On Memory: Make It Visible

One of the sneakiest failure modes in agentic systems is implicit memory — context quietly stuffed into system prompts that nobody can see or audit.

Make memory explicit. Store it. Log it. Version it if you need to. A user should be able to look at what context the agent is working with. You should be able to inspect it when something goes wrong at 2 AM.

The same principle applies to observability — and it needs to exist from day one, not bolted on later:

  • Traces so you can follow a request end to end
  • Tool logs so you know what the agent called and what came back
  • Cost tracking so your AI spend doesn't become a surprise
  • Failure logs so errors aren't silent

On Multi-Agent Systems: Don't Start There

Because people post about multi-agent systems constantly online, it feels like that's the default starting point. It's not.

Most early systems need one good orchestrator and a clear tool layer. Five agents talking to each other sounds powerful; in practice it usually means five places for failures to disappear and become impossible to trace.

Separate agents start to make sense when the roles are genuinely distinct — like:

  • A planning agent that breaks down a task
  • A research agent that gathers information
  • An execution agent that performs actions
  • A review agent that checks the output

If you can't clearly articulate why each agent is separate, it probably shouldn't be.

What AI Is Actually Good For in This Stack

AI is excellent at:

  • Scaffolding UI components
  • Writing boilerplate wrappers around APIs
  • Generating repetitive code patterns

It is not the right tool for designing your boundaries. Do that manually.

The things that need to be deliberate:

  • Data ownership — what service owns what data
  • State management — where state lives and who mutates it
  • Retries — what happens when a tool call fails
  • Permissions — what the agent is and isn't allowed to do
  • Auditability — can you explain what happened and why

Warning: This is usually the line between a fun demo and a system you can actually run. The demo doesn't need auditability. The production system does.

The Architecture in One Sentence

Keep the edges simple, put intelligence in one deliberate place, isolate your tools, make memory explicit, and observe everything from the start.

That's it. Vibe code the boilerplate. Design the boundaries yourself. And resist the urge to add orchestration complexity before the simple version breaks.

Have a different approach? I'd love to hear how you're structuring your agentic apps — especially what's working at scale.

← all posts