“I want an online shop built from scratch” usually means “I want a shop that does what templates do not”. And what templates do not do is almost always the same: talk to whoever manufactures, whoever ships and whoever collects payment, without a person copying data from one screen to another. This article explains how we structure that work in five layers, what each carries and the order they are built in. The examples come from eclipseando.com, a shop of ours in production, and from the carrier connectors we have published for Odoo.
Key idea: the front end is the most visible layer and the least risky. Where money gets lost is in the three in the middle: a checkout that can be tricked, data that lives in two places and a provider whose orders are passed on by hand. You build from the inside out.
The five layers of a shop
| Layer | What it contains | Typical error when skipped |
|---|---|---|
| 1 · Data | Catalogue, prices, stock, orders, customers. A single source of truth. | The website price and the ERP price drift apart within two months. |
| 2 · Checkout | Basket, price and shipping calculation, gateway, payment confirmation by webhook. | Trusting the thank-you page and preparing an order that was never paid. |
| 3 · Providers | Manufacturer, warehouse, carrier: outbound order, label, tracking, incidents. | Tracking is copied by hand and reaches the customer, if at all, a day late. |
| 4 · Scheduled jobs | Queues, retries, mailbox reading, stock sync, reminders. | An email that fails one night is lost forever. |
| 5 · Front end | Pages, product sheets, search, languages, speed, SEO. | You start here, show something pretty, and improvise the other four afterwards. |
Layer 1: data lives in one place
Before drawing a single screen you have to decide where the catalogue lives. If the client has Odoo, the answer is Odoo: products, prices, stock and orders are there and the website reads them, it does not copy them. If they do not, the shop needs its own database, and it should be small and boring. On eclipseando.com it is SQLite, in one file, with backups. What cannot happen is the price living on the website and also in a spreadsheet and also in the ERP: within two months they are three different prices.
Layer 2: the checkout does not trust the browser
Two rules we do not negotiate. First: the price is computed on the server, against the current catalogue, when the payment session is created. The browser may keep the basket, but it does not get to say what it costs. Second: an order is paid when the gateway confirms it with a signed webhook, not when the customer lands on the thank-you page. With Stripe that is checkout.session.completed with the signature verified; other gateways call it something else with the same idea. And if the next step fails when the webhook arrives, you return an error so the gateway retries, and you store the session id so you never produce twice.
Layer 3: every provider talks the way it can
This is where “logistics integration” stops being a word and becomes work. A provider with an API and a webhook (an on-demand printer, a large carrier) is integrated in both directions: the order is created on payment and its “shipped” notice is listened for to pass tracking on to the customer. One with a dropshipping API is integrated one way and queried the other: before charging, real availability per country; afterwards, the order. And one without an API, of which there are many, is integrated by reducing the human work to one click: the system produces exactly the email or CSV the provider needs, and if its parcels go out with a carrier that sends emails, those emails are read and turned into statuses.
Two details you only learn with real orders. One: tracking goes per shipment, not per order, because an order with two products from two providers is two parcels. Two: the lead times in the provider's documentation are not the ones it meets; you measure them by creating test orders and reading what comes back, and those are what the customer sees before paying. When the provider is a carrier and the shop runs Odoo, all of this is already solved in the carrier connectors we publish: label, tracking, manifest and return inside the delivery order.
Layer 4: what runs on its own and what gets retried
A shop has work that cannot depend on someone remembering it: draining the email queue, retrying paid orders that never reached the provider, reading the carrier's mailbox, syncing stock with marketplaces. Each is a scheduled job with an interval and a log. The design rule is that none of them calls an external service in the path of a user request: the page reads what the job left in cache. That way, if the provider goes down at three in the morning, the shop keeps serving pages and the orders are retried when it comes back.
Layer 5: the front end, last and fast
With the four layers below solved, the front end is the most rewarding part. We prefer static sites generated at build time (Astro on eclipseando.com) served by nginx or Caddy: they load instantly, there is no database to attack and they cost what a small server costs. Dynamic parts (basket, payment, order status) go through a separate API. Multilingual is done with one URL per language and own copy, not a machine translator on top, and is tested by checks that every template exists in every language. And speed is measured before publishing: page weight, images at the size they are painted, nothing blocking the first render.
The order matters: from the inside out
The most expensive mistake we see is starting with layer 5. A pretty website is shown in week two, the client gets excited, and layers 1 to 4 are improvised underneath in a hurry. The result works until the first order with two providers, or the first lost webhook. We build the other way round: first data and checkout with their tests, then the integrations with real test orders, then the scheduled jobs, and the front end last, when it is already known exactly what it has to show. It takes the same time. Far less gets redone.
Frequently asked questions
When does it make sense to build the shop from scratch instead of using Shopify or Odoo Website?
When the value lies in what the platform does not ship: an own computation, integrations with providers that have no connector, a catalogue that is not a catalogue. If your shop is a normal catalogue with a normal carrier, a platform is cheaper and the right answer. We go into it in when to build the site on Odoo Website and when not to.
What about a provider that has no API?
It gets integrated all the same, through another channel: the system generates the exact email or CSV it needs, in one click, and reads whatever the provider or its carrier sends back by email. It is not as clean as an API, but it removes the manual copying, which is where the mistakes happen.
And if I already have Odoo?
Then layers 1, 3 and 4 largely exist already: the catalogue and orders live in Odoo, carriers come in through published connectors and the scheduled jobs are the ERP's own crons. What gets built is the front end and, if needed, a custom checkout connected to Sales.
Useful links inside FlexigoTech
Got a shop in mind that does not fit a template?
Tell us what you sell, who makes it and who ships it. We will send back the five layers with what goes in each and in which order. Email comercial@flexigobe.com or call +34 616 809 504.