OpenCart store builds, 3.x to 4.x upgrades, migrations on and off the platform, payment and multi-vendor work. Write-ups go up here once the merchant has cleared the figures and we can link a live URL. Until then, here is how to check us.
Most agency portfolio pages are a wall of logos with a percentage stuck to each one. We would rather tell you what is actually here. An OpenCart write-up goes up only after the merchant signs off on the numbers and lets us link the live store, and OpenCart merchants tend to be small operations that do not enjoy seeing their revenue printed next to their logo. This page fills up more slowly than our WordPress portfolio.
That is the honest state of it. Below you will find what our OpenCart projects usually involve, what a published case contains when it goes up, and what you can check today instead of waiting for one.
Our WooCommerce cases are already public with real figures in them, and the engineering is the part that transfers. The Shopify to WooCommerce migration is the closest read if you are weighing a catalogue move.
No OpenCart cases published yet. Check back soon — we ship multiple per month.
Most of what reaches us on OpenCart is repair, not greenfield. A 2.x or 3.x store whose original developer disappeared. A checkout that quietly stopped taking cards after a gateway changed its API. A theme with dozens of core file edits that blocks every upgrade. We spend more hours on version upgrades and migrations than on new builds, which matches where the platform sits: US search interest in OpenCart has roughly halved year over year, and new merchants mostly start somewhere else.
We still take the work. A profitable OpenCart store does not need replacing just because the category is shrinking. But if you ask whether to rebuild on OpenCart or move to WooCommerce, you get a straight answer, and sometimes that answer costs us the bigger project.
The brief and the constraint that drove it. The full stack with version numbers, down to the OpenCart minor release and the PHP version we landed on. Every extension we kept, replaced, or wrote ourselves. A real budget band and real calendar time, with overruns named rather than averaged away. Post-launch numbers pulled from the merchant's own analytics and Search Console. Screenshots from the live store. Then a section on what we would do differently, which is usually the part worth reading.
When we cannot get those things, the case does not go up. We do not fill the gap with a mockup.
Read a case from another platform. The Shopify to WooCommerce migration covers 1,840 SKUs and the redirect work behind a catalogue move. Same problem on OpenCart, different function names.
Ask for a reference call. We set up 30 minute calls with past clients before a contract is signed, including OpenCart merchants who will happily talk but not be named on a web page. Ask and we will ask them.
Buy something small first. A paid audit of your current store gets you written findings and a prioritised fix list for a fraction of a migration budget, and it shows you how we think. Several of our longest clients started exactly there.
If you know what you need, OpenCart services lists scope and pricing per service, and the packaged solutions are fixed-price versions of the jobs we run most often. If you are not sure, take the free 30 minute scoping call and we will tell you which one applies, or that neither does.
Because we publish a case only when the client has approved the figures and we can link the live store. Our OpenCart clients are mostly small merchants, and a fair number of them decline to be named. We would rather leave this page thin than fill it with anonymised claims nobody can verify. The projects exist; the write-ups appear as permissions come through.
Usually yes, on a call. We can walk you through a store's admin, the module code we wrote, the before and after page-speed reports, and the migration mapping sheets, without publishing any of it. What we cannot do is send you a deck of screenshots to forward around, because that is the thing clients ask us not to do.
Yes. We arrange 30 minute reference calls before a contract is signed, and we try to match you with a project close to yours in size and scope. We ask the client first and we never hand out a contact without their say-so. Most agree.
No, and inherited stores are the majority of our OpenCart work. Someone else built it, the relationship ended, and the store now needs an upgrade path or a rescue. We start with a paid audit so we can price the real work rather than guessing at what is under the theme.
If your store makes money, your extensions still get updates, and you are on a supported OpenCart 4.x with a current PHP release, staying is usually cheaper than moving. Move when the extensions you depend on stop being maintained, when your theme blocks upgrades, or when you need something the ecosystem no longer supplies. We will tell you which of those applies to you before quoting a migration.
A 3.x to 4.x upgrade on a store with a clean theme and mainstream extensions is typically two to four weeks. A migration to WooCommerce or Magento depends almost entirely on catalogue size and how much custom checkout logic is in the way. We quote a fixed scope after the audit rather than an hourly estimate up front.
30 minutes with a senior engineer. No salespeople. We respond within one business day with a brief outline.
Send a project brief →
