eCommerce development that respects your catalogue and your margin
A store is not a brochure site with a cart bolted on. It is an operations system with a shopfront attached, and almost everything that goes wrong with one goes wrong after launch.
What is eCommerce development?
eCommerce Development is the end-to-end build of an online store: catalogue and product data architecture, payments, tax and freight configuration, fulfilment integration, subscriptions and reporting. It suits Australian businesses selling to consumers or to trade who need the storefront, the warehouse and the accounting ledger to agree with each other every day.
Get a fixed written quote- Typical timeline
- 7 to 14 weeks
- What drives cost
- Catalogue size and data quality, how many systems must connect to the store, and whether you are migrating history from an existing platform.
- Best for
- Merchants whose store has to run operations, not just take orders
- You own
- The storefront code, the customer and order data, every account
- Built with
- Shopify Plus, BigCommerce, headless storefronts, integration layers
Your handover
What makes a store build different from a website build
A brochure site has one job: persuade a visitor to make contact. A store has to persuade, price, apply tax, reserve stock, charge a card, pick, dispatch, notify, accept a return and then reconcile all of it against your accounts. Each of those steps is a place where margin leaks quietly, and none of them are visible on the homepage.
- 01Product data model and catalogue taxonomy
- 02Storefront built to your design system
- 03GST, freight zone and payment configuration
- 04Fulfilment and carrier tracking integration
- 05Accounting and inventory system connections
- 06Subscription or recurring order flows where required
- Migration of products, customers and order history with redirects
- eCommerce measurement and reporting configured
- Trade rehearsal results and staff operating documentation
How a partial shipment appears to the buyer, to your bookkeeper and to the courier
So we open a commerce project with operations rather than artwork. Which system holds the authoritative stock figure. What happens when a customer buys the last unit thirty seconds after a wholesale order claimed it. How a partial shipment appears to the buyer, to your bookkeeper and to the courier. How a refund travels back through the payment provider, the ledger and the stock record. Settle those in writing and the build becomes execution. Leave them until testing week and you launch something that behaves beautifully on demonstration data and unravels by the second Monday.
Having the trade off written down turns that into a short conversation rather than an argument.
Catalogue architecture decides everything downstream
The product data model is the single most consequential decision in an eCommerce development project, and it is usually made in an afternoon by whoever is doing the import. Get it right and filters, search facets, marketplace feeds, packing slips and reporting all fall out of one structure. Get it wrong and every one of those becomes a manual workaround that somebody maintains forever.
The full list
We model products the way customers choose them, not the way your accounting system stores them. A trade buyer searching by thread size and material does not care that your ERP groups by supplier. We also decide early what a variant is versus what is a separate product, because that boundary determines how reviews accumulate, how stock is counted and how your feeds behave. Where the catalogue is large or moves fast, the sensible answer is often to make an inventory system the source of truth and let the store consume it.
- A product, variant and option model that matches how buyers actually choose
- Attributes that drive filters, facets and channel feeds from one source
- Bundles, kits and made to order lines handled explicitly, not faked with order notes
- Image and video standards including the aspect ratios each channel demands
- Naming and code conventions your warehouse staff can read on a pick slip
- A content template so new lines launch complete rather than half described
How the engagement runs
How an eCommerce build runs
We sequence an eCommerce development project so the risky parts happen early and the visible parts happen once the risky parts are settled. Data migration and integration are the usual sources of delay, so they start in the first fortnight rather than the last.
- 01Commercial discoveryMargin by line, freight profile, return rate, repeat purchase behaviour and which systems already hold the truth
- 02Data modelProducts, variants, options, bundles and the attributes customers filter by
- 03Stage 3Platform decision recorded in writing with the reason and the constraint you are accepting
- 04ConfigurationMarkets, GST treatment, freight zones, payment methods, order statuses and notification templates
- 05BuildStorefront, whatever checkout adjustment the platform permits, and the integration layer to your back office
- 06MigrationProducts, customers and order history imported, record counts reconciled and old URLs redirected
- 07Trade rehearsalReal card transactions, a refund, a partial shipment and a return processed end-to-end before launch
Two decisions on your side that keep the project moving
The rehearsal step at the end is the one clients remember. Before go live we push real transactions through every payment path, refund one, ship one partially, return one and watch the consequences land in the accounting system and the stock record. It takes a day and it routinely surfaces something that would otherwise have been discovered by a customer.
Choose the right level
Choosing the platform before you fall in love with a design
Platform choice is an operating decision dressed up as a technology one. The useful questions are how unusual your pricing and fulfilment rules are, whether you want a vendor carrying responsibility for uptime and card security, and how much content sits beside the commerce. Answer those and the shortlist usually writes itself.
Route
01
Hosted platform with a custom theme
Fits when
Fairly standard commerce and you want the vendor running infrastructure
What you accept
Platform fees and the boundaries of a checkout you do not control
02
Self-hosted store on WordPress
Fits when
Content and commerce woven together, or pricing rules that misbehave
What you accept
Patching, hosting and performance become your responsibility
03
Headless storefront on a commerce API
Fits when
Editorial heavy commerce, several regions or several channels
What you accept
More moving parts and a front end you must keep maintaining
04
Custom commerce application
Fits when
The model is not really a store, it is a product with a payment step
What you accept
The largest commitment, sensible only when nothing off-the-shelf fits
How we work this out during scoping
We record the decision and the constraint you are accepting in the scope document, because six months later somebody always asks why the checkout cannot do a particular thing. Having the trade off written down turns that into a short conversation rather than an argument. If the shortlist lands on a hosted platform we will usually be talking about a Shopify build, and if it lands on self-hosted we will be talking about WooCommerce. This page is about the decision itself and the plumbing that follows it, which is the same work whichever way the choice goes.
The Australian details that quietly eat your margin
Freight is the first one. A single flat postage rate looks tidy and subsidises every delivery to Darwin out of your profit, while overcharging the Sydney buyer who was the easiest sale you had that week. We set zone and weight based rates against real carrier data, wire tracking back into order status so nobody is copying consignment numbers by hand, and set up click and collect properly where you have a shopfront.
More on the Australian details that quietly eat your margin
Then there is how prices and payments are presented. Australian shoppers expect GST inclusive display, and the ACCC has clear expectations about surcharges reflecting what card acceptance genuinely costs you rather than being a revenue line. Buy now pay later changes both conversion and effective margin, so it deserves a decision rather than a default. Returns are the last piece and the one most often left until after launch, which is a mistake in apparel and homewares where the returns experience drives whether anyone buys twice. Merchants shipping serious volume should also read how we approach logistics projects, because the constraint is usually the warehouse rather than the website.
When you should not build a store yet
If you sell four products and already have a working site, a full commerce build is machinery you do not need. Add a payment link, see whether anyone buys, and spend the difference on demand. If your problem is that nobody visits, a new store will not fix it, and the money belongs in search and advertising until the traffic exists to justify the platform.
Retailers weighing this up will find more on our retail work
There are also businesses whose first online sales genuinely belong on somebody else's platform. If your category has established demand on Amazon, testing there costs a fraction of a store build and tells you something real about price and packaging before you commit. Equally, if your buyers are trade accounts who order the same forty lines every month, a login protected reorder tool is worth more to them than a beautiful catalogue. We would rather scope that than sell you a storefront your customers will never browse. Retailers weighing this up will find more on our retail work.
How we scope it
Four ways to scope your eCommerce Development project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
eCommerce Store launch
A first real store, set up for Australian selling
Fixed written quote, agreed before work starts
- Product data model and catalogue taxonomy
- Storefront built to your design system
- GST, freight zone and payment configuration
eCommerce Store growth
A store with catalogue, integration or margin problems to solve
Fixed written quote, agreed before work starts
- Everything in eCommerce Store launch
- Fulfilment and carrier tracking integration
- Accounting and inventory system connections
- Subscription or recurring order flows where required
Commerce platform
Multi store, multi channel or a custom commerce build
Fixed written quote, agreed before work starts
- Everything in eCommerce Store growth
- Migration of products, customers and order history with redirects
- eCommerce measurement and reporting configured
- Trade rehearsal results and staff operating documentation
eCommerce Store care
Merchandising, speed and conversion, month to month
Rolling monthly, quoted in writing
- Hosting, patching, backups and uptime monitoring
- Merchandising, campaign and catalogue changes
- Checkout and payment paths tested after every update
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
How long before we can take our first real order?
Most builds run 7 to 14 weeks from kickoff to live trading. Configuration and storefront work are predictable. The two variables are product data readiness on your side and integrations to warehouse or accounting systems, which can add several weeks when the requirements are vague. We agree a product content deadline in week one and treat it as a hard milestone.
Which parts of an eCommerce build push the quote up?
Four things explain most of the variation: catalogue size and how messy the existing data is, how many systems must exchange information, whether pricing and freight rules are standard or bespoke, and whether you are migrating order history. We work through each on a scoping call and send a fixed written quote. Platform subscriptions and payment fees are separate and paid by you directly.
If we change agencies later, what actually leaves with us?
All of it. The storefront code sits in a repository under your organisation, the platform and payment accounts are registered to your ABN with your billing details, and your product, customer and order data can be exported whenever you like. We hold collaborator access you can revoke. Nothing about the arrangement depends on us continuing to be involved.
Who runs the store during the first month after go live?
We stay close for the first few weeks because that is when real orders expose the edge cases: an unusual address format, a courier rejecting a parcel dimension, a discount stacking in a way nobody intended. We monitor checkout completion and error logs daily at first, fix what surfaces, and hand over once the numbers settle. After that you can keep a retainer or run it internally.
Can one platform serve both retail customers and wholesale accounts?
Usually yes, and it is often the better answer than two separate sites. Trade accounts sign in to see contracted pricing, minimum quantities and their payment terms, while retail buyers see the public catalogue. It works well until wholesale pricing logic becomes genuinely complicated, at which point we look at whether the rules belong in the store or in the system that already governs them.
Do you handle product photography and product copy?
We define the standards, templates and import tooling, and we will write the templates and category content. Photographing and describing several thousand individual lines is work that needs product knowledge, so it usually stays with your team or a photographer we brief. What we will not do is let placeholder descriptions reach launch, because thin product content is the most common reason a technically sound store underperforms.
Related services
Get a fixed written quote for your store build
Tell us your catalogue size, how you fulfil orders and which systems the store has to talk to. A reply lands within one business day, and the quote that follows is fixed and in writing.