Most CTOs evaluating a Magento agency are handed a code sample sometime during the sales process, glance at it for thirty seconds, and form a vague impression that “the code looks fine.” That impression is almost never useful. A good agency and a mediocre one can produce code that looks roughly identical to a non-specialist reader, and the differences only surface in the layout of dependencies, the discipline around configuration, and the boring details that come up under load. Reading a Magento code sample properly takes about an hour, and it is one of the highest-leverage hours you will spend before signing a contract.
This guide walks through what an experienced Magento engineer actually looks at when they crack open someone else’s module. It is biased toward Adobe Commerce 2.4+ conventions, but most of the patterns apply equally well to Magento Open Source. Bemeir runs this evaluation routinely when we audit codebases inherited from previous agencies, and the patterns below are the ones that have correlated most reliably with future production pain.
The Folder Layout Tells You More Than the Code
Open the sample at the module root and look at the directory tree before you read a single line of PHP. A properly structured Magento module separates `etc`, `Model`, `Block`, `ViewModel`, `Controller`, `Plugin`, `Observer`, `Helper`, and `view/frontend` (or `adminhtml`) folders cleanly. The presence of a single bloated `Helper` directory holding eight files of unrelated logic is a strong signal that the team writes Magento like they wrote Magento 1, where helpers were the dumping ground for anything that did not fit elsewhere.
A clean modern module will also include a `Service` or `Api` folder that contains service contracts and data interfaces, plus `Setup/Patch/Data` and `Setup/Patch/Schema` directories rather than the deprecated `InstallData` and `UpgradeData` scripts that Magento removed support for in 2.3. If the agency is still writing install scripts, they are working from a 2017 mental model and have not invested in keeping their team current. Adobe’s official module structure documentation is the reference point for what good looks like in 2026.
Read the `composer.json` Before You Read Any PHP
The composer file is the most honest part of a Magento module. Look at the `require` block. Are the version constraints pinned to specific Adobe Commerce versions, or do they use wide ranges like `”magento/framework”: “*”`? Wide ranges mean the team has not actually tested against specific versions, which means the module breaks unpredictably when the host store upgrades. Look at the `autoload` section to confirm PSR-4 is used correctly and that the namespace matches the directory structure. Look for declarations of any custom test or dev dependencies, a module with zero dev dependencies almost certainly has zero tests.
Then check the `replace` field. Mature Magento agencies use it to declare the framework dependencies their module substitutes for, which signals an understanding of how to build modules that play well in larger ecosystems.
di.xml Is the X-Ray of the Codebase
If a module has any architectural ambition, that ambition lives in `etc/di.xml`. This file declares preferences, plugins, and virtual types, the three mechanisms that make Magento extensible without forking core. Read this file carefully.
Look for `<preference for=”…” type=”…”/>` declarations. A small number of preferences pointed at narrow interfaces is fine. A pile of preferences pointed at concrete classes is a red flag because it means the agency is overriding implementations directly, which guarantees painful merges every time Adobe ships a patch. Bemeir’s Adobe Commerce engineering team treats preferences as a last resort, and we expect any agency we replace to have done the same.
Plugins are where the experienced agencies shine. Look at the `before`, `after`, and `around` plugin declarations and ask yourself whether each one is solving a problem that genuinely required plugin scope, or whether it could have been solved with a simpler observer or a normal class. Overuse of `around` plugins, which can intercept and replace the entire wrapped method, is the single most common sign of a junior developer dressed up in a senior title.
The Database Schema Says Whether They Think About Scale
Open `etc/db_schema.xml` and look at the column definitions. Are foreign keys declared? Are indexes set on columns that will be queried? Does the schema use `varchar(255)` for everything, or does it match column sizes to actual data? A schema with no indexes, no foreign keys, and lazy column widths is what you get from someone who has never had a database explode under production load. Adobe’s data definition reference is the standard here, and it is short enough to read in fifteen minutes.
While you are looking at the schema, check whether the team has used `db_schema_whitelist.json`. Magento requires this file alongside any schema declaration so that future drops of columns are tracked explicitly. If it is missing, the team did not run `bin/magento setup:db-declaration:generate-whitelist` and does not know it exists.
Tests Or No Tests
A Magento module without tests is not necessarily a bad module, but the absence of tests changes your evaluation. Look for `Test/Unit`, `Test/Integration`, or `Test/Mftf` directories. Read one unit test. Are the assertions meaningful or do they just verify that constructors return objects? Are integration tests fixtures applied with `magentoDataFixture`, or has the team rebuilt fixture loading from scratch?
| Code-sample signal | What it usually means | Future production risk |
|---|---|---|
| Wide composer version ranges | No version testing discipline | Patch upgrades break unpredictably |
| Many `<preference>` declarations | Direct overrides of core | Painful merges on Adobe patches |
| Heavy use of `around` plugins | Junior interception patterns | Performance hits, hard-to-debug logic |
| No `db_schema_whitelist.json` | Unaware of schema tooling | Silent data loss on upgrades |
| No unit or integration tests | No regression safety net | Bugs surface only in production |
| `Helper` folder holding business logic | Magento 1 mental model | Tangled dependencies, low reuse |
| Service contracts present | Service-oriented architecture | Module ages well, easy to extend |
The table above is the rough scoring rubric Bemeir’s team uses internally during pre-engagement code reads.
Look for the Frontend Story
If the sample includes any frontend code, check whether the team has shipped Hyvä-compatible patterns or whether they are still hand-rolling Knockout components. In 2026, an agency that pitches Magento expertise but cannot deliver a Hyvä-native frontend is missing the most important performance shift in the platform’s recent history. Read more about how this plays out in production in Bemeir’s Hyvä migration practice, which has been the focus of most of our 2025 and 2026 frontend engagements.
For storefronts that have moved to a Tailwind-based approach, look at how the agency organizes utility classes. Are there clear component boundaries, or is every block a one-off soup of utilities? A team that has internalized a Tailwind component pattern writes CSS that other developers can read three years later.
The Commit History Tells You Whether They Refactor
If the code sample is delivered as a Git repository, the commit history is gold. Read the last twenty commits. Are commit messages descriptive? Are pull requests squashed or merged with a long history of “fix” commits? Do you see refactor commits, or only feature commits? Teams that never refactor are accumulating technical debt that you will eventually pay for. Teams that do refactor have a culture of code health that survives the loss of any individual developer.
Also look at who is committing. Is the work concentrated in one or two people, or spread across a team? A bus factor of one means that hiring the agency is really hiring that one person, and you should ask explicitly whether that person will be on your project.
What to Do With What You Find
After an hour of reading, you should be able to summarize three things: how the agency thinks about extensibility, how they think about upgrades, and how they think about scale. If any of those three are missing, you have your answer. If all three are present, you have a strong technical signal that complements whatever the sales team has told you.
Bemeir’s eCommerce development practice was founded by builders, and the team treats code review as a leading indicator of partnership fit. The agencies that pass this evaluation tend to behave the same way once they are on your codebase, which is ultimately what you are buying. For more on what changes when an agency takes over an existing Magento stack, the team’s Magento agency practice page covers the operational side of the engagement model. The technical signals in a code sample are your earliest, cheapest way to predict whether you are about to make a good hire.
