How to Choose a Magento Agency in Romania

Most merchants pick a Magento agency on a referral and a good meeting, then find out the hard way whether the team can deliver. You can do better in one conversation. These are the questions that separate an agency that will move your numbers from one that will learn on your budget.

The most useful of them is the first, because it is the only claim you can independently check for free, in about five minutes, without asking anyone’s permission.

Ask for field data, not a screenshot

Every agency has a PageSpeed screenshot showing 100. Here is why that proves almost nothing, and what to ask for instead.

A PageSpeed score is a weighted composite of five laboratory measurements taken on a simulated device. Total Blocking Time is 30% of it. Largest Contentful Paint is 25%, Cumulative Layout Shift 25%, First Contentful Paint 10%, Speed Index 10%. Interaction to Next Paint, which is one of the three Core Web Vitals Google actually uses, is measured in that test and weighted at zero. So a perfect score is literally silent about a third of Core Web Vitals.

It is also graded on a curve against other websites rather than against an absolute standard, run against one URL, on one simulated device, over one throttled connection. Google itself recommends taking the median of five runs because a single run is only half as stable.

The number that cannot be faked is field data: what real Chrome users actually experienced, at the 75th percentile, over a rolling 28-day window. So ask for that instead, phrased exactly like this: the 75th percentile LCP, INP and CLS, on mobile, for a named category or product URL, with the date range.

Then check it yourself. Google publishes a free tool at CrUX Vis that shows 40 weeks of real-user history for any site with enough traffic. No account, no API key, nothing to install. Type in the store, look at whether the numbers actually moved in the weeks after the agency’s launch date. PageSpeed Insights shows the same field data under the heading about what real users are experiencing, which is the section above the lab score that most people scroll straight past.

Two honest caveats. Smaller stores often have no field data at all, because Google requires a minimum traffic level, and that absence means nothing bad about the store. And because each data point covers the previous 28 days, a genuine improvement shows up as a ramp over about a month, not a step. Compare a window fully after launch against one fully before it.

The homepage trick, and the desktop trick

Lighthouse tests one URL. On a Magento store the homepage is usually the most heavily cached and the least complex page you own. The work happens on category pages with layered navigation and forty product images, on product pages with galleries and reviews, and in the cart, which is uncacheable by design.

So ask for the same measurement on a category URL, a product URL and the cart. An agency that has done the work will have those numbers. An agency that has optimised a homepage for a sales deck will not.

Then check which device the screenshot is for. Lighthouse simulates desktop at 40ms latency, 10Mbps and no processor penalty. Mobile gets 150ms, 1.6Mbps and a fourfold processor slowdown. That is nearly four times the latency, six times less bandwidth and four times the processing cost. The scoring curves differ too: desktop earns a 90 at an LCP where mobile would be failing. A screenshot with no device label is not a claim at all.

And be wary of numbers from a staging site. Staging has no real traffic, no production catalogue pressure, no third-party scripts firing behind an unaccepted cookie banner, and by definition no field data to check it against. That unfalsifiability is exactly what makes it attractive as a sales artifact.

Ask where the time actually goes

This is the question that tells you whether an agency understands Magento or only understands themes.

Time to First Byte is the server’s share of the page load. Google considers 800ms or less good and anything over 1.8 seconds poor, and budgets it at roughly 40% of your total LCP. Since the target for a good LCP is 2.5 seconds, that is a budget of about one second. Lighthouse fails a server response over 600ms outright.

So a store with a 1.5 to 2 second TTFB has spent most of its entire performance budget before the browser has parsed a single byte of HTML. No amount of image optimisation, critical CSS or lazy loading recovers that. Magento’s answer is a full-page cache in front of PHP, which is why Adobe recommends Varnish for production, and why a cache hit and a cache miss on the same URL produce wildly different numbers.

You can measure this yourself with one command. Run curl against a product page with the write-out option for time_starttransfer, which curl defines as the time from the start until the first byte arrived. Run it five or ten times, and again with a cache-busting query string so you see a miss rather than a hit. The gap between time_pretransfer and time_starttransfer is the server’s actual thinking time, with the network distance stripped out.

A high Lighthouse score combined with a high TTFB is diagnostic, and it is common. It means somebody optimised the frontend and left the backend alone. On Vitacom, that was the entire story in reverse: the store was already on Magento 2 with Hyvä and still scored PageSpeed 12, with server response climbing toward 16 seconds. Fixing the backend took it to 100 and brought response time to 12ms. Read the full Vitacom case study.

Ask who does the work, and what they contribute

Find out whether the people in the meeting are the people who will touch your code, or whether it is handed to juniors afterwards. Ask for names, and ask what each of them shipped most recently.

Then ask whether the team contributes to the Magento or Hyvä ecosystem or only consumes it. Both projects are open source with public repositories and public issue trackers, so this is verifiable in a browser while you are still in the meeting. A team that writes modules the wider community uses is at a different level from one that only installs them, and more importantly, it is a team that can fix a problem in the platform rather than working around it for three years.

Ask the operational questions before the creative ones

The build is a few months. The relationship is years. These are the questions that decide how those years go, and almost nobody asks them during a pitch.

Where does a request live? A named ticketing system you can log into, or a WhatsApp thread nobody can search six months later.
What are the response and resolution times, in writing, by severity? A store down, payments broken, and a minor styling bug are three different emergencies and should carry three different commitments.
Who owns the code? You should own the repository, hold the credentials, and be able to hand everything to another agency tomorrow without asking permission. If any part of the answer is that they host the repository and will give you an export on request, that is a lock-in, whatever it is called in the contract.
What happens the week after launch? Launch week is when the bugs surface. An agency that treats go-live as the end of the project is planning to hand you a store and a list.
What are the working hours, and in which language? If your checkout breaks at 09:00 on Black Friday, you need a human who answers, in a language your team speaks.

The Romanian specifics that a global agency will discover mid-project

A Romanian store is not a generic European store, and the differences are not cosmetic.

Shipping is a genuine integration problem, not a configuration option. Your customers expect the couriers they already know, Sameday, Fan Courier, Cargus and DPD among them, and they expect locker delivery with a working point picker at checkout. Every one of those is a checkout-frontend component, which matters enormously if a Hyvä migration is anywhere in the plan.

Payments are equally local. Card processing through the providers Romanian merchants actually use, alongside cash on delivery, which remains a substantial share of Romanian orders and carries its own reconciliation and returns workload that a purely card-based store never has to think about.

Invoicing is a compliance obligation now, not a nice-to-have. Electronic invoice reporting through the national system has to work correctly and continuously, and an agency that has never wired it up will discover its edge cases on your deadline.

And if any part of your revenue runs through eMAG Marketplace, stock and price synchronisation between Magento and the marketplace is a project of its own, with its own failure modes.

None of this is exotic, and none of it is hard for a team that has done it. It is expensive for a team that has not, and you pay for that education.

The red flags

Walk away from a few things:

A fixed quote before anyone has looked at your code. A Magento estimate without an audit is a guess dressed up as a price.
A performance claim with no URL, no date and no device. See the whole first half of this article.
Replatforming as the answer to every problem. Sometimes the answer is deleting 180 modules.
No named developers, and no live references you can click.
Any hesitation about giving you full access to your own repository and infrastructure.
Case studies you cannot verify, and no client who will take your phone call.

Agency, freelancer, or in-house

Choosing an agency is a different question from whether you need one at all. If you are still weighing a team versus a single developer versus hiring in-house, we cover that trade-off in in-house or agency for Magento maintenance.

Book a free strategy call

Bring us your store and your goals. We will pull your real field data, measure your server response ourselves, and tell you honestly what the store needs, with numbers you can verify, before anyone talks contracts. Book a free strategy call.