Ecommerce development: when a store needs its own system
How to approach ecommerce development when a store needs its own catalogue, variants, orders, SEO structure and admin panel.
A company rarely asks for ecommerce development because it wants a prettier online store. It usually gets there when selling online starts to collide with the real business: difficult product variants, made-to-order workflows, product pages that do not fit a template, orders that need tracking, or a catalogue that should bring organic search demand and does not.
The easy mistake is to choose a platform by its feature list. Cart, payments, coupons, search, admin, invoices, shipping. All of that matters, but it does not answer the main question: which part of the store is standard, and which part is specific to the business?
Custom ecommerce development makes sense when the catalogue, the order flow or the way the company sells are specific enough for the store to be designed around the business, not around a template.
What ecommerce development really means
Developing an ecommerce store is not just launching a shop. It means designing a selling system: catalogue, product model, variants, content, cart, checkout, orders, administration, images, SEO, support and sometimes production.
There are many stores where an off-the-shelf platform is the right answer. If you sell simple products, with few variants, a conventional checkout and no unusual rules, the sensible thing may be to use an existing platform and focus on product, brand and acquisition.
Custom ecommerce development starts to matter when the store is not just a surface layer, but part of the business itself. For example:
- The product has variants, exceptions or configurations that a template handles badly.
- The order does not end at payment: it goes through production, review, shipping or manual delivery.
- The catalogue needs pages by search intent, not just generic categories.
- The admin panel has to reflect how the team works, not how the platform works.
- Integrations or rules must live on the server, not in loose spreadsheets.
- The order data must remain stable, even if the product changes later.
In those cases, the store is not a website with a cart. It is a commercial and operational system.
Template, platform or custom system
Not every ecommerce project should be built from scratch. Many should not. The decision usually has three levels.
The first level is a template on top of a market platform. It is fast, sufficient and reasonable when the business fits the platform’s model. The second level is a configured and extended platform: you keep its foundations, but add integrations, themes, automations or small custom pieces. The third level is a custom system: catalogue, orders and administration are designed for the specific case.
The mistake is choosing the level because it sounds better. Building everything from scratch to sell a handful of simple products can be a bad decision. Forcing a complex catalogue into a template can be just as bad.
The question I use is simpler: where is the real complexity? If it is mainly in marketing, you probably do not need a custom store. If it is in the product, the order flow, operations or data, the project deserves a different conversation.
That is also how I would connect ecommerce development with custom web applications: not as a list of screens, but as a system design decision.
Catalogue: a product is rarely just a product
In a small store, it is tempting to think in products. In a real store, what is sold is often a combination: product, presentation, size, finish, availability, personalization, delivery option or condition.
If that model is forced into a generic product page, workarounds appear quickly: duplicated titles, badly named variants, values corrected by hand, stock that does not mean what it seems to mean, or descriptions that mix different things.
The catalogue has to answer practical questions:
- What is the thing that is actually being sold?
- Which options change the order, and which only change presentation?
- Which data is inherited, and which data belongs to each variant?
- What does the customer need before buying?
- What does the team need after the order arrives?
Lantilla.com is a good example. It is an ecommerce store for original photography from La Antilla and Islantilla. The important decision was that the store does not sell an abstract photograph: it sells a photograph in a specific presentation and size. The system contains 186 photographs with their own page, 16 thematic collections, two presentations and an order flow with six documented states, from pending to delivered or cancelled.
That kind of model is not solved by adding fields at random. First you understand what is being sold; then you design the store.
Orders: store what happened, not what exists today
A serious ecommerce system cannot depend on the current catalogue to explain old orders. When someone buys, the order has to keep a snapshot of that moment: title, variant, conditions, address, state and any data needed to produce or deliver.
This prevents very specific problems. If tomorrow you change a description, image or product configuration, the old order should not be reinterpreted. If a product is unpublished, the order should still make sense. If there is an issue, the team needs to see exactly what was bought.
The store also needs states that match the business. “Paid” is not the same as “in production”, “prepared”, “shipped” or “delivered”. If the product is made to order, the admin panel cannot be just a purchase list. It has to be an operations tool.
This is where ecommerce development becomes close to custom software. The public site sells; the internal system makes that sale fulfilable.
SEO: a store should not generate empty pages
Many stores fall into the opposite trap: creating thousands of URLs just because the system can. Category, tag, colour, use case, season, city, gift, room. If there is no real product and no clear intent behind the page, that is not architecture. It is noise.
The better alternative is slower: one page per intent when the catalogue can support it. A collection, use case, gift idea or customer type deserves a page only if it helps someone choose and if there are real products behind it.
In Lantilla.com, public pages are organized by collection, place, style, season, tag, room, gift and type of business, but not as an infinite URL factory. The editorial rule matters: fewer pages, each backed by real photographs.
That matters for search, but also for buying. A person does not always enter the store searching for an exact product name. They may search for an idea, a use, a place or an intention. The store has to respond to that without becoming a maze.
The admin panel decides whether the store can be maintained
The public side of an ecommerce project usually gets all the attention. But the store is won or lost in the admin panel: products, variants, images, orders, pages, states, support and content.
A custom admin panel does not mean filling the company with buttons. It means removing fragile steps. If the team has to edit the same data in three places, something is wrong. If publishing a page depends on remembering a convention, it will eventually break. If a critical rule lives in a spreadsheet, it does not belong outside the system.
AI can help in some parts, but it should not be in charge. In a catalogue, it can suggest tags, text or groupings. But if the vocabulary has to remain stable, the system must constrain what the model is allowed to say. In Lantilla.com, vision-based tagging works against a closed vocabulary: the model cannot invent new tags every time it looks at a photo.
That is the difference between using AI as assistance and letting it disorder the catalogue.
When I would not build a custom ecommerce system
I would not build a custom store if the catalogue is simple, if the sales model changes every week, if nobody will maintain content and orders, or if the main uncertainty is commercial rather than technical.
Before building, I would check:
- What exactly is being sold.
- Which variants change the order.
- Which data must be frozen at purchase time.
- Which states the operation needs.
- Which pages answer real search intents.
- Which integrations are essential from day one.
- Which parts can be handled by an existing platform.
If these answers are not clear, the first job is not programming. It is modelling the store.
An online store is not good because it has many features. It is good when the catalogue, the order flow and the operation fit how the business really sells.
If your ecommerce project does not fit a template, I would approach it as a system: start with catalogue and operations, decide what should be custom, and build only what the business actually needs to sustain.