Vibe-Coded CRM vs. Vibe-Coding on Dynamics: The Platform Is the Moat

The most interesting thing about the vibe-coded CRM trend is that it is half right. Teams really are generating working CRM replacements with AI in days, posting the screenshots, and announcing the cancelled licences. The demos are genuinely good. The per-seat frustration driving them is genuinely legitimate. I am not going to pretend otherwise.

But the trend proves something narrower than what it claims. It proves that the user interface of a CRM is now cheap to build. It does not prove the CRM platform is obsolete. Those are different layers, and conflating them is how a weekend win becomes a two-year liability.

The term itself comes from Andrej Karpathy’s February 2025 post on X, where he described “fully giving in to the vibes” and letting the model write the code - a mode he explicitly framed as fine for throwaway weekend projects (the original post). Note what he did not say: that this is how you build systems of record. The term’s origin is a disclaimer, not an endorsement.

Here is the position I will defend for the rest of this piece: if vibe coding made the experience layer nearly free, the rational architecture is a cheap, fast-moving experience layer on top of a governance layer that took a decade to harden. That is an argument for keeping Dataverse underneath, not for rebuilding it badly in Postgres.

What the demo doesn’t show: the invisible 80%

Every capability below shares one root cause when it fails in a homegrown build: enforcement location. A governed platform enforces security, audit, and validation server-side at the data layer, so every access path inherits the invariant - API, mobile, integration, export. A vibe-coded app enforces them in the UI or in a single API route, and any path the author did not think about bypasses the control entirely.

Walk the list. Each item is boring until the day it is an incident.

Security roles and row-level security. Dataverse enforces role-based and record-level security at the platform, so a user without privileges on a row cannot retrieve it through any channel. The homegrown equivalent is usually a WHERE owner_id = ? clause in one query. The failure mode is a departing rep who swaps GUIDs in a URL, or hits the API directly, and exports the entire pipeline instead of their own. The platform makes that impossible by construction. Your weekend build makes it possible by omission. I covered how subtle this gets when AI enters the picture in four Dataverse security designs, three of them wrong.

Audit history. Dataverse auditing records who changed what and when, with the prior value preserved (Manage Dataverse auditing). The docs make it sound like a checkbox, and honestly the checkbox part is easy. In production, the parts that earn their keep are retention policy, log capacity management, and whether you can actually answer a question twelve months later. The homegrown failure mode is brutal in its simplicity: a plain UPDATE statement overwrites the old close date, and when the compliance request or the commission dispute arrives, the answer to “who changed this and what was it before” is nothing. Not a bad answer. No answer.

ALM and environments. Power Platform ships a whole application lifecycle discipline - solutions, managed environments, dev-to-prod promotion. The vibe-coded app has one environment, which is production, and its change management is “push to main and refresh.” The failure mode is a Tuesday-afternoon schema change that breaks the thing finance quietly built on top of your API.

Upgrade paths. Dataverse upgrades underneath you. Your standalone app’s framework does not; it rots. And here is a pattern I keep observing, stated as observation rather than measurement: AI-generated codebases are disproportionately hard to refactor, because no human ever held the design in their head. The upgrade path for a vibe-coded CRM tends to be another vibe-coded CRM.

Duplicate detection. Dataverse ships duplicate detection rules at the platform level. Without them, Bob Smith and Robert Smith accumulate as separate accounts, your forecast double-counts, and every inbound sync fans the duplicates further downstream. Nobody notices until the quarterly number is wrong and nobody can say by how much.

Integration surface. Outlook tracking, Teams, finance posting - these exist as supported connectors on the platform. The homegrown versions are bespoke sync jobs, and the characteristic failure is silence: a token expires, the sync stalls, and nobody notices for three weeks because there is no platform telling anyone.

The “invisible 80%” framing is rhetorical, not a measurement. But the direction is right: the visible part of a CRM is the part AI just made cheap, and the invisible part is the part it did not touch.

The real lesson: UI is a commodity, the platform is the moat

Vibe coding collapsed the cost of exactly one layer: the experience layer. Forms, grids, dashboards, the role-specific view a sales manager actually wants - that is now an afternoon of prompting instead of a quarter of development. Good. That layer was always overpriced relative to its difficulty.

What it did not collapse is the governance layer. Row-level security that holds across every access path, audit trails that survive hostile questioning, upgrade continuity, integration contracts - none of that got cheaper, because none of it is a code-generation problem. It is an invariants problem, and invariants are exactly what ad-hoc generated code does not give you by default.

So follow the economics. If the UI is nearly free and the governance is expensive, the architecture that wins is cheap UI on top of foundations you rent. Rebuilding Dataverse semantics in Postgres - security model, audit subsystem, change tracking, duplicate rules, connector surface - is volunteering to own the expensive part so you can save money on the part that just became free. That is the trade backwards.

The hybrid pattern: vibe coding Dynamics 365 instead of replacing it

Here is the architecture I recommend, and it is a recommendation, not a survey of options.

Dataverse stays as the system of record. On top of it, you generate role-specific or process-specific front ends with exactly the vibe-coding velocity the trend celebrates. The first fork in the road is whether you stay inside the platform or step outside it:

The in-platform path - custom pages and PCF controls inside a model-driven app - is where I would start for anything internal. You get the custom UI without inheriting an auth and throttling estate.

An illustrative scenario, explicitly illustrative: a sales rep gets a vibe-coded micro-app that shows only their pipeline, tuned to how they actually work, built in a day. It reads and writes through Dataverse with delegated auth, so their security role scopes what they see, and every edit lands in the Dynamics 365 audit history with their name on it. Your numbers, roles, and timelines will differ. The shape will not.

One honest correction to the usual pitch: security and auditing do not ride along “for free.” They ride along because you made three correct choices - stayed on licensed platform access, used delegated identity, and kept writes going through the governed API instead of around it. Get any of those wrong and the hybrid degrades toward the standalone failure modes. This is the same discipline argument I made in turning work items into specs an AI agent can build from: the governance is in the structure, not the vibes.

And yes, address the elephant: the hybrid pattern does not make the per-seat fee disappear. Users touching Dataverse data need appropriate licences, full stop. What changes is what the fee buys. In the standalone world, you pay zero licensing and instead pay in engineering time, security exposure, and audit gaps. In the hybrid world, the seat price is the rent on the governance layer - the rows in that table above. If the fee still feels wrong after you price the table honestly, that is a negotiation with Microsoft, not an architecture decision.

When a standalone vibe-coded app genuinely wins

The concession, made honestly: there are real cases where the standalone app is the right call. A three-person team with no regulated data, a tool that genuinely dies in six months, a true greenfield with zero integration needs - build the standalone app and enjoy it.

Ask five questions. Do you handle regulated or personal data? Does more than one role need different access to the same records? Do you have audit obligations, contractual or statutory? Does this need to integrate with email or finance? Will it live longer than a year?

The first and third are gates, not points on a spectrum. Regulated data or real audit obligations end the conversation on their own; no count of other answers rescues a standalone build from those two. For the remaining three, treat two or more yes answers as the line - an editorial heuristic, not a measured threshold, but one grounded in the enforcement-location argument above, because each yes is another access path your UI-level controls will not cover.

The sneakiest failure mode is not a standalone app that breaks. It is a standalone app that silently succeeds its way into load-bearing status. Eighteen months later the disposable tool holds the customer master, and nobody ever scheduled the graduation. If you build standalone, write down the trigger that forces the migration review. Today.

Stop asking build vs. buy. Ask which layer you own

The build-vs-buy question is obsolete, because a vibe coded CRM and a licensed platform are no longer competing answers to the same question. They are answers to different layers.

Own the experience layer. It is cheap now, it moves at the speed of your business, and AI generation means you can afford a bespoke front end per role instead of one compromise UI for everyone. Rent the governance layer. It took a decade to harden, it enforces its invariants across every access path including the ones you forgot, and rebuilding it is the expensive project hiding inside every weekend demo.

The teams getting this right are not the ones cancelling platforms or the ones banning AI codegen. They are the ones pointing vibe-coded velocity at the layer where velocity is the whole point, on top of the layer where velocity was never the problem. If you are deciding how much of your data estate an AI-built experience should touch, start with the three context layers of enterprise AI - the same layering logic applies, and it will save you the rewrite.