In short
- The problem: founders pick between an agency and a senior engineer by comparing day rates, then pay for the wrong choice later in rework, slow fixes, and a site nobody fully understands.
- What I do about it: decide on one question first: does this software need an owner after launch, or just a delivery? Agencies are built for delivery. Senior engineers are built for ownership.
- Who this is for: founders, store owners, and product leads whose WordPress or WooCommerce site has become important enough that "who looks after this" is a real decision.
The version of this I see most often goes like this. A business hires an agency to build a WooCommerce store or a custom plugin. The launch goes well. Six months later the business needs changes every week: a new payment method, a subscription tweak, an integration with the warehouse. Each change becomes a quote, a ticket in someone else's queue, and a developer who has not seen the code since launch.
Nothing about the agency was bad. The mismatch was structural. The business bought a project and then needed a product.
The opposite mistake happens too. A founder hires one strong engineer to build a marketing site with a tight launch date, a brand refresh, and twenty landing pages. The engineer is excellent at the plugin work and spends weeks on design and content tasks a small agency team would have finished in parallel.
Both choices can be right. The trick is knowing which problem you have.
The real question is who owns the system after launch
Start with what happens the month after go-live, not the build itself.
If the site will mostly stay as built (a brochure site, a campaign site, a store with a stable catalog and standard checkout), you need someone to deliver it well and be reachable for occasional fixes. That is a project, and projects are what agencies are organized around: a scope, a team, a timeline, a handover.
If the site will keep changing because the business keeps changing (custom checkout logic, a membership or subscription model, integrations with an ERP or CRM, a plugin you sell), you need someone who carries the whole system in their head and makes decisions about it every week. That is ownership. Ownership does not survive handovers well, and it is the thing a senior engineer is hired for.
Most of my career has been on the ownership side: owning the Paysera WooCommerce gateway plugin from spec through maintenance, and owning core SureCart engineering at Brainstorm Force as it grew. The work that mattered most in those roles was rarely the first build. It was the hundredth change, made safely, by someone who knew why the first ninety-nine were made.
An agency is the better buy for a defined project with a deadline
Agencies are good at things a single engineer structurally cannot match:
- Parallel skills. Design, front-end, back-end, content, and QA can happen at the same time. One engineer does them in sequence.
- Elastic capacity. A launch that needs five people for six weeks and nobody afterwards is exactly what an agency's staffing model exists for.
- Process you do not have to build. Discovery workshops, staging environments, sign-off steps, and project managers who chase you for content. If your company has none of this, the agency brings it.
- Continuity of the company, not the person. If one developer leaves, the agency still owes you the work.
Where agencies are weaker is predictable from how they make money. Their best people are spread across many clients. Knowledge of your system lives in whoever happened to build it, who may be on another account by the time you need them. And long-term maintenance is often priced as a retainer for a pool of hours, not as someone thinking about your architecture.
That is not a criticism. It is the shape of the business. Buy an agency for what it is good at.
A senior engineer is the better buy when the software is the business
A senior engineer, whether full-time or on a long contract, makes sense when:
- The site makes or loses money through custom code. Checkout, payments, subscriptions, multi-vendor payouts, B2B pricing. Bugs here are lost orders, not cosmetic issues.
- Changes are continuous. Weekly or monthly releases, not one launch and a few tweaks.
- Integrations are the hard part. Payment gateways, ERPs, shipping, accounting, external APIs that fail in creative ways.
- You need someone to say no. A senior engineer's value is as much in the plugins they refuse to install and the features they push back on as in the code they write.
What you are paying for is judgment that compounds. The second year of a good engineer on one system is worth far more than the first, because they know where the bodies are buried: which plugin cannot be updated without testing, which hook a past integration depends on, why the order table has that odd index.
The weaknesses are just as real. One person is one person. They have a finite number of hours, one set of strengths (a strong plugin engineer is not automatically a good designer), and if they leave without documentation, you are worse off than with an agency.
Day rates are the wrong comparison
Founders usually compare an agency's day rate with an engineer's salary or contract rate, and the numbers point whichever way the founder already wanted.
The costs that actually decide it rarely show up on the quote:
- Ramp-up on every change. When the person making a change did not build the system, each ticket starts with re-learning it. On a codebase with a lot of custom logic, that re-learning can be a large share of the hours billed.
- Handover loss. Every time ownership moves (agency to agency, agency to in-house, engineer to engineer), some knowledge does not make the trip. You pay for it later as bugs in code nobody remembered was load-bearing.
- Decision latency. An in-house owner fixes a broken checkout the same morning. A ticket in an agency queue gets fixed when it reaches the front. For a store, the difference is measured in orders.
- Rework from scope gaps. Fixed-price projects are only as good as the scope. Anything the scope missed becomes a change request, or gets built the quick way to stay on budget.
None of this means agencies are more expensive. For a stable project they are often far cheaper, because you are not paying anyone to be around when nothing needs doing. It means the comparison should be total cost over the next two years, not price per day.
Agencies sell a team, so check who is actually on it
If you go the agency route, the most useful questions are about people, not process:
- Who specifically will write the custom code, and have they shipped WooCommerce or plugin work at this level before?
- Will the same people be on maintenance after launch, or does it move to a support team?
- What does the handover include: a repository you own, deployment steps, written notes on the custom parts?
- How do they handle plugin updates and WordPress core updates on a site with custom code?
A strong agency will answer these easily. Vague answers about "our team of experts" usually mean the person who builds your site will not be the person who fixes it. If you want a list of what to look for in individual developers' work, I covered that in hiring a freelance WordPress plugin developer.
One senior engineer is a single point of failure unless you plan for it
If you go the engineer route, plan for the day they are unavailable from the start. This is part of the job, and a good senior engineer will raise it before you do:
- The code lives in your repository, under your organization's account, not theirs.
- Deployments are scripted, not a sequence of steps only one person remembers. A zero-downtime deploy is written for Laravel, but the principle is the same for WordPress: a repeatable release anyone can run.
- Decisions are written down. Short notes on why the checkout works the way it does are worth more than long documentation nobody reads.
- Tests cover the money paths. Checkout, payments, renewals, and refunds should have automated tests, so the next person can change them without fear. At SureCart this was a deliberate investment: coverage went from 30% to 90%, and that is what makes it safe for more than one person to change the code.
- There is a second pair of eyes. Even part-time code review from another engineer, or a small agency on standby, removes the bus-factor risk.
The hybrid that works: a senior owner plus outside help for bursts
For a business that has outgrown "a website" but is not ready for an engineering team, the arrangement I would recommend most often is a combination:
- A senior engineer owns the system. Architecture, custom code, integrations, code review, release decisions, and the final say on which plugins are allowed.
- An agency or freelancers handle the bursts. A redesign, a batch of landing pages, a content migration. Work that is parallel, well scoped, and does not change the core.
The owner writes the brief, reviews the agency's work before it merges, and makes sure the burst does not leave behind code nobody understands. The agency does what it is good at without having to own what it will not be around to maintain.
This is also how good product companies run. A core team owns the product, and outside help is brought in for specific pieces with a clear boundary.
When you need neither
Sometimes the honest answer is to hire nobody for custom work:
- The site is standard. A theme, a page builder, and well-known plugins cover it. What you need is a reliable host and someone to apply updates, which is a maintenance service, not an engineer or an agency build.
- The platform is wrong. If you are paying for custom WooCommerce work to replicate what another platform does out of the box, the decision to revisit is the platform. I compared the options in WooCommerce vs Shopify for custom builds.
- The idea is not validated yet. Spending on a custom build before you know people will pay is the most expensive way to find out. Launch with off-the-shelf tools first, then invest where the business proves it needs something custom.
What I check before recommending one or the other
- How often will this site change after launch? Weekly or monthly points to an owner; rarely points to a project.
- Where does the money flow through custom code? Checkout, payments, subscriptions, or payouts on custom logic need someone accountable for them every day.
- Who owns the repository, hosting, and domain today? If the answer is "the last agency", fix that first, whatever you decide next.
- Is there a written scope that would survive a new team reading it? If not, an agency will price the uncertainty, and an engineer will spend the first weeks discovering it.
- What breaks if one person disappears for a month? Tests, scripted deploys, and written decisions should make the answer "not much".
- Which work is parallel and short-lived? Design, content, and campaigns are good agency work. Core logic is not.
- What will the next two years cost, not the next two months? Include ramp-up, handovers, and how long urgent fixes take.
My verdict: hire an agency when you need something built and can describe it fully up front, and hire a senior engineer when the software is part of how the business makes money and will keep changing. If you are in between, get one senior person to own the system and bring in an agency for the bursts. The mistake is not choosing the "wrong" one in the abstract. It is buying delivery when you needed ownership, or paying for ownership of something that will barely change.