Experience · Ecommerce

Ecommerce development: a simple buying experience and an operation that keeps up.

New online store
Redesign
Migration
Custom ecommerce
B2B

What the customer goes throughThe customer

Finds the product

Catalogue, filters and search

Chooses a variant

Real stock for that combination

Adds to basket

Price, delivery and tax

Pays

Payment authorised and checked

Order confirmed

Order created

The checkout ends here. The experience doesn’t.

Tracks the order

Fulfilment and updates

Receives it

Shipping and delivery

Can send it back

Return, refund and stock

What your business resolves at that same momentYour business

Checkout ends on a screen. The customer experience and the operation carry on all the way through.

Selling online doesn’t end when someone clicks «Buy»: that is where payment, the order, stock, fulfilment and delivery begin. We design and build online stores where those two halves —the one your customer sees and the one your business carries— move at the same time.

Tell us what you sell How we work

The starting point

Checkout doesn’t fix what happens before it. Or what happens after.

When a store isn’t selling what it should, almost everyone looks at the last step. But a sale runs through two whole worlds, and the checkout is the thin line between them: it holds up neither.

one sale

Before paying

They can’t find itThe catalogue is organised like the warehouse rather than the way people search for things, and the search box forgives nothing.
They can’t see the differenceTwo similar references, two product pages that don’t compare the same things, and no visible reason to pick one.
They don’t know if it’s in stockStock by size, colour or measurement isn’t visible until the basket, and sometimes not even there.
They don’t know the totalThe delivery cost turns up when they are already paying. It is the classic moment of abandonment, and it is avoidable.
They don’t know when it arrivesA generic «24 to 72 hours» wins fewer purchases than a specific date.
They don’t trust itNot the site, not the payment, and not that sending it back will be easy if it doesn’t suit them.

And there is one case where none of this is the problem: nobody reaching the store at all. That isn’t fixed by redesigning the checkout, it is fixed with SEO, Google Ads or Meta Ads. Before touching the store it is worth knowing which of the two sides the brake is on.

checkout

One minute of the whole sale.

After paying

The order is retyped by handIt lands in the store and someone types it out again into the ERP, a spreadsheet or the invoicing software.
Stock runs lateIt doesn’t come down on confirmation but overnight, and meanwhile you sell what is no longer there.
Fulfilment depends on one personOn someone checking the inbox, printing, finding it in the warehouse and deciding the order of work.
The customer asks where it isEvery order without automatic tracking is a call, an email or a message that someone has to answer.
A return undoes it all by handRefunding the payment, putting the stock back, redoing the invoice and telling the customer. Four different places.

The checkout is one minute of the sale. Everything else decides whether that minute happens at all, and whether it is worth anything when it does.

Before buying

Buying isn’t one click. It’s seven decisions in a row.

Between arriving and paying there is a run of small decisions, and a doubt hangs off every one of them. An unanswered doubt doesn’t make people complain: it makes them leave, and it leaves no trace. Design work isn’t about removing the doubts, it is about answering them before they slow anyone down.

What they ask themselves

What has to be sorted already

Arrives

Is this what I’m looking for?
Categories and filters written in the customer’s words, not the internal catalogue’s. A search box that copes with typos, synonyms and trade names.
How is it different from that one?
Product pages that compare where comparing matters: the same attributes, in the same order, in the same units. The difference is visible without opening two tabs.
Is there one in my size, my measurement, my colour?
Variants with real stock per combination. What isn’t there is said before it is chosen, not after it is in the basket.
What will it cost me in total?
Delivery, tax and discounts worked out on the product page and in the basket. No new figure turns up at the last step.
When does it arrive?
An estimated delivery date, which comes from the stock, from the carrier and from the time of day the order is placed. Not one generic lead time for the whole catalogue.
What if it doesn’t suit me?
Returns and exchanges explained before paying and on the product page itself: the window, the conditions and who pays to send it back.
Do I trust paying here?
Methods people recognise —card, PayPal, digital wallets, bank transfer—, the option to buy without creating an account, and a final summary that hides nothing.

Buys

None of the seven is resolved at the checkout. They are resolved long before it, which is why a good checkout feels easy: by the time you reach it there is nothing left to decide.

One order

At the top it says «order confirmed». Underneath, five things at once.

It is the same purchase. For the person making it, it is one sentence. For your business it is a payment to secure, stock to take down, a parcel to pick, a delivery to follow and a customer to tell about all of it. If one of the five is left half done, the problem comes back as a phone call.

All the customer ever sees

Order confirmed

Payment

The payment is authorised and taken
If it is declined, you know why
The invoice goes out on its own, with its tax

Inventory

Stock comes down on confirmation, not overnight
What is sold is reserved and not sold twice
If a line runs out, it stops being offered

Fulfilment

The order joins the work queue
It groups by warehouse, by family or by route
Whoever picks it sees exactly what was bought

Delivery

Label and carrier by destination and weight
Tracking the customer never has to ask for
And if something comes back, it comes back with its reason

Communication

Confirmation, dispatch and delivery, without anyone writing an email
The customer sees the order and the history in their account
What was promised before paying is what gets delivered

Order delivered

And when something comes back

Several of those five have to be corrected in the opposite direction —refund the payment, put the stock back, collect the parcel, redo the invoice, tell the customer— and not always all of them, nor always in the same order. A store is well built when it can undo a sale as well as it can make one.

None of the five is visible from the shop front. All five are noticed when they fail, and always in the same place: on your team’s phone.

What we build

The anatomy of a store that sells and can be run.

It isn’t a catalogue of services: it is what has to be resolved for a purchase to cross the whole store. It is done in full on a new project and in parts on a store that already exists.

What helps people choose

catalogue, navigation and product pages so that finding and comparing costs nothing

Catalogue and category architecture
Filters and on-site search
Product pages built for deciding
Variants, combinations and bundles
Category and product content for ecommerce SEO
Reviews and trust signals
Responsive online store design, from home page to checkout
Redesign of stores that already sell but don’t convert

What lets people buy

basket, checkout, payments and the commercial rules of your business

Basket and checkout with no extra steps
Guest checkout and customer accounts
Payment gateways and payment methods
Delivery methods, zones and costs
Tax, VAT and invoicing
Promotions, vouchers and volume discounts
Prices, catalogues and terms per customer (B2B)
Minimum orders, batches and selling rules of your own

What keeps the order moving

statuses, stock and operations from the moment it is paid to the moment it lands

Order statuses and internal workflow
Stock, reservations and stockouts
Delivery notes, picking and packing
Carrier integration and tracking
Returns, exchanges and refunds
Automatic customer updates at every status
An admin panel built for the people who work in it
Automation for orders, customers and after-sales

What connects the store to the business

integrations, data and growth for the digital channel

ERP and CRM integration
Invoicing and accounting (Holded and similar)
Catalogue, price and stock synchronisation
Product feeds and Google Merchant Center
Ecommerce migration without losing rankings
Technical SEO, performance and load speed
Ecommerce analytics and measuring the purchase

And when what the business needs stops being a store and becomes a system —a configurator, a customer portal, B2B ordering with rules of its own—, the project leans on Custom web development and Custom software. Never the other way round: we don’t build from scratch what the platform already does well.

What it is built on

The platform is a decision inside the project, not the project.

We don’t defend a platform out of habit. The decision comes from looking at five things of yours —catalogue, operations, checkout, selling rules and integrations— and three possible answers come out of it. What separates them is written between them.

Standard store

When the business fits inside what the platform already does.

An ordinary catalogue, the same prices for everyone, delivery by zone, the usual payment methods. It is configured well, designed well, and the engine is left alone. It is the cheapest to maintain, the least likely to break and the one that survives updates best.

This is as far as out of the box goes. The line is crossed when one rule of yours doesn’t fit.

Extension

When nearly everything fits but there are rules of your own.

The base is still the platform and what it lacks is added to it: a delivery calculation of your own, a price list per customer, the connection to the ERP, a checkout step that works differently in your business. You gain behaviour without giving up the ecosystem.

The second line is crossed when what rules is no longer the platform, it is the way you sell.

Custom ecommerce

When the selling model calls for behaviour the platform forces.

Product configurators, batch ordering, negotiated prices, catalogues per customer, stock split between shop and warehouse, subscriptions with rules of their own. At this point building is worth more than arguing every month with a platform that says no.

What we work with, and when each one fits

WooCommerceThe store lives inside a content site and you want full control of the hosting, the code and the data.
PrestaShopLarge catalogues, many references and combinations, and fine commercial control of prices and promotions.
MagentoLarge structures, several stores or several markets running on one base.
Custom buildWhen none of the above can run your rules without fighting them every month.

The useful question isn’t «which is the best platform?». It is «how much of the way I sell do I have to change to fit inside it?». When the answer is «not much», the platform wins. When it is «quite a lot», building starts to make sense.

How we work

The same journey, four times, each one more real.

We don’t start with the design. We start by understanding what you sell and how what you sell is handled today. From there, the whole journey —from someone arriving to someone receiving the order— is walked four times, and each pass looks more like reality.

Arrives
Decides
Pays
Receives

What you sell
on paper
Catalogue, variants, prices, selling rules, tax, delivery, returns, and what happens in your business today from an order arriving to it going out of the door. This is where the written scope and the platform decision come from, not an estimate with a range in it.
How they decide
on the design
Navigation, category, product page, basket and checkout, decided before they are built: what is understood first, where each of the seven doubts gets answered and what is taken out of the way. Moving a decision here is cheaper than moving it in a finished store.
How they buy
on the store itself
Catalogue loaded, payments in test mode, delivery calculating, emails going out, an admin panel that works. You can buy here, and we do: we test it and your team tests it, because they are the ones who will live inside that panel.
What happens next
with real money
Before going live we make a real purchase from end to end: it is paid for, the order lands, stock comes down, it is picked, it ships, the emails arrive. And then it is sent back, to check that the store undoes a sale as well as it makes one.

And once it is live

We look at what people do —where they drop out, what they search for and don’t find, what doesn’t sell— and at what every order costs your team. The first is conversion work; the second is operations. There is almost always more money in the second, and it is almost never looked at.

Fit

When this project makes sense.

You already sell online and the store has become too small for you.
You sell well, but every order costs manual work.
You are opening an online channel and don’t want to rebuild it in a year.
The way you sell doesn’t fit a template.

Models we work with

Brands selling direct
Distributors with large catalogues
Manufacturers
B2B and prices per customer
Shop and online at the same time
Subscription and repeat ordering

We aren’t the option if what you want is the cheapest possible store to test whether this works: there are thirty-pounds-a-month solutions that do that job well, and they are the right decision until they stop being it. We aren’t the option either if the aim is to go live in three weeks without looking at operations: it can be done, but the manual work you don’t resolve now gets paid for every day afterwards.

Frequently asked questions

Before commissioning an online store.

How much does developing an online store cost?

There is no single rate because there is no single project, but what moves the price can be named: how many references and how many variants the catalogue has, whether prices are the same for everyone or depend on the customer, how many integrations there are —ERP, invoicing, stock, carriers—, whether the store is resolved on a standard platform or calls for custom development, and whether an earlier store has to be migrated. We would rather look at the starting point and give a fixed quote with the scope in writing before we start, instead of a range that means nothing.

How long does an ecommerce development project take?

A store with a hundred references and standard payments doesn’t take as long as an ecommerce with a large catalogue, prices per customer and an ERP integration. What we usually do recommend is doing it in phases: publish the part that already sells first and leave the next ones ready, rather than delaying the launch by a quarter for features nobody is waiting for yet. The timeline is closed with the scope, and the scope is closed in the first phase of the project.

Which platform suits us: WooCommerce, PrestaShop, Magento or custom?

It depends on the catalogue, on operations and on how many rules of its own your way of selling has. WooCommerce fits when the store lives alongside a content site and you want full control; PrestaShop, on large catalogues with many combinations and fine control of prices; Magento, on large structures or several stores and markets. Custom development comes in when none of them can run your rules without fighting them. There is no platform that is better than the rest: there is one that fits this project better.

Can you redesign or migrate an existing store without losing rankings?

Yes, and in many cases it is the sensible thing to do: if the store already sells, starting from scratch throws away content and authority that took years. A migration done properly keeps the URLs that rank, redirects the ones that change one by one, keeps the category and product content, respects the internal linking structure and controls the indexing of filters and variants, which is where it almost always gets out of hand. Some movement in the first few weeks is normal; losing traffic permanently is not, and that is avoided with the work beforehand, not with a correction afterwards.

Can the store be connected to the ERP, the CRM, invoicing, stock and logistics?

Yes, and it tends to be the part that pays for the project. An order that comes in once and travels on its own to the invoice and to the carrier label saves work every single day, and it removes the most common source of error: copying data by hand. Catalogue, prices and stock can be synchronised in both directions, the invoice can be created when payment is taken, the order can be sent on to the picking system and the tracking returned to the customer. What gets integrated, and which way each piece of data travels, is decided in the first phase, because it conditions the platform.

Who runs the store afterwards, and what maintenance does it need?

Your team runs it. Part of the work is making the admin panel look like the way you actually work —adding products, prices, promotions, orders— so that nobody has to call us for the day to day. Beyond that, an ecommerce needs real maintenance: platform and module updates, backups, performance reviews, keeping an eye on payments and integrations, and improvements based on what shows up in the data. We put it in writing before we start, with what is included and what isn’t.

Do you guarantee the store will sell more?

No, and it is worth being wary of anyone who guarantees it: sales are shaped by the product, the price, the stock, the competition and how many people reach the store, and a website has very little say over any of that. What can be sustained is that the store stops getting in the way —that the product gets found, that the difference is understood, that the total cost is known before the last step and that buying doesn’t take patience— and that the operation stops costing hours per order. If with all that resolved the problem is still somewhere else, we will say so.