Custom e-commerce is worth considering when the way you sell and deliver calls for features that are difficult to support in your current setup. Examples include configurable products, specific pricing rules or orders that several people need to handle before delivery. We should examine where custom code adds value and which parts we can retain or reuse.
At Færder Marketing, we consider Astro and React for the pages customers use, alongside a backend that handles the shop’s rules and data. This can offer considerable flexibility. Its practical value lies in helping customers complete their task and staff process the order correctly.
Start with what is difficult to do today
Write down specific situations. Does a customer have to call to get the right price? Do staff enter the same order in several systems? Can a product be sold online when an essential component is out of stock? These questions provide a better basis for a decision than a general wish for a more modern platform.
If your current Shopify or WooCommerce shop handles commerce well, an improved product page or one new integration may be enough. A new design does not necessarily require a new commerce system either. A rebuild should address tasks that matter to customers, staff and the business’s finances.
Three choices that are often confused
A theme controls much of the presentation. The commerce platform handles products and orders, among other things. The development tool is what we use to build the solution. Astro, Shopify and Lovable therefore describe different things rather than three directly comparable alternatives.
- A customised shop on an established platform: we use the platform’s features and extend them where needed.
- A custom frontend with an established commerce platform: we build the customer-facing pages and connect them to the platform. This is often called headless commerce.
- A custom frontend and custom commerce logic: we also define the product model, rules and workflows behind the sale, reusing suitable libraries and services.
A custom frontend gives us control over presentation, while the commerce platform’s data model and API still set boundaries. Shopify, for example, documents APIs for products, carts and customer accounts in its headless commerce documentation. We need to examine both sides before committing to a particular feature.
Why we would consider Astro for a new online shop
Many online shops combine readable product pages, categories and guides with a few more interactive tasks. Astro fits this structure well. We can build the pages with HTML and use React for filtering, comparisons, product choices and the cart. Astro documents how these interactive components can load independently of the rest of the page.
Astro can also generate pages on the server when they are requested, so we do not need to rebuild the entire website whenever a price changes. We still need to plan how prices, stock and cached pages stay up to date. See Astro’s server rendering documentation.
Astro is one possible foundation for the website. Product administration, order processing and sign-in also need to be part of the solution. Other frameworks can offer similar flexibility, and a system dominated by signed-in workspaces may call for a different structure. Code ownership and a well-designed data model matter more to control than the framework’s name.
A hypothetical example: configuring a bed
Imagine a bed retailer whose customers can choose the size, fabric, legs, headboard and a different firmness on each side. This is a hypothetical example of a possible solution, not a description of a launched client project.
A configurator could show which choices work together, update the image and explain the delivery time. Customers could save their configuration, share it with a partner and bring it to the physical shop. A member of staff could open the same configuration and help them continue.
Behind this, we need a model for components, permitted combinations, stock codes and availability. A headboard with its own stock count is different from a text field recording a customer preference. The supplier needs an order it can fulfil, and customer service needs to see exactly what was agreed.
When the order is created, we record the price and specification as they were at purchase. Later product changes must not alter the historical order. This is an important aspect of custom development: we can shape the data around how the business actually sells.
The database: PostgreSQL and how it is managed
PostgreSQL is a natural starting point for connecting products, components, customers, orders and inventory. It supports transactions: several database changes can succeed together or be cancelled together. We can use this to save an order and a stock reservation as one operation. Correct implementation is essential, and a payment with an external provider does not become part of that same transaction. PostgreSQL explains the principle here.
Supabase is one possible service built around PostgreSQL, with features including authentication and file storage. Each project gets a PostgreSQL database. This can reduce infrastructure work, while we still define the data, access rules and shop functionality. Supabase describes its database setup here.
We can also manage PostgreSQL ourselves. That brings more responsibility for updates, capacity, monitoring and recovery. Both options let us define our own product model. PostgreSQL data can be moved, but using a service’s specific authentication, storage and integration features can make a later migration more involved.
Administration is part of the product
A shop needs interfaces for editing products, images, campaigns and content as well as processing orders. Staff should be able to make routine changes without editing code. An existing content editor may cover some needs, while specific tasks may benefit from a custom interface.
We also need to decide which system is authoritative for prices, stock and order status. If the point-of-sale system is the source of stock figures, the online shop must respect that. Integrations need to tolerate interruptions and show staff what requires attention. An accounting integration failure can then be handled without losing the order.
Boxx shows why workflow matters
In our work on Boxx, we have developed a digital experience for finding, comparing and ordering containers. The solution includes product and depot information, buying guidance and workspaces for following up suppliers and transport. These needs make the connection between customer-facing pages and operations clear. See the Boxx case study.
Boxx was developed using Lovable and custom code. It is not an example of an Astro shop. Kjetil is also involved in strategy and business development through K28. The example illustrates structure and functionality; it is not evidence of sales results or the effect of a particular framework.
What needs to work after the customer places an order
Payments, stock reservations, delivery, cancellations and refunds need clear states and responsibilities. A repeated payment notification must not create another order. We need to validate prices and product choices on the server and test what happens when two customers try to buy the final item at the same time.
Security also covers what customers and staff can view or change, how personal data is handled and who responds to faults. Read the questions to ask about security. AI can assist development, but does not replace these checks.
Backups need to cover both the database and files, and restoration must be tested. Supabase notes, for example, that database backups do not include the files held in Storage. The setup should reflect how much data loss and downtime the business can tolerate. See the backup documentation.
Assess flexibility alongside cost and handover
Custom development involves work on features an established platform may already provide. Compare both development and several years of operation: service subscriptions, maintenance, integrations, editing and your own staff time. Clarify code rights, account access, data export and how another developer could take over. Keeping code in Git is only one part of this.
Plan the transition from your current shop too. Products, images, customer information and order history each need assessment. Preserve useful URLs or give them relevant redirects. Product information for search and advertising, purchase measurement and integrations need to be checked in the new solution. Astro alone does not guarantee better visibility or more sales.
Start with one demanding order
Before building the whole shop, we would choose one product with the most demanding options and take it through a working trial: configuration, pricing, delivery, test payment and processing in the administration interface. Include a change, an out-of-stock component and a refund. This gives us a concrete basis for assessing the solution and its scope.
Bring three things to an initial discussion: an example of a difficult order, an overview of your current systems and the tasks that take staff the most time. Use the customer journey article to map the wider picture. We can then assess what to improve, connect or build as part of the online shop project.
