Your eCommerce team after launch: who you actually need

Launching a platform does not end the project, it starts it. The first question is usually "who do we hire now", and that is the wrong question. After launch you need four functions covered: technical maintenance with a defined on-call rota, an owner for product data, customer service with access to order data, and one person accountable for conversion. These are functions, not job titles. At 50 orders a day, two people and a technical partner can cover all of them. At 500, each one fills somebody's day.

Functions, not job titles: the four roles that keep a platform standing

The difference between a function and a job is practical rather than semantic. A function is a set of decisions somebody makes on their own and answers for. A job is how you pay a person. One person can hold three functions if they have the time and the skills. What no function survives is being shared by two people, because then it belongs to neither.

Technical maintenance and on-call

Something always breaks after launch: an integration stops responding, a payment never returns to the store, an update quietly removes the button from the cart. The question is not whether it happens but who picks up the phone and how fast. On-call has to be planned before the first outage, because improvising during one is where the cost really lands.

It is worth borrowing from teams that run large systems for a living. Google's Site Reliability Engineering book sets hard limits: a maximum of two incidents per 12-hour on-call shift, and no more than half of an engineer's time spent on purely operational work. The logic carries over. An on-call rota that eats the whole week has stopped being a rota and become firefighting.

• Who answers: a named person and a named backup, not "someone from the team".
• How fast: separate response times for an outage that blocks sales and for a defect that can wait until Tuesday.
• With what: production access, plus the ability to ship a fix and roll it back without waiting for anyone's approval.
• What follows: a short note after the incident, so the same root cause does not come back every month.

The same questions decide how the store behaves during a sales peak. Which layer gives out first, and in what order, we broke down in our piece on what breaks at 10x traffic.

An owner for product data

This is the role most often skipped and the most expensive to skip. Somebody has to answer for complete attributes, valid EAN codes, current prices, consistent variants and descriptions in every language you sell in. Without an owner, the failures stack up quietly: on-site search, filters, channel feeds, recommendations and the way AI systems summarize your product.

Catalog quality now carries compliance weight too. The EU General Product Safety Regulation has applied since 13 December 2024 and covers online sales, so manufacturer details, product identification and warnings are no longer a matter of diligence but of compliance. Somebody has to keep them current with every new delivery.

The product data owner does not have to be a separate hire on day one. It does have to be a name. How to handle this across a wide catalog without hiring three copywriters, we covered in our piece on AI product descriptions done right.

Customer service that can see the order

Most tickets after launch are about delivery status, returns and address changes. What matters is not how many agents you have but whether they see what the system sees: payment status, tracking number, the history of changes on the order. Support without data access creates a second queue of work, because every ticket escalates to someone who does have access.

Repetitive questions can be automated away, but only once the process is written down. Automating an undocumented process just makes the mess faster. How we structure this in practice we showed alongside AI handling of order status questions.

One person accountable for conversion

Conversion is a role, not a recurring agenda item. If "marketing and IT" own the number, nobody owns it: marketing points at traffic quality, IT points at performance, and the cart keeps leaking in the same place. This person does not need to write code. They need to read a funnel, form hypotheses and hold the mandate to stop a release that damages checkout.

The same role has to watch whether the storefront still meets accessibility requirements after each round of changes. The European Accessibility Act has applied since 28 June 2025 and covers eCommerce, although microenterprises providing services are exempt from those obligations. One well-run checkout review usually shows how much money is sitting on the table: the points we check are listed in our abandoned cart audit.

Scale changes the line-up more than the industry does

A universal list of job titles does not work, because the same function means a completely different workload at a different scale. Orders per day and number of sales channels are a more useful starting point. The table below is where we start the conversation with a client after go-live, not market research: treat it as an order of magnitude to correct with your own numbers.

A starting point, not labor market research. The order volumes are indicative: with a complex, high-value product these thresholds move down sharply.

Functions do not appear out of nowhere as you grow. They peel away from the people who used to do everything at once. At 50 orders a day the owner watches conversion personally and fixes descriptions personally. At 200 there is no time for either, yet the work usually stays where it was, because that is how it has always been done. That is exactly where margin bleeds most quietly.

Roles that depend on your sales model

The four functions above apply to every store. What comes next depends on how you sell, not on how big your team is.

B2B: an owner for the ordering process, not a store administrator

In B2B the value sits in customer-specific price lists, credit limits, approvals and sales documents. All of that lives in the ERP, so the critical post-launch role is someone who understands the ordering process on both sides and can settle where the source of truth is. Hiring a developer instead of a process owner here produces an integration that does exactly what somebody once said in one meeting.

Regulatory deadlines add their own rhythm. Poland's mandatory e-invoicing system went live in stages during 2026, from 1 February for the largest taxpayers and from 1 April for everyone else, and comparable mandates are landing in other markets. A software vendor will ship the feature but will not own your process, so somebody on your side has to track those dates. What a well-built data exchange looks like we took apart in our piece on B2B store and ERP integration.

Marketplace: a channel skill you usually buy

Selling on Amazon, eBay or Kaufland is a separate profession: different listing rules, different advertising, different reasons for account suspensions. With one or two channels it rarely fills a full-time job, and a mistake costs faster than it would in your own store. That is why buying the skill often makes more sense, for example through marketplace account management run by our sister agency Amazonway, while keeping one person in house who owns assortment, pricing and margin across channels.

International expansion: language is the smallest problem

A new market adds obligations, not just translations. Local payment methods, returns, support in the language, delivery expectations and local compliance are work that does not stop once the language version is live. The role most often missing here is not a translator but a market owner: someone accountable for the result of one country, with the standing to say the second one has to wait.

What to buy and what to keep in house

The line does not run between "technical" and "commercial". It runs along two questions: how often do you need this competence, and what does it cost to keep it sharp. A skill used once a quarter goes stale faster than you get to use it.

• Usually worth buying: infrastructure and security, out-of-hours cover, performance work, integration delivery, deeper platform development, rare channel specializations.
• Usually worth keeping: knowledge of assortment and margin, the customer relationship, pricing decisions, development priorities and ownership of your data.
• Almost never worth splitting: accountability for conversion and for product data. Shared accountability for a number means no accountability at all.

When an in-house team is simply better

Against our own commercial interest: there are situations where an internal team beats any external partner, including us.

• High change frequency: when you ship to production several times a week, the cost of coordinating with an external team eats the saving.
• An unusual domain: made-to-measure products, configurators, discount rules that lose half their meaning the moment you write them into a document.
• Volume that fills a job: if the work is continuous and predictable, a salary is cheaper than buying the same hours.
• Platform as an advantage, not a cost: when the store is the product rather than an operational tool, owning the team has strategic value.

The commercial model matters too, because work is planned differently under a fixed scope than under hourly billing. We put both approaches side by side in our piece on fixed scope versus hourly.

How to avoid getting locked into one supplier

Vendor lock-in rarely comes from outsourcing as such. It comes from missing access and missing documentation. The test is blunt: if your technical partner disappeared tomorrow, how many days would another team need to take over the system? If the answer is "no idea", you have a problem no matter how well the relationship is going.

• Code: the repository belongs to you and the partner has access to it, not the other way around.
• Access: cloud accounts, domain, payment gateway and analytics registered to your company, with your own administrator.
• Documentation: architecture, integration notes and incident runbooks maintained alongside the code, not written at the exit interview.
• Technology: standard, well-known tooling rather than a supplier's private framework that nobody else can read.
• Contract: a written exit, a handover period and a knowledge transfer obligation, agreed at the start while everyone still likes each other.

That is also the honest context for what we do ourselves. Seedlight builds platforms on the BEAM framework and stays after launch in Maintenance and Growth, but the point of that stage is to take on-call and upkeep off your plate, not to take control of your system. If a partner will not hand over access or keeps documentation to themselves, that is not a working style. It is a warning sign, whoever the partner happens to be.

Four hiring mistakes that surface within months

The mistakes companies make after launch are remarkably consistent. They all trace back to the same thing: hiring against a tool, or against a feeling of being short-staffed, instead of against a decision that has no owner.

• A developer instead of a process owner: the company hires an engineer because "things need fixing", then nobody can tell them what or why. The result is an expensive person executing other people's requests without priorities.
• No owner for product data: the catalog belongs to nobody, so it degrades month by month, and the cost only shows up in on-site search and in channel feeds.
• Blurred accountability for conversion: everyone owns it, so no one does, and nobody has the mandate to stop a release that breaks the cart.
• A team built ahead of demand: roles created against a sales plan that has not happened yet, instead of against work that already recurs every week.

The first one costs the most, because it looks the most reasonable. An in-house developer without a process owner and without a backlog spends the first quarter learning the system and the second on tasks a partner would have closed in days. The order should be reversed: name the decisions and processes that have no owner, measure how many hours a week they actually take, and only then decide whether that is a hire or a line in a retainer.

What to do in the first month after launch

Instead of a hiring plan for the year, run an exercise that fits on one page.

• List the functions: maintenance and on-call, product data, customer service, conversion, integrations, extra channels.
• Assign names: one name per function, plus a backup for on-call.
• Set response times: separately for an outage that blocks sales and for a defect that can wait.
• Count the hours: for one month, log the real time each function takes before converting it into headcount.
• Decide what you buy: based on those hours, not on a hunch.