How we work
Building is the easy part. What sets an integration of ours apart is what happens afterwards: tested on every release, kept compatible and shipped predictably. For years.
Why we do this for every integration
Every Magento release, every new Hyvä version and every PHP upgrade is a moment where a plugin can break. When it does, the merchant notices first, and they call your support desk, not the developer. An unstable plugin costs you support time, Marketplace reviews and eventually merchants.
That's why testing and maintenance isn't a separate service for us but part of every integration we build. You don't buy a plugin, you buy a plugin that keeps working. Three things make that work.
How we work together
Not a big project with a delivery date, but an ongoing collaboration. This is what it looks like in practice.
1. A thorough review first, then a scope
Existing plugin? We read all of it before touching anything: architecture, Magento and Hyvä conventions, security, test coverage, compatibility with the versions your merchants run. That produces a list of action points, ordered by risk. From day one you know where your plugin stands.
New plugin? We analyse your API and your requirements and write a scope of work: exactly what gets built, which Magento and PHP versions are supported, a fixed price, delivery time and acceptance criteria. No surprises afterwards, on either side.
2. In your repository, through pull requests
Usually we get access to your repository and work in it. Every change is a pull request, with tests and a description your own developers can review. The code is and stays yours, the history stays readable, and you can see what is happening at any time. If you have no repository or no developers of your own, we host it and work through the same pull request flow.
3. Ongoing, with a fixed number of hours
A plugin is never finished. Magento changes, your API changes, merchants ask for new features. That is why, after delivery, we work with a fixed number of hours per week or per month, with no minimum: whatever fits the size of your plugin. Within those hours we fix bugs, keep the plugin compatible and build new features. You set the priorities, but we also ask for some room to pick things up ourselves. That is where our strength lies: not working through a list, but thinking about how the extension can be better and then actually doing it.
4. One fixed point of contact, clear agreements
You get one fixed point of contact who knows your plugin inside out. No ticket system to disappear into. We agree on response times that fit your situation; a fix for critical bugs within one business day is an agreement we make regularly. Releases follow a fixed procedure, including the Magento Marketplace guidelines if your plugin is listed there.
5. Merchant bugs: we find the cause
The vast majority of "the plugin doesn't work" reports turn out to be something else: a conflicting extension, a customised theme, a wrong configuration, a cache that was never cleared. We are very good at this. We reproduce the problem, point out the real cause and deliver either a fix in the plugin or a clear answer your support team can pass straight on to the merchant. That ends the discussion about whose fault it is.
Code you can read
Part of our work is open source. Have a look: Rvvup (and the Hyvä Checkout module), Briqpay, ICEPAY and Colissimo. That way you can see how we structure, test and release before you call us. Our test environment itself is open source too: magento2-in-a-box, the Docker images we and a large part of the ecosystem use to test plugins against every Magento version.
Platforms
Our home is Magento, in all its flavours: Adobe Commerce, Magento Open Source and Mage-OS, with Hyvä Checkout as the checkout the market is moving to. WooCommerce is becoming more important for our clients and we take that on as well, for ICEPAY among others.
Problems reach you through us, not through your merchants
We monitor your plugin continuously. If something breaks because of a change on the Magento side, on the side of your API or in a popular third-party extension, we see it in the test results before a merchant sees it in production. And if a merchant does report something, we work out whether it is the plugin or something in their store. You get a fix or an answer, not an open ticket.
What our clients say
"Control Alt Delete streamlined our webshop deployments with reliable automation. What used to require manual oversight now happens automatically with every push to main, saving us time and eliminating deployment errors."
Our work
Briqpay
Hyvä Checkout compatibility module for Swedish payment provider Briqpay: existing Magento payment flow brought natively to Hyvä Checkout, open source in Briqpay's repository, with end-to-end tests via GitHub Actions.
Bullstore
Bullstore needed stable Magento management. We updated the store and extensions, added automatic updates with CI smoke tests on key flows (add to cart, checkout reachability).
ICEPAY
Ground-up ICEPAY payment integration for Magento 2 and Hyvä Checkout, built on their modern checkout API using contemporary Magento practices, with comprehensive end-to-end testing coverage for reliability.
Magento 2 in-a-box
Open source Docker images with a ready-made Magento or Mage-OS installation for every PHP and Magento version. Built to test plugins in CI against the full version matrix, now used by Mollie, MultiSafepay, Briqpay and Rapidez, among others.
Also available on its own: testing for agencies and stores
We apply the same testing approach for Magento agencies and individual stores that want to guard their own checkout. No integration required, same peace of mind.
Our clients and partners
