Everything a store needs
after 'Add to cart'.
Most ecommerce quotes cover the storefront: design, product pages, a payment gateway connected. What decides whether you can actually run the business sits behind the checkout, and it is rarely itemised. This is a build note on two production stores we designed, built and operate ourselves - what is in them, and why each piece is there.
These two stores are our own products, not client work. We are showing them because we can open the code, the database and the admin panel, which we cannot do with a client's store. Deliberately, there are no sales figures anywhere on this page: it is a note about what was built and what production taught us, not a claim about what it earned. Our results work is on the case studies linked at the end.
- Subject
- Two of our own stores
- Stack
- Next.js, Payload, Postgres
- Payments
- Razorpay (INR), PayPal (USD)
- Live since
- July 2026
A storefront is not
a working business.
A quote for an online store almost always describes the part you can see. Design, product pages, a cart, a payment gateway connected, a contact form, an analytics tag. All of it necessary, none of it sufficient.
The moment real money moves, a second set of problems arrives and none of it is visual. A customer pays and the confirmation has to reach them whether or not the gateway's webhook turned up. An invoice has to exist, with a number that has never been used before. Someone reaches the payment screen, gets distracted, and closes the tab - and either something follows up or that sale is gone. A sale happens, and the ad platform that produced it has to be told, exactly once.
None of that is exotic and none of it is optional. It is simply the part that does not appear in a screenshot, so it does not appear in most quotes either. We built both of our own stores on the assumption that this layer is the actual deliverable and the storefront is the easy half.
What gets quoted.
What has to exist.
Neither column is wrong. The left is what an ecommerce build usually includes; the right is what a store still needs on the day it starts taking money. The gap between them is where the arguments with your developer happen six months in.
The left column is a website. The right column is the business. A build that stops at the first one hands you the second as homework.
What is actually
in the box.
Counted from the repositories and the live databases rather than estimated. The two stores share one codebase and diverge only where the tax treatment and the payment gateway force them apart.
| Component | Detail |
|---|---|
| Payment gateways | Razorpay + PayPal |
| Currencies and tax treatment | INR at 18% + zero-rated export |
| Admin collections | 14 |
| Site-wide settings groups | 2 |
| API endpoints | 13 |
| Automated email flows | 11 |
| Maintenance and migration scripts | 41 |
| Test files | 14 |
| Application code | ~20,600 lines |
The two sites are one codebase with a deliberate seam. Everything above that seam - page copy, programmes, the About text - is byte-identical. Everything below it is site-specific, because one sells domestically with tax added and the other sells overseas as a zero-rated export, and those are genuinely different products in law even when they are the same product on screen.
That seam is the interesting design decision. Sharing too little means every fix has to be made twice; sharing too much means one site's legal text quietly overwrites the other's. We have made both mistakes on this codebase and the seam is where we landed.
Four things that only show up
once real money moves.
Every one of these is a bug we shipped in our own store and then had to find. They are on this page because they are the ones a build gets wrong quietly - nothing errors, nothing alerts, and the damage is only visible if you go looking.
The webhook that arrives late, or never
A payment gateway confirms a sale by calling your server. That call can be slow, can be retried, and can be lost. If the confirmation page trusts the webhook alone, a customer who has genuinely paid sits looking at a pending screen, and if it trusts the browser alone, a customer who has not paid gets the goods.
The answer is both paths and one source of truth: the success page actively asks the gateway what happened rather than waiting to be told, and fulfilment runs once no matter which path gets there first.
The invoice number that must never repeat
Sequential invoice numbering sounds like a solved problem until you run two storefronts under one tax registration. Both of ours did, both used the same prefix, and each kept its own counter in its own database. Two sequences, both starting at one.
It had already collided before anyone noticed, because nothing about a duplicate invoice number makes an error appear. It is only visible when someone reconciles the books, which is the worst possible moment to find it.
The conversion that gets counted twice
Send a purchase event from the browser and again from the server - which you should, because browsers block the first one - and the ad platform counts two sales unless both copies carry the same event id. Reporting then shows roughly double the truth, which is the most expensive kind of wrong number, because you will scale spend against it.
The related trap is firing the event on the wrong page state. A purchase event that fires when the confirmation page loads, rather than when the order is actually paid, counts abandoned checkouts as sales.
The file that was uploaded but never linked
Our own worst one. Digital products were uploaded correctly into the admin, and the record that points a product at its file was left empty. The download route fell through to a fallback that did not exist, and every buyer got a placeholder message instead of their book.
Nothing failed. No error, no alert, no failed payment. It ran that way for six days before anyone bought and checked. A build is not finished when the feature works once in testing; it is finished when the thing that breaks it silently has a check in front of it.
How this was built
Both stores were built by a senior developer working with AI assistance throughout - which is why two full storefronts, two payment integrations and two tax regimes exist at all at this size. It is worth being plain about what that does and does not change. It compresses the time between deciding something and having it running. It does not decide that the invoice counter needs to be keyed to the financial year, or notice that a download has been silently broken for six days. Every one of the four problems above was found by a person looking at production, and that is the half of the job we are actually selling.
What people ask us
before commissioning a build.
What should an ecommerce build include beyond the storefront?
At minimum: invoicing that produces a correctly numbered document for every order, order confirmation that survives a late or missing payment webhook, abandoned checkout recovery, server-side conversion tracking that does not double-count, and secure delivery if you sell files. Ask for those five by name when you compare quotes. They are the items that are usually absent, and they are the ones you cannot add cheaply later because they touch the order record itself.
Should I use Shopify or a custom build?
Shopify for most stores, most of the time - it already solves the layer described on this page and you should not pay to rebuild it. A custom build earns its cost when the product is not a normal product: gated content, licensing, unusual tax treatment, a booking model that does not fit a cart, or an integration that has to run inside your own system. Both of the stores here are custom because they sell books and coaching under two different tax regimes from one codebase, which is exactly the case a platform handles badly.
Does my store need tax invoicing built in?
If you are registered for GST in India, yes, and it needs to be part of the order flow rather than something you produce afterwards in a spreadsheet. The invoice number has to be sequential and gapless within the financial year, the tax split depends on where the buyer is, and export sales are treated differently again. Retrofitting this to a store that has already taken orders is considerably more expensive than building it in, because the historic orders have to be renumbered.
Does AI make an ecommerce build cheaper?
It makes it faster, which is not the same thing. The build time for the visible half falls a lot. The half described on this page - deciding what has to exist, then finding the failure that produces no error message - is unchanged, because it depends on knowing what to look for in production. Expect a shorter timeline and a better-specified system for your money, rather than the same system at a fraction of the price.
To say it once more plainly: the two stores described here are our own products, not client work, and no sales figures appear on this page. Everything counted above was read off the repositories and live databases on 7 September 2026. We are happy to screen-share the admin panel and walk through any of it on a call.
Check what's missing from your quote.
Commissioning a store and not sure what should be in the quote? We will go through the list on this page against what you have been offered, and tell you what is missing - whether or not you build it with us.