All posts

Vibe Coding 馃5 min read

You Can Vibe Code A Storefront. You Cannot Vibe Code A Backend.

AI is excellent at the half of a store you can judge by looking at it, and dangerous at the half where being wrong is invisible until it costs money. That line is also where the platform decision sits.

By Juan Molina

Blog title card reading Vibe Code The Storefront Not The Backend, beside an illustration of a colourful storefront page on one side and a plain dark server and database on the other, joined by a single arrow

There is a split in every online store that nobody points out to people who are building one for the first time, and almost every vibe coding failure sits on one side of it.

The storefront is what customers look at. Layout, product pages, the cart drawer, the copy, the animations, the way it behaves on a phone. The backend is what the business runs on. What a thing costs, how many exist, what was ordered, who paid, what shipped, what got refunded.

AI is genuinely excellent at the first one. It is dangerous at the second one, and the reason is structural rather than a temporary gap in model quality.

Why the storefront suits this so well

You can evaluate a storefront by looking at it. The feedback loop is immediate and complete: describe it, see it, say what is wrong, see it again. Nothing is hidden from you, because the output is the thing you are judging.

That is the ideal shape for working with a model. Whatever you cannot articulate, you can point at. This is why vibe coded landing pages are frequently very good, and it is not luck.

Why the backend does not

Now describe correct.

A backend is right when stock cannot go negative under two simultaneous orders. When a refund moves the exact tax portion. When a webhook arriving twice does not credit an account twice. When a payment that times out after charging the card resolves into one order rather than zero or two.

None of that is visible. All of it looks identical to broken until the specific circumstance occurs, and the circumstances arrive at volume, which is to say when you are finally succeeding. You cannot point at a race condition in a preview.

So the loop that makes vibe coding work is simply absent. You are accepting code on the basis of it appearing to run, and appearing to run is exactly what an incorrect backend does.

The list nobody estimates correctly

People think of a backend as a database and some endpoints. The actual list, for a store that takes money:

Products with variants that each hold their own stock. Stock that decrements at payment rather than at dispatch. Carts that survive a refresh. A checkout that cannot be manipulated from the browser. Payment capture that is safe to retry. Tax. Shipping rates that are live, and labels. Orders that support partial shipment and partial refund. Customer accounts that can only read their own data. Webhooks that are signed and deduplicated. Refunds with the right tax split. An audit trail, because at some point somebody will ask why a number changed.

Every item is unglamorous. Every item is solved. Every item will take you longer than you think and is worth nothing to your customers, because they expect all of it and notice none of it.

So use a platform. Which one is the actual question

The conclusion most people reach here is Shopify, and for a lot of people that is correct, so it is worth being precise about when it is not.

A hosted platform gives you the backend and the storefront together. That is the whole proposition, and if you want to pick a theme and start selling, nothing beats it. The catch for anyone reading this is that it also means the storefront is theirs. You get a theme system and a template language, which is the one part you were enjoying and were good at.

Vibe coding against a theme system is a worse experience than vibe coding a fresh application, because the model is now working inside somebody else's constraints, with its own conventions, that it half knows.

The shape that actually fits is a backend with an API and no opinion about your front end. You write the storefront in whatever you and your model are best at, and the transactional half is somebody else's problem. This is just headless commerce, a decade-old idea that happens to describe exactly what vibe coding needs.

Where we fit, and where we do not

That shape is what dashfordevs is. Catalog, carts, checkout, orders, customers, inventory and shipping behind an API, with publishable and secret keys separated so the right one can live in your bundle, and server-side pricing so a total cannot arrive from a browser. You write the storefront. We are not going to have opinions about your CSS.

We also take the categories hosted platforms decline, which matters more than feature comparisons if you sell hemp or THCA, because the best platform in the world is useless if it closes your account.

Where we are the wrong answer, and this is a lot of people: if you want to be selling this afternoon without writing a storefront, take Shopify, and it is not close. If you are selling twenty items to people you know, any hosted platform is less work than an API. And if you are not going to write any front end code at all, our half of the split is the half you did not want.

The rule

Vibe code the part you can judge by looking at it. Do not vibe code the part where being wrong is invisible and expensive.

That line runs between the storefront and the backend, and it is the same line the platform decision runs along. Getting it right is mostly a matter of noticing it is there.

If you want to see what the other half looks like as an API before deciding anything, the docs need no account to read.

Tagged

  • vibe coding
  • architecture
  • ecommerce
  • shopify

Related Blogs

More from the blog, picked at random. Everything published is on the index.

1 of 15

Build on It Yourself

Sign up, take your keys, and scaffold a storefront against a real backend.

Vibe Code The Storefront, Not The Backend 路 DashForDevs