Let me tell you about the fastest I've ever started a project, and how that speed quietly turned into the slowest middle I've ever lived through.

The shortcut that felt like cheating

The project was a large OTA-style travel platform. Multiple front-ends (a B2B portal, a B2C site), an admin to run them, application forms, document verification, the works. Plenty of surface area.

So at the very start, I made a decision that felt incredibly smart. I didn't build a backend at all. I reached for PayloadCMS and ran everything through it.

If you haven't used it, Payload is a TypeScript-first headless CMS where you define your data as "collections," and it hands you a backend and a polished admin UI for free. And I do mean free. You describe the shape of your data, and the dashboard, the auth, the REST and GraphQL APIs, the relationships, all of it just appears.

That solved two real problems in one move. It gave the team a genuine CMS to edit content and filters, and it gave me an admin UI without me building a single screen. For the first stretch of the project, it was glorious. We moved *fast*. Features that would normally take days were taking hours.

I was convinced I had outsmarted the work.

Where it started to hurt

Then the project did what every serious project does. It got complicated.
The flows we needed stopped looking like "edit a record." We needed multi-step verification where each stage gated the next. We needed custom logic woven deep into how data was created and validated. We needed the admin experience to behave in ways that didn't map cleanly onto "a form for a collection."

And slowly, the relationship flipped. Instead of Payload doing the work for me, I was doing work for Payload. I was fighting its architecture to build the things I actually wanted, bending the tool around requirements it was never shaped for. Every custom requirement turned into a research project: can Payload even do this, and if so, how much do I have to contort to get there?
The speed was gone. I just hadn't admitted it yet.

The escape hatch that wasn't

Here's the part I want you to really hear, because it's the trap inside the trap.
When a tool starts fighting you, the obvious move is a compromise: keep the tool for the easy 80%, and build the hard 20% separately. Keep Payload for the simple content, and stand up something custom next to it for the complex flows.

It sounds reasonable. It is a disaster.
The moment you have two systems, you have a boundary between them, and that boundary needs to stay in sync. Data lives in two places. You write glue code to shuttle it back and forth. The two systems drift, and you write more glue to reconcile them. Now you're not maintaining one backend or even two backends. You're maintaining two backends and the fragile seam between them.

The "fast" option had quietly become the slowest possible architecture. I had all the constraints of Payload and all the work of a custom backend, with a synchronization headache stapled on top.

Ripping it out

So I made the call that, in hindsight, I should have made earlier. I ripped Payload out and built the backend myself. It was more work up front, no question. But for the first time on that project, the tool stopped being the bottleneck. When I needed a weird flow, I just built the weird flow. No contorting, no research project, no seam to babysit.

The lesson I keep relearning

Let me be very clear about something: this is not a knock on Payload. It is a genuinely excellent tool, and it did exactly what it promises. The mistake wasn't choosing Payload. The mistake was choosing it for the wrong project.

So here's the rule I use now, and it applies far beyond Payload. It's true of any "instant backend," any low-code platform, any tool that trades flexibility for speed.

If you already know a project is going to be complex and highly custom, and you have the team and the ability to build the real thing, build the real thing.

Pay the cost up front. Buy the foundation.

When the shortcut is the right call

To keep myself honest, the inverse is just as important, because "always build it yourself" is its own expensive mistake.

Reach for the shortcut when:

• You're validating an idea and speed matters more than the ceiling.
• The project genuinely *is* mostly content and CRUD, and you have good reason to believe it'll stay that way.
• You don't have the team or time to build and maintain a custom backend.
• The cost of being wrong is small, because you can throw it away cheaply.

Payload is a fantastic fit for all of those. I'd reach for it again tomorrow on the right project. I'd just never again hand it a project I already knew was going to outgrow it.

May your shortcuts be the right ones! 🍻