Magento and Adobe Commerce engineering
Magento is the platform you choose when the catalogue, the pricing rules and the accounts your business buyers need are the actual product. You pay for that in upkeep: hosting, indexing, caching and a real upgrade habit. If you cannot name the requirement that needs it, we build on a lighter platform instead.
01Capabilities
Four kinds of complexity that put a business on Magento
Magento is worth its weight in a narrow band of e-commerce problems: complicated products, complicated buyers, or both. These four are the ones we would keep you on it for, and each of them is a modelling problem before it is a storefront one.
- Buyers
Company accounts, contract prices and approvals
Buyer hierarchies, a price list per customer, quotes, credit terms and ordering on somebody else's behalf. No lighter platform models this honestly, and it is the single best reason to be here. The rules usually reach in from elsewhere, which makes it platforms development and integration work as much as storefront work.
- Catalogue
An attribute model that survives the next import
Attribute sets, configurable and bundled products, multi-source inventory, and indexing that still behaves after a large import. The attribute model is the design work, because it decides whether the next catalogue change takes an afternoon or a quarter.
- Stores
One product set behind several brands and countries
Magento splits a business into websites, stores and store views, and that hierarchy is where a second brand or a new market becomes configuration rather than a project. Getting it wrong is expensive later, because the shape is baked into every price, every attribute and every URL.
- Inherited
An estate more than one team has extended
Unsupported versions, a third-party module list nobody has audited, core files patched by someone who has since left. Getting that back onto a supported footing is legacy modernization work more than it is commerce work, and it is the shape most people arrive with.
02Fit
Is the complexity real, and is it yours to carry?
Magento is the heaviest of the three commerce platforms we work on, and the weight is the point rather than a flaw. You pay it in hosting, indexing, cron, cache and upgrade discipline, and you get a data model that bends to a complicated business. Each row is the call we would make, and three of them link to the unicrew page for the platform or service that fits.
| Your situation | What we recommend |
|---|---|
| A deep catalogue, a contract price list per customer, layered buyer accounts | Use MagentoThis is what the data model exists for. Working around its absence on a lighter platform costs more, every month, than operating Magento does. |
| A modest catalogue, a standard checkout, and nobody whose job is running servers | Different pageOur Shopify page. Otherwise you pay for modelling freedom you will never exercise, and you pay for it forever. |
| WordPress already holds the content and the catalogue is small | Different pageOur WooCommerce page. Two content systems is a worse problem than a less capable commerce model at that size. |
| Nobody on your side owns hosting, indexing, cron and upgrades | Staff operations firstBuy that capacity before you buy the platform. Magento punishes an estate nobody runs, and it arrives as a slow site rather than an outage you can point at. |
| Still on Magento 1, or a release that no longer receives security fixes | Security firstTreat it as a security position before a commerce project. Get the version and the payment path safe, then reopen the design conversation. |
| The bottleneck is the quality of your product data, not the storefront | Fix the dataStart with the product data pipeline, see data engineering. A new storefront presents the same bad data faster. |
Scope
What we own here is the architecture decision and what it costs to run. Which customisations become modules. Which stay out of Magento entirely. Whether the estate can be upgraded on a schedule rather than in an emergency. unicrew has been building commerce systems since 2012, with 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system. Where a lighter platform fits better, that is the one we build on.
Magento is at its best on complex catalogues, with many stores, many price rules and many markets. For a simpler store, we build on Shopify or WooCommerce instead. We settle that choice with you before anything is signed.
Yaroslav HavrylivSenior Engineering Manager, unicrew03Delivery
Getting an upgrade back onto a schedule
Almost every estate we are shown has been extended by more than one team. This order is what stops the first month producing confident wrong answers.
- Audit the modules and the core patchesThird-party modules, their maintenance status upstream, and any core files edited directly. This is where upgrade cost hides, and it is the difference between a planned upgrade and a rewrite wearing an upgrade's name.
- Measure the slowness before changing anythingIndexer state, cache hit rates, slow queries and real page timings for logged-in sessions. Slow Magento is usually three specific things rather than a general condition, and guessing which three is expensive.
- Get configuration and deployment honestConfiguration in version control, deploy mode set correctly, and a staging environment close enough to production to be worth testing on. Half of what gets blamed on Magento is a deployment process nobody trusts.
- Sequence the upgrade against your trading calendarPlanned around your peak periods, with a rehearsed rollback and module replacements identified in advance. Every step is checked through the same QA and test automation practice we use on our own builds, and we do not run an upgrade into a peak season to hit a date.
04Stack
What a Magento estate is built from
Two lighter platforms this decision is usually made against, and the two parts underneath it. Each has its own page if that is the call you are really making.
05Questions
Questions that decide whether Magento is the right home
The six we get asked most, answered the way an engineer would answer them. If yours is not here, ask it on the call.
Yes, and on a live estate it is often the sensible shape, because your people hold the trading context. Our engineers keep the upgrade position owned, so the estate stays upgradable on a schedule: an architect outside the delivery team reviews module and integration design, and the work goes through the same QA practice as our own. Team extension is managed teams; an outcome is web development.
Name the requirement Shopify blocks. If you can, and it is about catalogue structure, contract pricing or buyer hierarchies, Magento is right and its upkeep is the fair price. If you cannot, Shopify costs less over five years and removes a whole category of infrastructure work. The common mistake is buying flexibility nobody ever exercises.
Three, and all of them are real. Move to Magento 2, which is a rebuild of the front end and a re-implementation of every extension rather than an upgrade. Move to a lighter platform, which is often the right call. Or stay, and accept an unsupported platform handling payments, which is a decision to take deliberately rather than by default. We scope all three before putting effort on any of them.
Usually a short list: an indexer that is not keeping up, full-page cache bypassed for logged-in customers, a module doing database work on every request, or a category query with no realistic index behind it. Hosting gets blamed first and is the cause least often. We measure before recommending, because the fix differs in each case and three of the four are cheap.
A scoping call with an engineer. For an existing estate we ask for the module list, the version and read access to the repository, because those three tell us more in an hour than a workshop does in a day. What comes back is written: the upgrade or build path, what we would do first, and what we would keep as it is. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, offered once the first read is done, because a fixed number on an estate nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Building on Magento, or trying to get an old estate current?
Tell us what the catalogue and the pricing rules look like, and which version you run. You get an engineer's read on the right home for it, Magento or a lighter platform.