Hiring a Freelance Magento Developer: What to Ask First

I am a freelance Magento developer, so read this knowing which side of the table I sit on. Still, the questions below are the ones I would want a store owner to ask me, because a developer who answers them well is easier to work with and a developer who avoids them is a risk you can spot early.

Hiring for Magento is harder than for most platforms. The code base is large, mistakes show up as lost orders instead of a broken page, and a lot of people list Magento on their profile after touching it once. The goal of this list is not to catch anyone out. It is to find out how the person works before money and access change hands.

Experience with your version and your setup

"Magento experience" covers a lot of ground. Magento 1 and Magento 2 are different systems. Open Source and Adobe Commerce share a core but differ in features and hosting. Adobe Commerce Cloud has its own deploy process. Hyvä, Luma and headless frontends need different skills.

Questions worth asking:

• Which Magento 2 versions have you worked on recently, and have you done upgrades between minor versions, for example from 2.4.6 to 2.4.8?
• Have you worked with our frontend: Luma, Hyvä, or a headless setup with GraphQL?
• Have you worked on Adobe Commerce Cloud, if that is where we are hosted?
• Which extensions in our store have you dealt with before? ERP connectors, payment methods, search engines and B2B modules each have their own quirks.

Certifications help as a baseline, since the exams test real knowledge of the framework. They do not replace recent hands on work. Ask about both.

How they approach a problem

A good test is to describe a real issue you have and ask how they would start. You are not looking for a solution on the call. You are listening for the order of steps.

A solid answer usually starts with reproducing the problem in a non production environment, reading the logs, checking what changed recently, and only then touching code. An answer that starts with "I will install a module that fixes this" or "I will just change it on the server" tells you something too.

Also ask how they extend core behavior. In Magento 2 the expected answer involves plugins, observers, preferences used sparingly, and custom modules. Editing files inside vendor/ or app/code/Magento means your next upgrade will undo or break the change.

Code ownership and where the code lives

This is the topic store owners most often skip and later regret.

• Who owns the code written for you? The contract should say that custom code belongs to you once paid. Be clear about what is excluded, such as a developer's own reusable libraries, and on what terms you can use them.
• Where is the repository? The code should live in a Git repository that you own, on GitHub, GitLab, Bitbucket or similar, with the developer added as a collaborator. Not on the developer's account. If you part ways, you keep the history.
• Who has access to what? Give each person their own accounts for the admin, the server and the hosting panel. Shared logins cannot be revoked for one person without breaking access for everyone.
• Are paid extensions licensed to you? Commercial modules should be bought with your company account, so the license and updates stay with the store.

Environments

Ask how many environments they expect to work with. The minimum for a store that sells every day:

• A local environment on the developer's machine, usually Docker based. Warden, DDEV and Mark Shust's docker-magento are common choices.
• A staging environment that matches production in PHP version, search engine, Redis and RabbitMQ, with a recent copy of the database stripped of customer personal data.
• Production.

A developer who proposes to work directly on production "to save time" is offering to save time on the easy part and to spend it later on outages. There are exceptions, like reading logs during an incident, but changes should go through the same path every time.

Also ask how they handle customer data. A database copy for local work should have emails, addresses and payment related data anonymized. This matters for GDPR and similar laws, not only for good practice.

Testing

Ask what "done" means for them. Possible answers range from "it works on my machine" to automated tests running in CI. For most small and medium stores, a realistic and honest middle ground is:

• Static checks with PHP CodeSniffer and the Magento coding standard, and PHPStan where it fits.
• Unit or integration tests for business logic that is easy to get wrong, such as price calculation, shipping rules or integrations.
• A written checklist of manual tests for the critical path: search, product page, add to cart, checkout with each payment method, order in the admin, invoice and shipment.

Be suspicious of both extremes. A promise of full test coverage on a tight budget will not be kept, and no testing at all means you are the test.

Deploys

Ask them to describe how code gets from the repository to production. You want to hear something repeatable: a script or a pipeline that installs dependencies, compiles, deploys static content and switches to the new version, with maintenance mode only when the database changes. Ask how long the store is down during a normal deploy, and how they roll back if something goes wrong after release.

Ask when they deploy. Late Friday deploys and deploys during your peak hours are avoidable risks. A developer who brings this up without being asked is thinking about your business, not just the ticket.

Communication and pricing

• How do they estimate? Fixed price for well defined work, hourly for investigation and maintenance is a common and fair split. Be wary of a fixed price for something nobody has looked at yet.
• How do they report progress? Weekly written updates, a shared board, or both. You should never have to ask what happened to your money.
• What are their working hours and time zone? Agree on how incidents outside those hours are handled, and whether that costs extra.
• What happens when something they delivered breaks? A reasonable warranty period for bugs in their own work is normal. Problems caused by later changes from others are usually billed.

Handover

Every engagement ends at some point, and the best time to plan the ending is at the start. Ask what you will receive when the work is done:

• All code in your repository, with commit messages that explain why changes were made.
• A short document per custom module: what it does, where it is configured, which cron jobs or queue consumers it adds, and what depends on it.
• Notes on the environment: PHP version, services, cron setup, deploy steps.
• A list of every account and credential they used, so you can rotate or remove them.

A developer who is comfortable with this list is not afraid of being replaced. That usually means the work was done in a way someone else can maintain.

Red flags

• Asks for full server root access and admin credentials before any agreement, with no plan for staging.
• Cannot explain past work in technical terms, only in screenshots.
• Proposes to edit core files or to disable security patches to make something work.
• Will not commit code to your repository, or wants to keep it on their own.
• Gives a price for a large project after a five minute call.

A small paid trial

If you are unsure, start with a small paid task with a clear result: an audit of the store, a specific bug, or an upgrade plan. It shows how the developer communicates, estimates and delivers, at a cost you can afford to lose. It also gives the developer a look at your code before committing to a larger price, which leads to better estimates for both sides.

FAQ

How much does a freelance Magento developer cost?

Rates vary widely by region and experience. Compare on total cost and risk rather than hourly rate alone, because an experienced developer often finishes faster and causes fewer production issues.

Should I hire a freelancer or a Magento agency?

A freelancer fits ongoing maintenance, specific features and upgrades with a direct line to the person doing the work. An agency fits large projects that need design, project management and several developers at once.

Who should own the code a freelance developer writes?

You should, once it is paid for. Put it in the contract, keep the code in a repository owned by your company, and buy extension licenses in your own name.

What should a Magento developer hand over at the end of a project?

All code in your repository, short documentation for each custom module, environment and deploy notes, and a list of the accounts they used so access can be removed.

I am Rodrigo Biazzi, a Magento Certified Developer working with Magento and Adobe Commerce for more than 12 years. I am available for freelance Magento work, from single fixes to longer projects. If this is the kind of problem you have on your store, get in touch.