Spec to Production in Seven Days

I built a complete ecommerce platform for a real shop, by myself, and it went live seven days after the first commit. I want to be careful about what that sentence is and is not claiming. The speed is the headline because it is easy to count. It is not the point. The point is what had to be true, in one person’s head, for a week-long build to come out the other side as a production system that handles real money and that the owner can run without me.

The client is Next Game Performance, a small retailer in Towanda, Pennsylvania, selling used and one-off PC and gaming hardware. A card comes in, gets photographed, gets listed, and there is exactly one of it. The build was unpaid: a proof of concept, mine and theirs, to test whether an AI-native engineer can deliver a real client a real production system at this pace and quality. So there are no revenue numbers in this piece, no conversion lift, no traffic graph. That is deliberate. This is a case study about engineering and judgment, and I would rather show you the part that is true than dress it in metrics that are not.

What I can show you is the system. It is live, it is real, and the shape of it is the argument.

01What seven days actually had to contain

A storefront sounds like a small thing until you write down everything that has to be load-bearing before you can take a stranger’s money in production.

It runs on Next.js 15 and React 19, with Prisma against PostgreSQL underneath. Payments go through Stripe checkout plus webhooks, which means handling the asynchronous truth that a charge succeeds on Stripe’s clock, not mine. Authentication is built on Lucia with Arctic and argon2, the kind of thing people reach for a third-party service to avoid owning. Transactional email runs through Resend, bot pressure gets absorbed by Turnstile, and the interface is Tailwind 4. The data model is twenty-four Prisma models and eight enums, because a real store is not a product table; it is products, variants, carts, reservations, orders, order events, users, sessions, settings, and the relationships between all of them.

None of those are exotic on their own. The work is that all of them had to stand up together, correctly, in seven days, with one person holding the whole graph in mind at once. The speed is not the achievement. The achievement is that nothing got cut to make the speed.

02The part that needed a senior engineer

Most of an ecommerce build is assembly. There is one part that is not, and it is the part I would point a skeptical reviewer at first.

Almost everything Next Game Performance sells is quantity one. That single fact breaks an assumption nearly all store software is built on. When you stock forty of a shirt, two people checking out in the same second is a non-event; the math forgives you. When there is exactly one card, two people paying in the same few seconds means you have taken two payments for an item you can ship to one of them. The forgiveness is gone.

You cannot make that collision impossible, because the gap between reserving an item and a payment actually clearing is distributed across my server, Stripe, and a human typing a card number. What you can do is make it rare and make it loud. So inventory does not get decremented when someone adds to cart. Carts hold short-lived reservations instead, and the true stock count is the real quantity minus everything currently reserved by other carts. The race lives inside the act of taking a reservation, so every reservation attempt on a given product is serialized through a PostgreSQL advisory transaction lock keyed to that product. Inside one transaction: take the lock, read the real quantity, sum the live reservations held by other carts, compute what is actually available, and reject the request if it asks for more than that, surfacing the real available count back to the interface. Otherwise, write a reservation with a fifteen-minute time to live. The lock releases automatically when the transaction ends, so a crash cannot strand it, and a unique item can never be quietly double-sold.

I wrote up the full mechanism, including the code and the oversold-detection path, in Rare and Visible. What matters here is the category of the work. This is not feature output. This is the concurrency reasoning a system needs to stay honest when the real world hits it, and it is the difference between a demo and a thing that takes money.

03Built so the owner does not need me

There is a failure mode in solo-built client work that is worse than a bug. It is the build that only the builder can operate, so the client is permanently tethered to one person who eventually moves on. I designed against that from the start.

The owner is not a programmer and should never have to think about advisory locks or webhooks. So the system gives them a self-serve admin that does the things a shop actually needs: rotating live keys without a deploy, editing site pages through markdown, managing categories, and turning features on and off through settings rather than code changes. The product decision underneath all of it was owner-independence. A handoff where the client still has to call you every week is not a handoff. It is a dependency wearing a handoff’s clothes. The store had to be something they run, not something they rent my attention to keep running.

04Why I trust it, and how it ships

Moving fast is only credible if you can show why the speed did not buy fragility. The answer is tests, written alongside the build rather than promised for later: 316 test cases across the suite, split between unit and integration coverage and end-to-end specs that drive the real flows. The concurrency path, the payment idempotency, the auth, the reservation expiry. The parts most likely to fail quietly are the parts most heavily covered, because a silent failure in a payment system is the expensive kind.

It does not run on a managed platform that hides the operations from me. It is deployed to a Hostinger VPS on Ubuntu 24.04, with systemd supervising the process, nginx in front, and certbot handling Let’s Encrypt certificates. Hand-rolled, on purpose. Owning the deploy means I understand every layer the request passes through, which is the same instinct as owning the auth and owning the inventory lock: when it is your client’s money, you do not want a layer you cannot reason about.

05What this is actually about

The honest read on this build is not “look how fast.” Fast is cheap, and anyone selling you on speed alone is selling you the easy half. The real claim is narrower and, I think, more interesting.

One person, working AI-native, carried a real production system, payments and auth and concurrency and operations and a non-technical owner’s daily reality, from spec to live in a week, and held all of it at quality the whole way. That is not a story about a store in a small Pennsylvania town. It is a small, real data point about what the unit of delivery is becoming. The question every team is about to be asked is what one capable person plus the right tools can now own end to end. This is one answer, shipped, taking real payments, running without me.

That is the work I care about. Not the demo that looks right on a stage. The system that stays honest when a stranger clicks buy, and that the person who owns it can run long after I have moved on to the next thing.

Drafted with Bishop, my AI partner.
Words picked, edited, and approved by me.