Magento Extension Development

Buy when an existing Marketplace extension covers 80%+ of your need with reasonable config — it’s nearly always cheaper than custom and someone else maintains the upgrade path. Build custom when (a) no extension solves the problem, (b) you need it to integrate tightly with proprietary systems (ERP, PIM, custom checkout flows), (c) you’re selling the extension itself, or (d) the closest off-the-shelf extension would need so much customisation it’s cheaper to start clean. Our spec audit ($499) gives you the buy-vs-build call in writing before you commit.

Three fixed-price tiers, no per-hour surprises:

• Spec Audit: $499 — 1–2 days, just the spec, you can take it to any developer
• Standard Extension: $2,999 — 3–6 weeks, single-purpose extension with Hyvä + Luma support, MFTF tests, docs, GitHub repo
• Marketplace-Ready: $9,999 — 6–10 weeks, includes Adobe Marketplace submission package, EQP compliance, listing copy, screenshots, demo video, customer-support runbook

If your extension is unusually complex (multi-store ERP integration, custom payment gateway, headless GraphQL surface), we’ll quote per spec. No surprise invoices.

Typical timelines:

• Spec Audit: 1–2 days from kick-off call to delivered spec doc
• Standard Extension: 3–6 weeks — week 1 spec sign-off, weeks 2–5 build + tests, week 6 docs + handover
• Marketplace-Ready: 6–10 weeks — standard build plus Marketplace submission, EQP fixes, listing assets, demo video

Add 1–2 weeks if you want a UAT cycle with real users before sign-off.

Yes — every extension we ship includes a Hyvä-compat module by default. We use the standard Hyvä compatibility module pattern (separate view/frontend directories under Hyva_*Compat) so the extension renders correctly on both Luma stores and Hyvä storefronts without code duplication. If you only need one frontend, we’ll happily skip the other and discount accordingly — tell us in the booking form.

Yes, by design. We use data:patch over InstallSchema, di.xml over class rewrites, plugins / observers over preference, and declarative schema for any DB changes. None of those rely on internal Magento implementation details — they’re the documented extensibility surface. The Standard Extension tier includes 14 days of bug-fix coverage; Marketplace-Ready includes 12 months of upgrade compatibility (we test on each minor + patch release and ship a compat patch if anything breaks).

Yes — that’s the Marketplace-Ready tier ($9,999). It includes: full submission package (technical + marketing), Mage Extension Quality Program (EQP) compliance audit, listing copy, screenshots (admin + frontend), 60–90 second demo video, support runbook, and the actual submission to Adobe’s portal. 100% pass rate to date — every extension we’ve submitted has cleared Adobe’s code review on the first attempt because we run the EQP checks ourselves before submission.

You do, fully. When you pay us to build an extension, the source code is yours under a written assignment-of-IP clause in the contract. You can put it on your own GitHub, sell it, modify it, take it to another developer, open-source it — anything. We retain the right to reuse generic patterns (e.g. our boilerplate module skeleton, our PHPUnit test scaffolding) but never anything specific to your business logic, data, or branding.

Yes. Every extension ships with:

• MFTF (Magento Functional Testing Framework) tests for admin + frontend user flows
• PHPUnit unit tests for business logic, with fixtures for test data
• phpcs --standard=Magento2 + PHPStan level 6 linting on every commit
• GitHub Actions CI running the full suite on every push

We commit to green CI before any merge. The next developer picking up the extension can refactor with confidence because the tests catch regressions.

Yes, two docs per extension:

• User guide (admin-facing) — how a store admin installs, configures, uses the extension. Screenshots, troubleshooting tips, common pitfalls.
• Dev guide (engineer-facing) — architecture, extension points, how to override, how to add custom logic on top, API reference.

Both are markdown in the repo (so version-controlled), plus a rendered HTML version. We write docs the way we wish vendors did when we’re consuming their extensions — thorough, honest, and answering the questions you’d actually ask.

Yes, hugely. Quick rule of thumb:

• Plugin — intercepts a public method (before/around/after). Magento’s preferred extensibility mechanism. Multiple plugins can stack cleanly. Use this first.
• Observer — reacts to dispatched events. Use when Magento explicitly fires an event for what you need.
• Preference (rewrite) — replaces a class entirely. Last resort: only one preference per class wins, breaks other modules trying to do the same. We avoid this unless absolutely necessary.

Bad extensions abuse rewrites; good ones use plugins + observers. We default to plugins because they survive Magento upgrades.

Yes — 60+ open-source Magento 2 extensions on GitHub at github.com/mage2sk and github.com/mage2kishan. Real working code for SEO modules, B2B helpers, admin UX improvements, payment integrations, frontend widgets, and more. Browse the source, run the tests, read the docs — that’s the standard you can expect on your custom build. Several have been adopted by the Magento community and run on production stores.

All tiers include 14 days of bug-fix coverage after handover — anything broken because of our build gets fixed at no extra charge. After that, two options: (1) per-incident support at our standard hourly rate (handy for one-off questions), or (2) maintenance retainer ($299–$999/month depending on extension complexity) covering Magento minor + major version compat updates, security patch verification, and minor feature requests. Marketplace-Ready tier includes 12 months of upgrade compatibility built-in.