Retail & Ecommerce
Most retail problems that look like software problems are disagreement problems: the site, the warehouse and the finance system each believe something different. We make one of them right and have the others read from it.
What this covers
Storefront build
Fast, accessible pages with the merchandising controls the team needs.
Stock accuracy
One inventory position, updated where stock actually moves.
Order orchestration
Where an order is fulfilled from, decided by rules rather than by habit.
Returns
The reverse journey treated as a first-class one, because it decides repeat purchase.
Pricing and promotions
Changes applied everywhere at once, with an audit of what ran when.
Marketplace integration
Listings, orders and stock synchronised with the channels you sell on.
Who this is for
Multi-channel retailers
Where stores, site and marketplaces compete for the same stock.
Direct-to-consumer brands
Growth outpacing the systems that got you here.
Wholesale and B2B
Account pricing, credit and reordering rather than a checkout.
Grocery and fresh
Short shelf life, substitutions and slots that make accuracy unforgiving.
How we work
People who have done it before
Teams that have worked in this setting, not a generic squad reading the brief for the first time.
One team, start to finish
The people who design it are the people who build it and the people who answer for it afterwards.
Working software early
Something running in weeks, so the direction is judged against a real thing rather than a document.
Sector experience, not sector slides
What we bring to the first meeting
We have worked in this sector, so the first conversation is about your constraints rather than an introduction to the domain. Where we have not done something before, we say so.
Talk to us
What we promise
- A named team you can reach, not an account manager relaying questions
- A working version early, and every fortnight after that
- Written estimates with the assumptions and the risks stated
- Your code, your data and your accounts, yours throughout
- A direct answer when something is late or will not work
How it runs
Understand
Two weeks with the people doing the work, mapping what actually happens rather than what the process document says.
Prove
One narrow slice built and put in front of real users, to test the approach before it is expensive to change.
Build
Delivery in fortnightly increments, each one usable, each one reviewed with you.
Run
Support, monitoring and improvement — or a handover to your team, documented.
Common questions
Usually not. Replatforming is expensive and rarely the actual constraint — stock accuracy and order routing more often are.
Yes, and it is normally the right record of truth for stock and price.
Peak is a capacity and a rollback question. We plan both, and we do not ship changes into it.
As a budget agreed up front and measured in the build, not as a tuning exercise afterwards.
Is this the right fit?
Tell us what you are trying to do. If we are not the right people for it, we will say so.
Get in touch