Most agency process pages describe a tidy sequence that no project follows. This is the actual shape of an ecommerce build as we run it, including where projects slip and what we need from a client to keep them moving.
We are writing it down because the most common cause of a difficult project is not technical. It is that nobody agreed early enough on who was responsible for what.
Phase one: discovery and architecture
Short, and the phase that prevents the expensive reversals later. We establish the catalogue structure, the customer journey, the payment and shipping model, and any systems the store has to talk to.
The questions that matter most here are rarely about design. How many products, and how do they vary? Who fulfils orders, and from where? Does the store need to be bilingual, and if so, from launch or later? Is there an existing system holding stock or customers that must stay in step?
Bilingual is worth deciding now rather than later. Arabic reads right to left, which changes layout, navigation and iconography rather than sitting on top of them. Retrofitting is consistently more expensive than building for it.
Phase two: design
Storefront, category page, product page, cart and checkout. We design the product page and the checkout with the most care, because that is where the money is made, and they are routinely the pages that receive the least attention.
Feedback works best consolidated. One considered round beats a fortnight of individual messages, not because we mind the messages but because contradictory instructions from three people is the most reliable way to extend a timeline. We ask for a single set of comments per round, with a named decision maker.
Phase three: build and content
Development runs in parallel with catalogue loading, photography and copy. This is where projects slip, and it is almost always content rather than code.
What we need from you: product names, descriptions, prices, variants and weights for shipping; consistent photography; your shipping, returns, privacy and terms policies; and access to the domain and any existing analytics. Having these ready before the build starts is the single largest lever you control over the timeline.
Weights are the item most often forgotten and they matter, because shipping rates cannot be calculated without them.
Phase four: payments and integrations
Gateway integration is not a plugin install even when a plugin exists. Three parts have to work: the checkout the customer sees, the webhook that tells your store a payment succeeded, and the reconciliation between the gateway, the bank and your order records.
The webhook is the part most often implemented badly. If a store only marks an order paid when the customer returns to the success page, every customer who closes the tab after paying leaves you with a paid transaction and an unpaid order. We test that path deliberately. Our comparison of payment gateways in the UAE covers the selection side of this.
Phase five: testing and launch
Testing on real devices rather than on a desktop browser resized to look like a phone. Live test transactions through the real gateway, including a refund, because refunds are where integrations quietly fail. Analytics verified as actually recording. Then a monitored launch rather than a switch flipped on a Friday evening.
If the store replaces an existing site, we map every old URL to its new equivalent and put permanent redirects in place before launch. Skipping that step is the most common way a new store loses the search visibility the old one had earned.
After launch is where the money is made
A launched store is a starting line. What determines whether it earns is what follows: fixing the points where the funnel leaks, improving product pages that get traffic and no sales, recovering abandoned carts, and building the organic visibility that reduces dependence on paid traffic.
Budget for it. A common and painful pattern is spending the entire budget on the build and having nothing left to bring anyone to it. The structural side of that work is covered in our guide to ecommerce SEO.
Frequently asked questions
Who owns the store and the accounts?
You do. The domain, the hosting, the platform subscription and the payment gateway account should all be in your company's name, with us holding access rather than ownership. We set it up that way by default.
What happens if we want to change something mid build?
Small adjustments are normal and absorbed. Changes that alter agreed scope are quoted before they are done, so the decision is yours and visible rather than arriving later as a surprise on an invoice.
How long does the whole thing take?
Typically several weeks to a few months, driven mostly by catalogue size, integrations and how ready the content is. We would rather give you a realistic date than an optimistic one.
If you are planning a build
The projects that go well are the ones where the content is ready, one person can make decisions, and the scope was honest at the start. None of that requires a bigger budget. It requires agreeing the boring things early.
We handle this work as website development. If you want a view on scope or timeline before committing, tell us what you are trying to sell.
