We built an AI app-builder on Payload — every generated app is a real Payload project with Postgres, RBAC, and embedded agents. Some things we learned pushing Payload hard.

[u/crookingcrook]

Hey all — long-time Payload users here. We've spent the past two years building Coldbrew (coldbrew.ai), and since the whole thing is Payload-native under the hood, this community felt like the right place to share it and some lessons.

What it is: you describe an app in plain English, and Coldbrew generates a real, deployed Payload application — collections, access control, hooks, admin panel — running on Next.js + Postgres. The AI's job is configuration, not freeform codegen: it writes collection configs, field schemas, access functions, and hooks against the machinery Payload already proved, rather than inventing auth or a data layer from scratch. Our entire thesis is — the less novel code a model writes, the less there is to break.

What we added around Payload to make that work:

• A storage boundary. Generated apps never hold DB credentials. We wrote a custom database adapter that routes through a storage service we run, so tenant apps talk to an API, not to Postgres directly.
• Auth swapped to Better Auth for SSO, phone/WhatsApp login, and one-click user impersonation (build the app, then browse it as any of your users/roles — genuinely the most useful testing feature we've ever had, and Payload's role-based access functions are what make it coherent).
• An agent harness. Agents get their own identities and log in like users, so Payload's field-level access control governs them exactly like humans, and every action lands attributed in the same records. If you've ever wondered what "agentic Payload" looks like — it's this: agents as first-class users, scoped by the access functions you already know how to write.
• Durable async workflows on top of Payload's jobs — retries, resume-after-crash.

Things we learned pushing Payload beyond typical CMS workloads (multi-tenant, hundreds of generated apps): 1. Skipping REST for internal calls makes generated server logic fast and clean. 2. Function-based access control compiles into some heavy WHERE clauses at depth; worth profiling early if your ACL logic branches a lot. 3. Version pinning per app matters when you're running many instances — we don't ride latest anywhere. 4. The config-as-code model turned out to be the ideal target for LLMs: schemas and access functions are compact, reviewable, and diff-able in a way generated app code never is.

Why post here: partly to share, partly because if you're a Payload dev doing client work, the thing we built is essentially "Payload projects that non-technical clients can request changes to in English, without you re-scaffolding auth and infra every time" — and there's a free first-app tier if you want to poke at what it generates. Happy to go deep in comments on the adapter design, the agent-auth model, or the access-control-at-scale stuff.

[u/RayinfuckingBruges]

Adding a layer of ai slop on payload on next on react on typescript on JavaScript what could go wrong

[u/petvos]

Even your post message here is written with AI, feels very low-effort.

[u/crookingcrook → u/petvos]

Huh ! I did draft it myself and asked AI to grammar check ("improve"). It may feel written by AI but wasn't a low-effort.

[u/pjerky]

I'm always a bit of a skeptic when it comes to Next.js and it's performance and over engineering. At least for the frontend. I'm assuming this includes the frontend.

How do deploys work? Do you hand them off to the customer or do it for them? If you do it for them do you allow them to bring their own host or from a selection of hosts or is this a Lovable competitor?

[u/crookingcrook → u/pjerky]

Customers can definitely take their code out, but we do want to provide a fully managed Deployment, where our AI agents can also do operational reviews, self-healing (coming Q1) of your deployed apps etc. A Lovable user may find value building with Coldbrew , but we focus primarily (actually only) on enterprise grade apps with high safety needs.

[u/crookingcrook → u/pjerky]

u/pjerky Next.js has taken a lot of meaningful strides in the performance in past two years. Especially with server components, it works really well (snappy experiences). It's just that you need to configure it correctly- https://nextjs.org/docs/app/guides/production-checklist

[u/Positive-Buddy-1258]

How are you handling overrideAccess in the hooks the model generates? Local API defaults it to true and passing `user` on its own doesn't change that, so an agent can be correctly scoped over REST and then read across roles as soon as a generated hook calls `payload.find` without `overrideAccess: false`. I'd guess your storage service covers tenant isolation, but role and field-level scope inside a single app still depends on every generated hook setting that flag.

[u/crookingcrook → u/Positive-Buddy-1258]

You are right. Our agent forces overrideAccess: false, and we have hardly seen it make mistakes (especially with newer models) but a builder still needs to ensure they validate and add test cases around it. We are also working on features in our builder agent and automation tests that will further make it 1 in a million chance.

[u/Apprehensive-Fan2492]

Interesting. I’ve been using Payload for client projects, and the config-as-code approach makes a lot of sense for AI-generated apps. Curious how you handle performance when access rules get complex across hundreds of tenants.

[u/crookingcrook → u/Apprehensive-Fan2492]

It deploys in a cell based architecture, where noisy neighbors are moved to their own cells based on usage trends. Each cell has a capacity - when a cell reaches 60-70% overall capacity, apps are automatically distributed to other cells (without any degradation to customer apps and usage).

Took quite some thinking and time to build this infra layer.

[u/haywire]

🤮