Quick answer: Check four things, in this order: proof of work you can verify, a plan for Magento versions and upgrades, written ownership of your code, and support that lasts past launch. Ask for named engineers, a reference call and a testing method. Compare price last.
Last updated: November 2026
Pick a Magento development company on evidence, not on a polished pitch. This guide gives you the questions to ask, the red flags to watch for, and a checklist you can carry into your next vendor call. Price matters, but it comes after proof, versions, code ownership and support.
Key takeaways
- Turn every claim (certified, partner, experienced) into something you can check yourself.
- Map your store’s Magento (Adobe Commerce) version to Adobe’s support dates before you sign.
- Ask for named performance targets (LCP, INP, CLS) and a testing method, not a promised score.
- Get code ownership and repository access in writing before work starts.
- Match the engagement model (hourly, monthly or project-based) to how clear your scope is.
What should a Magento partner actually deliver?
A good partner delivers advice and outcomes, not only code. Code is the smallest part of the job. A good partner tells you what to build, what to skip, and what will hurt you in a year. If a vendor only talks about features and timelines, they’re selling hours, not outcomes.
Here’s the range of work a full-scope partner usually covers. You won’t need all of it on day one, but they should be able to do it or tell you who can.
- Migration and upgrades (Magento 1 to 2, and moving between Magento 2 versions)
- Theme and frontend work, including Hyvä (a frontend theme for Magento 2)
- Custom extension development
- Integrations with ERP, PIM, CRM, payment, shipping and marketplace systems
- Performance optimisation
- Ongoing support and maintenance
That list matches what WebbyTroops lists on its Magento Development Services page. The real test is whether the vendor can explain how those pieces fit your store, not whether the list exists.
Why does judgement matter more than speed?
Because Magento (Adobe Commerce) is flexible, and flexibility cuts both ways. Almost anything can be built. Not everything should be.
Picture a store that wants a custom feature for something a stock setting already handles. A weak vendor quotes the custom build. A good one points to the setting and saves the budget. That kind of advice is what you’re paying for.
How do you check certifications and proof without taking their word for it?
Turn each claim into something you can check, and ask for evidence, not adjectives. Anyone can write “certified” on a website.
Do the named engineers really hold Adobe Commerce certifications?
Ask which named engineers hold Adobe Commerce certifications, and whether those same people will work on your project. A certified lead who disappears after the sales call doesn’t help you.
Ask to see the certificates. A vendor that’s proud of them will send them within a day.
Can you see the vendor’s published extensions?
If a vendor says they build extensions, ask for links to the listings. You can open a listing and see what the product does, how often it’s updated and how the vendor answers questions. A published product is a public track record, and it’s hard to fake.
Is the vendor an official Hyvä partner?
Want a Hyvä storefront? Ask if the vendor is an official Hyvä partner and ask for a way to confirm it. The same rule applies to any badge: if you can’t verify it, treat it as a claim, not a fact.
Can you speak to a reference or try a paid audit first?
Ask to speak with a current client whose store looks like yours in size and complexity. A logo wall isn’t a reference. A phone call is.
For a shortlist of two or three, consider a small paid audit before the big contract. It shows you how they think, how they communicate and what they notice that the other vendors missed. When you’re shortlisting a magento 2 development company, a few days of paid audit work tells you more than a polished slide deck ever will.
Which Magento version will you run, and what’s the upgrade plan?
Pick the version from Adobe’s support dates, and ask the vendor how they will keep you on a supported line. This is the question many merchants forget to ask. It’s also where the money gets lost.
Adobe supports each Magento (Adobe Commerce) release line for a limited time. After regular support ends, a line may get a period of extended support. After that, you’re on your own. Here are the dates Adobe publishes on its release-versions page:
| Release line | What Adobe lists |
|---|---|
| 2.4.9 | Released May 12, 2026. Regular support to May 31, 2029 |
| 2.4.8 | Regular support to May 31, 2028 |
| 2.4.7 | Regular support to May 31, 2027. Extended support to May 31, 2028 |
| 2.4.6 | Regular support ended Aug 11, 2026. Extended support ends Aug 31, 2027 |
| 2.4.5 | Regular support ended Aug 12, 2025. Extended support ended Aug 11, 2026 |
| 2.4.4 | Regular support ended Apr 12, 2025 |
Adobe’s 2.4.9 release notes also list official support for PHP 8.5 and Symfony 7.4 LTS, which is worth knowing if your vendor plans a stack upgrade alongside the version bump.
Read that table with today’s date in mind. As of November 2026, a store on 2.4.5 is past both its regular and extended support. A store on 2.4.6 is in its extended window, with a clock running.
What should the vendor tell you about versions?
A good partner looks at your current version and answers three things without being pushed:
- Where you are on Adobe’s support timeline
- Which version you should target, and when
- What the upgrade will touch (extensions, custom code, theme, integrations)
Adobe also recommends installing the latest patch for each release line. So ask how patches are handled on your project. Who applies them? How fast? Is it in the contract or is it a surprise invoice?
If you’re still on Magento 1, the picture is simpler and harsher. It reached end of life on June 30, 2020, and official security fixes stopped then. OpenMage is a volunteer-maintained fork, which means there’s no service-level promise behind it. For most merchants in that spot, a migration plan is the first conversation, not the last. WebbyTroops also has a Magento 2 update service page for routine version updates.
Why does this matter for choosing a vendor?
Because upgrades are where badly built stores show their age. Heavy custom changes to core behaviour, abandoned extensions and hard-coded hacks often make the next upgrade slower and pricier. A vendor who plans for upgrades will build in a way that keeps that cost down.
What questions should you ask before signing?
Ask about scope, performance, frontend, security, code ownership and support. Bring this list to every call. The answers matter, but so does how easily they come.
Scope: what’s in and what’s out?
Get a written scope with named deliverables. Vague phrases like “full development” or “as required” are where disputes start later. If something is out of scope, it should say so in plain words.
Also ask what assumptions the quote relies on. A quote built on “your data is clean” and “your extensions are compatible” can change fast once someone looks under the hood. A code review up front, such as a Magento code audit, takes some of the guesswork out of those assumptions.
Performance: what numbers are you aiming for?
Use Google’s Core Web Vitals as the targets. Don’t accept “we’ll make it fast.” Ask what they’ll measure and what the target is. Core Web Vitals give you a shared language. At the 75th percentile of visits, a good score means:
- Largest Contentful Paint (LCP): 2.5 seconds or less
- Interaction to Next Paint (INP): 200 milliseconds or less
- Cumulative Layout Shift (CLS): 0.1 or less
INP replaced First Input Delay as a Core Web Vital in 2024, so if a vendor’s pitch still talks about FID, that’s a small sign their knowledge is dated.
Ask, too, how they’ll test: on real devices, on your real catalogue, before and after launch. Don’t ask for a promised score. Nobody can safely promise one. Ask for a method.
Frontend: is Hyvä on the table?
Hyvä is a frontend theme for Magento 2, and it is worth raising early. It keeps Magento’s PHP templating and uses Tailwind CSS and Alpine.js, so it’s not a headless or PWA setup. Hyvä announced on November 6, 2025 that the Hyvä Theme itself is free and open source, available from November 10, 2025. Some Hyvä products, like Hyvä Checkout, are still paid, and Hyvä Checkout is built on Magewire and Alpine.js.
For context on results, Hyvä reports more than 7,000 merchants, requests cut from 230 to 5 and page weight cut from 3MB to 0.4MB. WebbyTroops states its own Luma-versus-Hyvä mobile PageSpeed figures as 20-45 against 85-98. Treat both as vendor-reported numbers, not a promise for your store.
So the theme itself is no longer a licence cost. Ask the vendor which other Hyvä products, if any, your plan needs. Then ask where the real work sits. Extensions are a common place to look. Extensions built for the older Luma theme may need a compatibility module, and Hyvä keeps a tracker of existing ones. Ask the vendor to list which of your extensions have a module and which will need custom work.
Also check the requirements. Hyvä lists minimum Magento patch levels and PHP versions, so ask the vendor to confirm them against Hyvä’s current docs for your exact store.
Security: how are patches and access handled?
Beyond patch timing, ask about access. Who gets admin accounts? Is there a separate staging site? Are credentials shared in chat threads? These sound like small things. They’re the habits that decide whether a bad day turns into a bad week.
Ownership: who owns the code?
Get this in writing before work starts. You want clarity on three points:
- Your store’s custom code belongs to you, per the agreement
- The code lives in a repository you can access, not only on the vendor’s machines
- Any third-party or vendor-owned components are listed, with licence terms
If a vendor gets awkward about this, pay attention. It’s a lot cheaper to ask now than to negotiate it during a breakup.
Support: what happens after launch?
Launch is the start of the real work. Ask how long the post-launch support window is, what’s covered, how requests are raised and what the response times are. Then ask what happens after that window. A Magento support and maintenance plan should spell out coverage and response times, not just say “we’re here when you need us.”
What are the red flags in a proposal?
Some warning signs show up before the contract. Watch for these:
- No discovery step. If a quote arrives without questions about your catalogue, integrations or traffic, it’s a guess dressed as a price.
- One number, no breakdown. You can’t compare, challenge or trim a lump sum.
- Vague scope words. “Etc.”, “as needed” and “standard features” are blank cheques.
- Silence on versions. If the proposal never names a Magento version or an upgrade path, nobody has thought about it.
- Guarantees nobody can keep. Promised ranking jumps, promised conversion lifts or promised Lighthouse scores should make you pause.
- Pressure to sign this week. A good partner can handle a few days of your questions.
- Unverifiable badges. Credentials with no names, no links and no way to check.
- Testing is missing. If QA isn’t a line in the plan, it’s probably going to be you.
None of these alone ends the conversation. Two or three together usually do.
Which engagement model fits your store?
Vendors usually offer some mix of hourly, monthly and project-based work. Each fits a different situation. For reference, WebbyTroops states its models as hourly (8-hour minimum per day), monthly (30-day minimum) and project-based (6-month minimum). It doesn’t publish rates, so you’d ask for a quote.
| Model | Best for | Watch out for |
|---|---|---|
| Hourly | Small fixes, urgent bugs, short experiments | Open-ended hours with no cap or reporting |
| Monthly | Ongoing improvements, steady backlog, maintenance | Paying for capacity you don’t use |
| Project-based | A defined build, migration or redesign | Scope creep and change-request fees |
How do you match the model to the job?
Start with how clear your scope is. If you can describe the finished result in a page, project-based pricing works. If you know the direction but not the details, monthly gives room to adjust. If it’s a single problem, hourly is cheap and quick.
A magento ecommerce development company should be comfortable moving you between models as your needs change. A store might begin with a fixed-scope migration, then shift to a monthly arrangement once the new platform is live. That’s normal. What isn’t normal is a vendor that only offers one model and bends your needs to fit it.
Whatever you pick, ask how time is reported. Weekly summaries, a shared task board and named people on each task keep everyone honest.
How do you read a proposal without a technical background?
You don’t need to understand every line. You need to see whether the vendor understood you. Read it in this order.
- Goals first. Does the proposal restate what you want in your words? If it reads like a template with your name pasted in, it probably is.
- Scope next. Are deliverables listed? Are exclusions listed?
- Process after that. Is there a clear path from audit to planning to build, testing, launch and support? A defined process is a good sign. It means the vendor has done this enough times to write it down.
- Then the people. Who’s the project lead? Who writes the code? Who tests it?
- Then the timeline. Are there milestones with something you can see at each one?
- Price last. Compare line items across vendors, not totals.
If you can’t follow a section, ask for a plain-English version. A vendor that can’t explain their own proposal simply, in a call or an email, is telling you something.
What checklist can you reuse for every vendor?
Print this table, fill it in for each vendor on your shortlist, and compare the answers side by side.
| Check | What a good answer looks like |
|---|---|
| Certified engineers | Named people, certificates you can see, assigned to your project |
| Published work | Links to live extensions or stores you can open |
| References | A call with a current client in a similar situation |
| Version plan | Your version mapped to Adobe’s support dates, with a target |
| Upgrade approach | A plan for patches and future upgrades, in writing |
| Performance | Named metrics (LCP, INP, CLS) and a testing method |
| Scope | Deliverables and exclusions listed in plain words |
| Code ownership | Written, with repository access for you |
| Security habits | Staging site, controlled access, patch process |
| Post-launch support | Defined window, coverage and response times |
| Pricing | Itemised, with assumptions stated |
| Communication | One lead, regular updates, plain language |
What should the first 30 days look like?
A strong start looks calm and a bit boring. Here’s a realistic shape, which you can adjust for your project size.
Week 1: access and audit
The team gets access to code, hosting, analytics and the admin. They review the store: version, extensions, custom code, theme, integrations, performance. You should receive a short written summary of what they found, including the awkward bits.
Week 2: plan and agree
Findings turn into a plan. You see scope, order of work, risks and a timeline. Anything that changed from the proposal is called out, with reasons. You approve it before the heavy work starts.
Weeks 3 and 4: first build cycle
Work starts on a staging copy, never on the live site. You get something to look at, even if it’s small. Testing begins early rather than being saved for the end. Reports arrive on the schedule you agreed.
By day 30, you should know three things: what’s been done, what’s next and what’s changed. If you don’t, raise it right away. Small communication gaps in month one turn into big ones in month three.
So, who’s the right partner?
There’s no single best magento development company for every store. There’s the one that fits your platform version, your budget, your integrations and the way your team likes to work. The checklist above helps you find that fit using evidence instead of impressions.
If you’d like a second opinion while you shortlist, WebbyTroops offers a free 30-minute technical and strategy call, with Adobe Commerce certified engineers on the team and a six-step process of audit, plan, build and integrate, QA, controlled launch and support. For Hyvä projects, WebbyTroops states a typical timeline of 8 to 12 weeks and two months of free post-launch support. Bring your current proposals and your questions. You’ll leave knowing what to ask next, whether you hire them or not.
Frequently asked questions
How do I check that a Magento vendor is really certified?
Ask which named engineers hold Adobe Commerce certifications, ask to see the certificates, and confirm those same people will work on your project. Treat any badge, including an official Hyvä partner claim, as a claim until you have a way to verify it. A vendor proud of its credentials will send proof within a day.
Which Magento versions are still supported in November 2026?
Per Adobe’s published dates, 2.4.9 (released May 12, 2026) has regular support to May 31, 2029, and 2.4.8 to May 31, 2028. Version 2.4.7 has regular support to May 31, 2027 and extended support to May 31, 2028. Version 2.4.6 is in extended support to August 31, 2027. Version 2.4.5 has passed both support windows.
Is the Hyvä theme free now?
Yes. Hyvä announced on November 6, 2025 that the Hyvä Theme is free and open source, available from November 10, 2025. Some Hyvä products, such as Hyvä Checkout, remain paid. Extensions are a common place to look for extra work, because extensions built for the older Luma theme may need compatibility modules or custom work. Ask your vendor to list which ones.
Which performance targets should a Magento vendor measure?
Google’s Core Web Vitals give a shared yardstick. At the 75th percentile of visits, a good score is Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less. Nobody can safely promise a score, so ask for a testing method on real devices, before and after launch.
Should I pick an hourly, monthly or project-based engagement?
Match the model to how clear your scope is. Project-based pricing suits a defined build or migration, monthly suits an ongoing backlog or maintenance, and hourly suits small fixes or urgent bugs. WebbyTroops states its minimums as 8 hours per day for hourly, 30 days for monthly and 6 months for project-based, and it does not publish rates.
Sources
- Adobe, Magento release lines and support dates: https://experienceleague.adobe.com/en/docs/commerce-operations/release/versions
- Adobe, Magento 2.4.9 release notes: https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/magento-open-source/2-4-9
- IWD Agency, Magento 1 end of life (secondary source): https://www.iwdagency.com/blogs/news/magento-1-end-of-life/
- web.dev, Core Web Vitals thresholds: https://web.dev/articles/vitals
- Hyvä, Hyvä is free and open source (announcement): https://www.hyva.io/blog/news/hyva-is-free-open-source.html
- Hyvä (vendor site, vendor-reported figures): https://hyva.io
- Hyvä docs, getting started and requirements: https://docs.hyva.io/hyva-themes/getting-started/index.html
- Hyvä docs, compatibility modules: https://docs.hyva.io/hyva-themes/compatibility-modules/index.html
- Hyvä docs, Hyvä Checkout: https://docs.hyva.io/hyva-checkout/index.html