When the CMS or the shop becomes the bottleneck, not the tool.
Laravel CMS and e-commerce platforms for companies whose content or catalogue no longer fits the product they started on — and an honest answer when an off-the-shelf platform would serve you better.
Where the tool starts to cost you
The platform still works. Everything around it has become manual.
If two or more of these describe your setup, the constraint is the data model, not the team.
- The content model does not match the business
- What you sell is not a page, but the CMS only knows pages. The real structure lives in a naming convention, a spreadsheet, or someone's head.
- Plugins hold the critical path
- Pricing, stock or checkout logic spread across extensions nobody can upgrade independently. Upgrades get postponed; risk accumulates.
- Routine changes need a developer
- A campaign, a rule change, an attribute fix: each becomes a ticket with a queue in front of it.
- Systems are reconciled by hand
- Orders, stock and customers copied between shop, ERP and warehouse. Somebody exports, somebody imports, somebody checks.
01
02
03
04
What we build
Five things a platform has to get right to stay usable.
- A CMS modelled on your domain
- Built from the objects you actually manage, with their relationships, states and validation rules — not a theme bent to approximate them.
- E-commerce: products, orders, coupons, content
- Variants, bundles and configurable products without a workaround. Order lifecycles with the states operations recognises. Coupons, promotions and contract pricing as rules, not plugins. Content and products in one panel.
- An admin panel built for the people in it all day
- Roles that mirror the real org, bulk editing and filtered views, drafts, previews and scheduled publishing, validation in business terms, an audit trail. If a routine task needs a developer, the panel is unfinished.
- Performance and technical SEO as build constraints
- Server-rendered pages, caching sized for your real data volumes, and canonical and pagination handling that survives faceted navigation. On a replatform, redirects are mapped before launch, not after.
- Evolutionary maintenance instead of a handover
- Tests on the paths that must not break, monitoring from day one, and upgrades planned instead of deferred until they become migrations.
What we have built
We run the platform we would build for you.
Not a portfolio of logos. Much of our work for regulated organisations cannot be named, because of the confidentiality we agreed to: here are the three things that exist, each stating how much of it you can check yourself.
- Automobili Zupi, a dealership back office
- Online at automobilizupi.it: a bilingual platform, Italian and English. The public part is the vehicle catalogue with search, the used-car valuation requests and the financing enquiries; the part that matters is the back office used every day for clients, contracts generated from templates, payments, roles, permissions and listing export to the marketplaces.
- A custom CMS, in active development
- We build and maintain our own CMS rather than assembling one from plugins each time, which is why a domain-specific content model is a starting point here instead of a research project. It is internal software, so there is nothing for you to visit — ask us for a walkthrough of the admin instead.
- An e-commerce store
- A retail catalogue and checkout built and run on the same stack: products, orders and content managed from one panel by a small team with no developer on staff.
Live, and public
Our own
Retail
Bring the constraint, not the wishlist.
Send the part of your setup that breaks or blocks the team. You get a technical read on it — including if the answer is you do not need us.
Qualifying honestly
When you do not need a custom platform.
Custom is not an upgrade over Shopify, WooCommerce or WordPress. It is a trade: you own the code, in exchange for fitting a model a packaged product would have to work around. It only pays when the model is genuinely yours.
A packaged platform is the right call when…
- The catalogue is standard: products, variants, prices, stock, one checkout.
- Shipping, tax and payment are covered by the ecosystem already.
- Speed to market matters more than fit, and workarounds are tolerable.
- No in-house technical owner, no budget line for ongoing engineering.
- The differentiator is brand, assortment or marketing — not the mechanics.
A custom platform starts to pay when…
- Every release adds another workaround to fit the packaged product's model.
- Pricing or ordering logic is the differentiator: contracts, quotes, approvals, rentals, subscriptions.
- ERP, PIM, logistics or legacy integration carries the real complexity.
- Operations depend on the admin panel, and the generic one is the bottleneck.
- Compliance, data residency or auditability need control of the whole stack.
- The extension stack is the risk: too many moving parts to upgrade safely.
| What you are deciding | Packaged platform | Custom platform |
|---|---|---|
| Fit to your model | You adapt the process to the product, absorbing the gap with conventions and extensions. | The product is built around the process: the gap is a design decision, not a workaround. |
| Cost profile | Lower to start, spread across licences, apps and the manual work the gaps create. | Higher to start, concentrated in the build and in engineering afterwards. |
| Who you depend on | The vendor and the extension authors, on their roadmap. | Any team that can read the code. You hold the repository. |
| Changing the rules | Fast inside what the product supports, fragile outside it. | Bounded by engineering capacity, not by what the product allows. |
| Sensible next step | Keep it; spend the budget on assortment, content and acquisition. | Scope the domain model first, then build what carries the business logic. |
How the engagement runs
Modelling before code, production before handover.
Assessment
Platform, data, integrations, and who does what in the admin every day. Output: a written read on what to keep and whether custom is warranted.
Domain model
Entities, relationships, states and rules agreed with their owners before any interface is designed. This step decides whether the admin panel feels obvious or arbitrary two years from now.
Incremental build
Slices that reach a real environment, with tests on the paths that must not break. The old system stays in production until the new one has earned the traffic.
Migration and launch
Content, catalogue and order history migrated with reconciliation checks, redirects in place before the switch, rollback path ready.
Evolution
Monitoring, planned upgrades, a working backlog. The docs are written so that the team who built it does not have to be the team that runs it.
Technical FAQ
The questions that decide the project.
Why build a custom CMS instead of adapting an existing one?
Only when the content model is the product. A generic CMS gives you pages, posts and a field builder — if that is what you need, use it. Custom is cheaper when your editors work with objects that are not pages (a course with sessions and seats, a property with availability windows, a product configured from compatible parts) and every packaged answer is a plugin plus a workaround.
When is Shopify or WooCommerce the better answer?
Often, and we say so in the first call: for a standard catalogue with standard checkout, shipping and tax, rebuilding that is money spent on a solved problem. Custom makes sense when the business logic is the differentiator — contract pricing, stock split across warehouses and channels, quote-to-order flows, subscription or rental mechanics, or an ERP and logistics layer that carries the real complexity.
Can you take over a platform someone else built?
Yes, starting with an assessment rather than a rewrite proposal: we read the codebase, the data model, the deployment path and the test coverage, then report what is safe to keep and what is a liability. Plenty of inherited systems only need dependency upgrades, tests on the critical paths and someone who answers the phone. Any rewrite happens incrementally, with the current system in production.
How do you handle SEO on a replatform?
As a data-migration problem, not a checklist at the end. Before launch we inventory every indexable URL, map it to its counterpart with a permanent redirect, and keep the patterns that already rank. Plus server-rendered pages, structured data, canonical and pagination handling, sitemaps from the real catalogue, and Core Web Vitals measured on your templates and data volumes.
What happens after launch?
The engagement is built around continuous change, not a handover date: monitoring and error tracking from day one, planned upgrades, and new features through the same review and test process as the original build. You get the repository, the infrastructure definitions and the documentation regardless.
Why Laravel?
A mature PHP framework with a large hiring pool, a predictable upgrade path and first-class answers for the boring but critical parts: queues, scheduled jobs, authorisation, validation, migrations, testing. It also means that if you replace us, you hire for a common skill set.
Get in touch
Discuss your platform with the people who would build it.
One reply from an engineer, not a form autoresponder. If it isn't a fit, we'll say so on the first call.
- Locations
- Italy · Czechia · Japan