Custom Ecommerce
For the stores a template cannot serve
Most businesses should buy a theme and get on with selling, and we will tell you when that is you. This page is for the ones where it genuinely is not — the ones with a pricing rule, an integration or a catalogue shape that no template anticipates.
The problem, as we usually find it
What is actually going wrong on most of the sites we are called into — before anything about what we would charge.
Most businesses asking for a custom store should buy a good theme and spend the difference on stock or advertising. We will tell you when that is you, and it frequently is.
This page is for the ones where it genuinely is not — where a pricing rule, an integration or the shape of the catalogue means no template can express what the business actually does.
Custom is not better. It is more expensive to build and more expensive to maintain, and it is worth it only when the alternative is asking your team to work around software every day.
What the work covers
Everything below is included. If something is not on this list, we quote it separately rather than leaving you to find out later.
Custom checkout and pricing
Tiered and B2B pricing, minimum order quantities, quote-based carts, and rules a stock theme cannot express.
Integrations that hold
ERP, inventory, accounting or POS, built to survive their API changing rather than to demo well once.
Unusual catalogues
Made-to-order, configurable products, rentals, bundles, and made-to-measure. Anything where a variant dropdown is not the answer.
Bespoke design
Designed for your products rather than adapted from a demo store built to show off someone else's.
Built to be handed over
Documented, in your accounts, and written so the next developer is not forced to start again.
Written technical specification
Integrations, rules and edge cases named before anyone estimates. Estimates before this document are fiction.
Staged delivery
Built in pieces you can see, with the riskiest integration first rather than last.
Error handling and logging
Retries, sensible failure behaviour, and logs a human can read when a sync fails at 11pm.
Documentation and handover
Written so another developer is productive in a day. If they would not be, we have not finished.
What we have actually found
Real numbers from real accounts. We never publish client names, so the businesses are described rather than identified — the figures are exactly as we found them.
Since 2012
building stores in India, which is long enough to have inherited our own work and learned from it
281x
one inherited store's object cache was slower than memory, while its own plugin reported it healthy
8
documented times we took the slower option on a build rather than the one that demos faster
7 days vs 1
a page cache outliving the security token baked into it — an uploader that froze at 99% and read as a network fault
The detail that decides it
The part most quotes leave out, because it takes experience rather than a price list.
When custom is genuinely the right answer
Pricing that is not a number. Tiered rates by customer, contract pricing, quantity breaks, quote-based carts, prices that depend on dimensions or material. Templates assume a product has a price. Some businesses do not work that way.
An integration that has to be right. When stock lives in an ERP or a POS, the store showing yesterday's numbers is not a minor inconvenience — it is overselling and refunds.
A catalogue with an unusual shape. Made to measure, rentals, configurable builds, bundles priced as a unit. Anywhere a variant dropdown stops being the answer.
Integrations, built to survive the other side changing
The demo version of an integration reads an API and displays the result. The production version handles the API being down, returning something unexpected, changing its response shape without notice, or rate-limiting you at month end.
So integrations get built with retries, sensible failure behaviour and logging you can actually read when something goes wrong at 11pm. When a sync fails, someone should know before a customer does.
We do the riskiest integration first rather than last. It is the part most likely to change the estimate, and finding that out in week two is much cheaper than finding it out in week nine.
Written so the next developer is not forced to start again
Custom work has a specific failure mode: it becomes unmaintainable, and the next quote you get is to rebuild it. We have written that quote for other people's work more than once and it is a bad conversation to have.
So the code is documented, the unusual decisions are explained in writing, and nothing depends on a person remembering something.
You should be able to hand this to another developer and have them productive in a day. If you cannot, we have not finished.
Custom code is only as good as the way it is written back
Most of the damage we get called in to undo was not caused by bad logic. It was caused by writing a change back in the wrong form, and nothing errored.
WordPress strips backslashes from content on save. Write a page built with blocks directly and every escaped character inside the block markup is quietly mangled — the page still loads, the layout still looks right, and the attributes underneath are broken. The fix is one function call, and the check is a byte comparison after saving rather than a length check. We byte-compare every content write, because a length check passes on exactly this failure.
Caching does the same thing to forms. A security token issued with a page is baked into the cached copy of it, so if the page is cached for longer than the token lives, every visitor served a stale copy gets rejected. On one store an uploader froze at 99% for months and read as a network problem. It was a seven-day cache against a one-day token — and because such a token is only guaranteed for half its lifetime, the lifetime has to be at least twice the cache duration, not equal to it.
The same discipline goes for theme files: we push them as uploaded files rather than pasting their contents through an interface, because a hand-copied block of encoded text silently corrupted an 18 KB template once. Every write is verified against what the storefront actually renders, not against what the write reported back.
How we scope it before anyone commits
A scoping engagement first, where we work out what actually needs to be custom and what can sit on a standard platform. Frequently the answer is a mostly standard store with two custom pieces, which is dramatically cheaper than custom throughout.
You get a written specification with the integrations, the rules and the edge cases named. Estimates before that document exists are fiction, and we would rather say so than produce one.
If the specification concludes you do not need custom, you have the document and you owe us nothing further.
What we need from you
Short, and worth reading before you start. What delays this work is almost never the work — it is waiting on access or a decision.
Access to the systems we integrate with
ERP, POS, inventory or accounting — including a test environment. This is the item that most often changes the estimate.
API documentation, or someone who knows it
Undocumented internal systems are workable, but we need time with whoever understands them.
Your business rules, written down
How pricing actually works, including the exceptions. The exceptions are where custom projects overrun.
A decision-maker available during the build
Custom work surfaces questions nobody anticipated. Waiting a week for each answer is what makes these projects long.
Realistic examples of the hard cases
The awkward order, the unusual customer, the product that breaks the rule. Those shape the build far more than the normal case.
Whether this is right for you
We would rather lose the enquiry than take work we would do badly, so the right-hand column is as honest as the left.
This is for you if
- Your pricing or ordering rules cannot be expressed by a normal store
- You need a reliable ERP, POS or inventory integration
- Your catalogue is made to order, configurable, or rented rather than sold
- You have outgrown a template and are working around it every day
This is not for you if
- A good theme would do the job; we will tell you if it would
- You want custom because it sounds more professional
- You need it live in three weeks
- You have no one who can make decisions about business rules during the build
How it runs
Four steps, in this order, every time.
- A scoping session first, paid or free depending on depth, where we work out whether you genuinely need custom.
- A written specification with the integrations, the rules and the edge cases named before anyone estimates.
- Build in stages you can see, with the risky integration done first rather than last.
- Launch, then a support window, with the documentation handed over rather than promised.
Looking for hosting? This is what we would put you on
We do not sell hosting and we do not resell it, so there is no plan of ours to push you onto. When a client asks where to host, this is the honest answer for most small Indian sites.
Indian data centre
Mumbai is on the list. A site served from India to Indian visitors starts a long way ahead of one served from Singapore.
LiteSpeed, not plain Apache
It ships with LiteSpeed and LSCache, which is most of the WordPress speed problem solved before anyone installs a plugin.
Free SSL and daily backups
Included on the plans we would actually put a client on, rather than sold back to you at renewal.
Priced for a small business
The long term is where it is cheap. Renewal rates are higher than the first-term price, so buy the longest term you are comfortable with.
That is a referral link. Hostinger pays us a small commission if you sign up through it, at no extra cost to you. We recommend it because we run client sites on it, not because of the commission.
The Stack We
Work In Every Day
Every platform below is one we build on, maintain, rank and report from — not a logo wall.
Questions
That one covers standard stores on WooCommerce or Shopify. This is for builds where the requirement itself is unusual. Most businesses need the first one, and we will say so.
Usually yes, and it is often the wrong call. We would rather lose the bigger project than build you something expensive to maintain that a theme would have handled.
Yes. We have taken the integration half of a build while an in-house team handled the front end.
Want free stats on your site first?
Send us the URL. We pull the numbers from your own accounts and tell you what is wrong before there is any quote, and before there is any contract.
No pitch deck, no obligation. Bring your URL and we will look at it together.