Who should build your eCommerce platform: a freelancer, an agency, a software house or an in-house team
Four delivery models held to the same standard: when each one is right, how it bills, what is left when it goes away and where it usually breaks. With a decision table, the questions to ask before signing, and the things builders do not publish about themselves. Checked 17 August 2026.
A freelancer fits a change you can close in a few weeks and then run without anyone’s help. A software house and an agency both fit building a platform, except a software house sells a project with a scope and a date, while an agency sells continuity and a wider set of skills in one place. An in-house team only makes sense once the backlog is steady and large enough that salaries cost less than invoices for the same work.
Key takeaways
- Who builds it moves more money than what you build it on. Elogic, an agency that implements Shopify, puts the platform licence at 20-40% of total replatforming cost, with implementation, ERP work and data migration accounting for the other 60-80%.
- The four models answer two questions at once: how big the change is, and whether the need is one-off or continuous. Fixed cost only appears with an in-house team, and it arrives together with the highest control and the full responsibility.
- Of the twelve firms we looked at on 17 August 2026, ten publish no price at all, none publishes an engineering standard as part of the offer, and the improvement percentages on their sites are self-reported claims with no methodology attached.
- Five questions decide more than any portfolio: who owns the code, what exactly a handover contains, what happens if you part ways, how the code gets written and reviewed, and what maintenance actually covers.
The question of who to hire usually comes up before the platform choice and before the first quote. Almost everything written about it comes from parties with an interest in one answer. Agencies explain that freelancers disappear. Freelancers explain that agencies bill you for an account manager. We build eCommerce platforms, so we are a party too, and we would rather say so upfront than perform neutrality.
In the Brave Search index on 17 August 2026, the first three results for “ecommerce development agency” were directories rather than builders. Directories rank firms by reviews and declared rate bands, which are useful filters and poor answers to a fit question.
That gap is what this piece is for.
The scope here is narrower than the title suggests: no platform comparison, no head-to-head between two specific offers. What a build costs on each of eight platforms, and who publishes each number, is laid out in a separate piece, and two complete routes are compared in Shopify Plus with an agency versus a Medusa platform. Here the subject is the earlier decision: four delivery models.
Why this decision outweighs the platform choice
Elogic, an agency that implements Shopify, publishes a line in its replatforming cost index that turns most platform comparisons upside down: the platform licence is only 20-40% of total replatforming cost, and implementation, ERP work and data migration drive the other 60-80%. That comes from a firm selling implementations on a paid platform, so it gains nothing by playing down the licence. We checked it at source on 12 August 2026. The index covers moving to a paid platform, which is the only case where a licence enters the sum at all.
If the proportion is even roughly right, the money follows the people, not the logo on the stack.
The practical consequence: if you spend three weeks choosing a platform and three days choosing who builds it, you are splitting your attention in the opposite direction to what the public numbers on cost structure suggest.
Freelancer: no overhead, and all the risk on one person
One person, one contract, usually one technology known well. The main advantage is the absence of overhead: you talk to the person writing the code rather than to someone who will pass your note along. The same person decides and lives with the decision, which makes the feedback loop as short as it gets.
- When it is the right call: a simple catalogue, one sales channel, a store on an existing theme, or a single integration. Also when you already have your own technical person and what you need is hands rather than decisions.
- How it bills: a day rate or an hourly rate, less often a fixed price for a carved-out slice. One useful reference point comes from a platform vendor itself: PrestaShop puts a freelancer build at 2,000-8,000 EUR against 5,000-25,000 EUR at an agency (vendor publication, checked 13 August 2026).
- When they go away: the project stops and nobody else holds the context. The risk is structural rather than personal, because illness and better offers happen to everyone. What matters most with a freelancer is therefore not the contract wording but where the code lives and whose name is on the accounts.
- The usual failure point: the moment the store stops being a simple store. A second integration, a second market and the first real peak all demand backend, infrastructure, performance and security at once. One person rarely holds all four at the same level.
Agency: you buy continuity and negotiate the rights separately
An agency sells continuity and breadth: design, front end, code, campaigns and ongoing care from one place. In practice two agencies can differ more than two models do, because some grew out of marketing and others out of implementation work.
- When it is the right call: when the need is continuous and mixed. The store has to launch, then keep developing, with campaigns, content and analytics alongside. What you are buying is not having to coordinate four suppliers yourself.
- How it bills: a fixed price or hourly for the build, then a retainer after launch. Rate bands collected on 12 August 2026 put mid-senior agencies at 125-175 USD per hour and Shopify Plus certified partners at 175-300 USD per hour, which is the widest single spread in this whole comparison and has more to do with certification and geography than with skill.
- When they go away: the store keeps running, because agencies rarely vanish overnight. What stays open is who holds the rights to what they built, and who holds the accounts: repository, cloud, domain, ad platforms. That is a contract question, not a technical one.
- The usual failure point: staffing churn. The team that learned your store gets moved to a larger client and new people learn your context on your budget. The quieter version: the account manager becomes a translation layer through which less and less technical information travels back.
Software house: hard scope, estimation risk on your side
A software house sells software delivery: a project team, a process and a scope. It sits closer to an engineering supplier than to a marketing partner, and its strength is finishing projects with many moving parts. When an ERP integration, a data migration and a new front end are alive in the same month, somebody has to hold the order and the dependencies, and that coordination is what you are paying for.
- When it is the right call: when you are building something that does not exist as a configuration option. A B2B portal with contract pricing, a configurator, ERP and warehouse integrations, a multi-vendor platform. Also when you need a team for a few months and do not want to hire permanently.
- How it bills: usually time and materials, meaning a rate multiplied by hours used. Public bands collected on 12 August 2026: Eastern Europe 40-70 USD per hour, Western Europe 70-100. Polish firms on Clutch most often declare 50-99 USD per hour with project minimums of 5,000-25,000 USD and up. These are directory declarations, not measured transaction rates.
- When they go away: a contract ends, not a relationship with a platform. What remains is code somebody has to maintain and the question of whether the documentation describes what is actually running in production. A good supplier leaves a repository and a rebuild-from-scratch runbook; a weak one leaves an archive of files.
- The usual failure point: billing for time against a scope that was never closed. The estimation risk sits with you and the supplier has no reason to finish early. Why we bill differently is set out in fixed scope versus hours.
In-house team: the context stays, and so does the fixed cost
An in-house team is the only model where the context stays inside the company permanently. People know the assortment, the margins, the customers and the history of decisions, so the next change does not begin with explaining how the business works. That advantage compounds over years and it is the one thing an invoice cannot buy.
- When it is the right call: when the backlog is steady and large, and eCommerce is the core of the business rather than a channel beside it. A practical test: if there has been work waiting every month for the last twelve, and the list grew faster than it shrank, fixed cost stops being a risk.
- How it bills: a fixed cost, independent of how much work any given month brings. We publish no salary bands here, because as of August 2026 we have no source we could cite with a date, and an invented number would be the worst possible favour. Build it from real listings for your roles and your region, adding recruitment, equipment, holidays and ramp-up time.
- When they go away: what usually leaves is not the team but one person whose head held the knowledge. It is the most common failure of this model and it has nothing to do with competence, only with whether decisions were written down somewhere other than in memory.
- The usual failure point: skills used unevenly. Security, performance, infrastructure and migrations are needed a few times a year, while a salary runs all year. In-house teams normally buy those in anyway, and that is healthy rather than a failure of the model.
That decision returns in all four models, at different moments. Covered separately in the eCommerce team after launch.
Us, held to the same standard
Honestly: we are not a fifth species. We are a software house narrowed to one domain that sells an outcome instead of hours. Same grid as above, so we can be compared rather than merely read. This section is advertising and we are not pretending otherwise. It stays in the same grid as the other four models, because a comparison that stops where the sales pitch starts is worth very little.
- When we are the right call: when you need an eCommerce or B2B platform that cannot be assembled from configuration, and you want to own it together with the care that keeps it running. With a simple catalogue and small scale we are overkill, which we say plainly further down.
- How we bill: a fixed price resting on written assumptions. Engineering from about 14,000 EUR, typically 18,500 to 46,500 EUR depending on catalogue, integrations and migration scope. AI Automation from about 1,400 EUR per workflow. Maintenance & Growth from about 800 EUR per month. The Blueprint is not sold separately: its amount sits in the contract from day one and becomes an invoice only if you stop after it. These are ranges, not an offer.
- When we go away: you keep the application code, the database, the documentation and the Blueprint plan. The plan is specific enough to send to three other firms and get comparable quotes back. The platform runs whether or not we work together.
- The usual failure point: a fixed price does not survive changing your mind mid-build. Scope is locked before the start and new ideas go to the backlog to be priced separately. If your project has a genuinely fluid scope, this model will chafe.
The euro figures above are conversions. We set these ranges in Polish złoty for the Polish market (Engineering from 60,000 PLN, typically 80,000 to 200,000 PLN; AI Automation from 6,000 PLN per workflow; Maintenance & Growth from 3,500 PLN per month) and convert at a rounded 4.31 PLN to 1 EUR, the NBP mid rate of 17 August 2026, table 158/A/NBP/2026. Rates move, so treat the euro numbers as orientation.
BEAM is the platform you end up running your whole eCommerce from: store, sales channels, product data and processes in one place, with AI agents that know your context, and the four stages of delivering it are described on our services pages.
Two axes sort this faster than any list of advantages
First: is the need one-off or continuous. Second: how much fixed cost you are willing to carry in exchange for control over the code and the pace. Everything else follows from those two.
| Model | Fits which need | Cost structure | Control over code and pace | What is left if you part ways |
|---|---|---|---|---|
| Freelancer | A one-off change of simple scope, measured in weeks | Fully variable, day or hourly rate, no fixed cost | High, provided the code and the accounts are yours from day one | The code, and one person who held the context and will not hand it over |
| Agency | A continuous, mixed need: build, development, marketing | Build plus a retainer, growing with the scope of care | Medium, depending on rights clauses and whose accounts these are | The store keeps running; rights to the agency’s work depend on the contract |
| Software house | A project with a hard scope and date, many moving parts | Usually time and materials, estimation risk sits with you | High over the code, lower over pace and cost | A repository and documentation, if they were part of the scope |
| In-house team | A steady, large backlog with eCommerce as the core business | Fixed cost, independent of how busy a given month is | The highest, together with full responsibility for the outcome | Everything, for as long as the people and the written decisions stay |
| Seedlight | Building a platform you own, plus care after launch | Fixed price for the build, a retainer after launch | High: the application code and the database sit on your side | Code, database, documentation and the Blueprint plan |
As of 17 August 2026. The table organises models, it does not rate individual firms. Two agencies can differ more than an agency and a software house do, so treat this as a starting point for questions rather than a verdict.
Ten of the twelve publish no price at all
This is the core of the piece. On 17 August 2026 we went through the websites of twelve firms building eCommerce and AI automation for eCommerce, Polish and international. Four things recurred often enough to be worth asking about rather than looking for on a website.
- Pricing sits behind a contact form in ten cases out of twelve. One firm publishes real packages, one other is alone in describing its pricing model openly. Comparing offers therefore starts with who will state a price at all, not with who is cheaper.
- None of the twelve publishes an engineering standard as part of the offer. Nowhere is there a description of how the code gets made: branches, code review, automated tests, how anything reaches production. The communication is entirely about business outcomes and never about how they are produced.
- The improvement percentages on these sites are self-reported. Four firms of the twelve publish concrete figures: average order value, conversion, revenue, time to market. None links a methodology or third-party verification, which makes those numbers unusable for comparing offers.
- One firm in twelve offers public code as evidence. One maintains a genuine public repository at 161 stars (GitHub public API, checked 17 August 2026), one states a preference for open source without linking anything, and the remaining ten show no code at all.
What this data is, so there is no misunderstanding. It is a study of twelve specific firms, not of a market. The sample was drawn from the Brave Search index rather than Google, so the same query may well surface different firms for you. Offer details come from visiting the sites directly, GitHub figures from the public API, everything checked on 17 August 2026. We are not claiming this is how the market looks, or that it applies to all agencies.
A missing price says nothing about the quality of the work. It says the comparison will start with phone calls instead of a spreadsheet. The same goes for a missing description of process: it can be absent from a website and present in the company. The finding applies to us as well, with one exception: we publish the ranges above deliberately, and that is a choice rather than an advantage nobody can copy. Any of those twelve firms could publish theirs tomorrow. How we ourselves work with AI tooling on someone else’s codebase is described in Claude Code on client projects.
Ask these five before signing, not after the first outage
This part is meant to work even if you pick somebody other than us. Write the answers down.
| Question | What a good answer contains | Warning sign |
|---|---|---|
| Who owns the code, and from when? | An assignment of rights to code written for you, with the moment of transfer and the exceptions named: open source libraries and the supplier’s own pre-existing components. | A reassurance that “of course the code is yours” with no clause behind it. Or a licence described using the word “ownership”. |
| What exactly does a handover contain? | The repository with full history, cloud accounts in your company’s name, architecture documentation, a runbook for rebuilding the environment from zero, and a list of secrets to rotate. | A handover described as “a code package”. Infrastructure sitting in the supplier’s account because “it is easier that way”. |
| What happens if we part ways? | Notice period, who transfers knowledge and over what period, whether the handover is billable and how long it takes, plus what happens to the domain, certificates and monitoring. | No exit description of any kind. This is the most commonly skipped clause in build contracts and the most expensive one to skip. |
| How does the code get written and reviewed? | Specifics: branches and code review, automated tests, who approves a release to production, how a change gets rolled back. Ask to see it on a live project. | Generalities about “best practices” and an “experienced team”. With AI tooling: no stated rules about what does and does not go to a model. |
| What exactly does maintenance cover? | What is inside the retainer and what is outside, separate response times for a sales-blocking outage and for a defect, who is on call out of hours, and how larger changes get priced. | A single monthly figure with no scope and no response times. Maintenance offered “as capacity allows”. |
The questions work the same for a freelancer, an agency and a software house. With an in-house team you are the recipient of the first three, because you are the one deciding where the code lives and who holds the accounts.
A builder who answers these specifically is a better choice than one who answers more elegantly. If an answer sounds like a reassurance rather than a description of a procedure, ask for it in the contract. A refusal is also an answer.
Who we are wrong for, in four specific cases
Written seriously, because without it the rest is a brochure. In each of these four, one of the other models is the better answer.
- A simple store on a small budget: a freelancer. A few hundred products on an existing theme, one market, no ERP integration. A good freelancer closes that faster and cheaper, and our fixed price would buy you control you will never use.
- A steady large backlog and readiness for fixed cost: an in-house team. If eCommerce is the core of the business, there is always more work than hands, and you are willing to manage people, an in-house team wins on accumulated context. Nobody outside will know your business the way somebody sitting inside it every day does.
- A project that is not eCommerce: a software house. An internal application, a service portal, a booking system, integrations unrelated to selling. We narrowed to one domain and outside it we bring no advantage worth paying for.
- No decision maker on your side. Our model rests on written assumptions that somebody has to confirm during the project. Without that person a fixed price stops working, and you will be better off on time and materials with someone else.
Where these numbers come from
Every figure here has a source and a date. Prices and rates move faster than articles do, so treat the list below as a starting point for your own check rather than a permanent state of the world.
- Licence as a share of total replatforming cost: Elogic, an agency implementing Shopify, replatforming cost index, elogic.co, checked 12 August 2026.
- Freelancer versus agency in the PrestaShop ecosystem: a publication by the platform vendor itself, prestashop.com, checked 13 August 2026.
- Hourly rate bands and project minimums: firm declarations in the Clutch directory plus agency publications, collected 12 August 2026. These are declarations, not measured transaction rates.
- The twelve-firm review: our own study of 17 August 2026, sample drawn from the Brave Search index, offer data from visiting the sites, GitHub figures from the public API.
- Currency conversion: 4.31 PLN to 1 EUR, the rounded NBP mid rate of 17 August 2026 (4.3075), table 158/A/NBP/2026.
- Our ranges and pricing model: the pricing page.
We revisit this quarterly, because a stale comparison does more harm than good. If a line moved, tell us.
FAQ
Freelancer or agency for a first store?
With a simple catalogue, one market and a store on an existing theme, a freelancer is usually faster and cheaper, and you are not paying for coordination you do not need. An agency starts to win when campaigns, content and analytics run alongside the build, or when you want continuous care without managing several suppliers. The key safeguard is the same either way: the code in your repository and cloud accounts in your company’s name.
What is the difference between an agency and a software house?
An agency sells continuity and breadth: build, development, marketing and care from one place, usually on a retainer after launch. A software house sells software delivery: a project team, a process and a scope, most often billed as time and materials. In practice the line blurs, because some agencies grew out of implementation work and some software houses bolted on marketing services. What settles it is not the label but the answer to two questions: how does the code get made, and who carries the estimation risk.
When is hiring an in-house team better than buying a service?
When the backlog is steady and large, and eCommerce is the core of the business rather than a channel beside it. A practical test: if there has been work waiting every month for the last twelve, and the list grew faster than it shrank, fixed cost stops being a risk. We publish no salary bands, because as of August 2026 we have no source we could cite with a date. Build the figure from real listings for your roles and region, adding recruitment, equipment, holidays and ramp-up time.
What does a build cost with each of these?
Public reference points checked in August 2026: PrestaShop, as the platform vendor, puts a freelancer build at 2,000-8,000 EUR against 5,000-25,000 EUR at an agency. Software houses usually bill for time, with bands running from 40-70 USD per hour in Eastern Europe and 70-100 USD in Western Europe up to 125-175 USD for mid-senior agencies and 175-300 USD for Shopify Plus certified partners. Our own range: Engineering from about 14,000 EUR, typically 18,500 to 46,500 EUR, converted from Polish złoty at 4.31 PLN to 1 EUR (NBP, 17 August 2026). These are ranges, not offers.
How do I check whether a builder will really hand over the code?
Ask them to point at the clause that assigns rights to code written for you, with the moment of transfer and a list of exceptions, meaning open source libraries and the supplier’s pre-existing components. The second and more important test is practical: the repository should be yours from the first commit, and cloud accounts should be in your company’s name rather than the supplier’s. A reassurance without a clause and without access is not an answer.
Is Seedlight an agency?
Not in the usual sense. We are a software house narrowed to one domain: we build eCommerce and B2B platforms, we bill a fixed price resting on written assumptions instead of hours, and after launch we run maintenance and development on a monthly retainer. We do not run campaigns or media. If your need is mainly marketing around an existing store, an agency is the right choice and we are not.
Journal
Co-founder of Seedlight · eCommerce platforms, AI, SEO and GEO
Newsletter
The Journal, straight to your inbox
New articles and lessons from real builds, every now and then. No spam, unsubscribe with one click.
