Why a services company lives inside a company builder

People who look at Oryvelon for the first time often ask a fair question. If the group has a digital and advertising agency in it, isn't Oryvelon really an agency with some side products?

It is not, and the reason is deliberate structure. Oryvelon is a digital company builder: it builds, owns and operates independent companies. It does not sell services to clients. Client work lives in WeAreMedia, the group's services company, which contracts, delivers and bills that work under its own name.

This article explains why a services company inside a company builder makes sense, why we keep it separate from Oryvelon itself, where the boundaries sit, how pricing works when group companies are also clients, and what a services business teaches a portfolio of products. If you are a founder with an agency background thinking about building products — a very common path — the structure may be useful.

What a company builder is, and is not

A company builder creates companies and operates them for the long term. Its revenue ultimately comes from the companies it owns: their subscriptions, marketplace fees, reports and product sales. See What is a digital company builder?.

An agency sells time and expertise to clients. Its revenue comes from retainers, projects and fees. Its product is delivery.

Both are legitimate businesses. They have different economics, different risks, different sales motions and different obligations to customers. Mixing them in one entity creates confusion on every one of those dimensions:

That table is why "is Oryvelon an agency?" gets a clear no. The agency work is real and valuable. It just belongs somewhere else.

Why keep services inside the group at all

If the models are so different, why not run WeAreMedia as an entirely unrelated business? Several reasons.

It already existed and works. The founders' experience in e-commerce, Shopify and performance marketing is where much of Oryvelon's thinking comes from. A services company is the natural home for that expertise when it is applied to other people's brands.

It keeps the group close to real problems. Product companies can drift into building for imagined customers. A services team spends its days inside real businesses: stores with messy catalogues, ad accounts with broken tracking, founders who need a website by next month. That exposure is hard to get any other way.

It is a capable delivery partner for group companies. New companies need websites, launch campaigns, creative and analytics setup. WeAreMedia can deliver those — as a supplier, under the same terms as any client.

It is a business in its own right. WeAreMedia has its own revenue, costs and clients. It is held to the same standard as every other company in the portfolio: it must be able to stand alone. See Designing every company so it could stand alone.

Boundary 1: the brand

Oryvelon runs a house of brands. Each company has its own name, domain and voice, with a light "An Oryvelon company" endorsement. See Naming, domains and brand architecture.

For services, that means:

• Services are sold as WeAreMedia, on wearemedia.us, with WeAreMedia proposals, contracts and invoices.
• Oryvelon's site does not offer services. If someone contacts Oryvelon asking for a website or ad campaign, we point them to WeAreMedia. The contact page says the same.
• WeAreMedia's portfolio shows client work, not Oryvelon's own companies presented as if they were clients, unless they genuinely were and the work is accurately described.

This is not about hiding the relationship. The endorsement is visible. It is about making sure a person always knows which company they are dealing with, and which company is responsible.

Boundary 2: client data

This is the boundary we are strictest about, because it is where a services company inside a product group could go most wrong.

A services team often has deep access to client systems: Shopify admin, ad accounts, analytics properties, customer email lists, sometimes sales data. It would be technically easy — and a serious breach of trust — to let that data flow into product companies. Imagine a product team quietly training a feature on patterns from agency clients' stores.

Our rules:

• Client data stays inside each client engagement. It is accessed through the client's own accounts, under the client's permission, for the client's work.
• No client data reaches any Oryvelon product. Not MerchNivo, not analytics, not AI prompts, not training or evaluation sets. MerchNivo works only with the data of stores that connect to it directly, under its own terms.
• Access is granted per engagement and removed when it ends. Named individuals, the least access needed, two-factor authentication everywhere. See Least-privilege access for small teams.
• Credentials stay out of chat and documents. Client passwords and API keys are handled through proper secrets practices.
• AI tools used in client work respect the same boundary. If WeAreMedia uses AI to draft ad copy or analyse a campaign, that work runs within WeAreMedia's own setup and the client's permissions, not inside a product company's prompts or knowledge.

These rules are an application of a group-wide principle: shared infrastructure, separate data. Services are the clearest test of it.

Boundary 3: what "learning from services" is allowed to mean

We do say that WeAreMedia's work informs the group. It is worth being precise about what that means, because it would be easy to overclaim.

What flows from services to products is general operating knowledge. For example: "store owners consistently struggle to notice when a best-selling product is about to go out of stock"; "refund spikes after a promotion are often a sizing or description problem, not a product problem"; "small brands rarely have clean UTM tagging". These are the kinds of observations any experienced operator carries in their head.

What never flows is client data or client-identifying detail. No store names, no figures, no customer lists, no screenshots of dashboards.

A useful test: could this insight have been written by an experienced e-commerce consultant from general experience, without reference to any particular client? If yes, it can inform a product. If it depends on a specific client's data, it stays in that engagement.

That is also why Noveniq, our own DTC technology accessories store, matters. When MerchNivo needs to test a feature on real store data, it has a real store the group owns and operates, with data the group is entitled to use. See Using a real store as a testbed.

Boundary 4: pricing and money between companies

When group companies use WeAreMedia, the easy mistake is to do the work "for free because we're all one group". We avoid that.

Group companies are clients. Work is scoped, estimated and invoiced like any other engagement. Terms can reflect the relationship, but they are written down.

Why it matters: - A product company that gets free marketing looks healthier than it is. When it is assessed at its 30/60/90-day checkpoint, its true costs must be visible. - A services company that gives away time looks less profitable than it is and loses capacity for paying clients. - If a company is ever sold, spun out or partnered, clean arrangements make it separable.

Capacity is a second issue. If WeAreMedia's best people are always on group work, client delivery suffers. Group work is planned into capacity like any other client, not squeezed in. See Unit economics per product.

Boundary 5: people and roles

A small group shares people, and pretending otherwise would be dishonest. The founders are involved across companies; some specialists work on both services and product work.

What we separate is roles and access, not necessarily people:

• When someone works on a client engagement, they act for WeAreMedia and use WeAreMedia's access to that client's systems.
• When the same person works on a product, they use that product's access only.
• Access is per company and per engagement, reviewed regularly.

This is less about bureaucracy than about making the right behaviour the easy behaviour. If a person's product account cannot see client systems, a mistake is much less likely.

How WeAreMedia fits the group's operating model

WeAreMedia follows the same operating standards as the rest of the portfolio, adapted to a services business:

• A source-of-truth document defining what WeAreMedia offers — web and Shopify development, social media, paid media, SEO, creative, content and AI automation — who it serves, how it earns, and what it will not do. See Source-of-truth documents.
• Its own metrics. Utilisation, client retention, margin per engagement and pipeline, rather than product metrics like activation or churn.
• Its own brand, domain, email and analytics, with separate tracking standards.
• Regular review in the group's operating cadence, alongside product companies.

Worked example: a request that arrives at the wrong door

Imagine a fashion brand emails Oryvelon: they have seen the group's work and want help rebuilding their Shopify store and running a launch campaign.

Oryvelon replies that the group does not offer services directly, and introduces WeAreMedia. From that point, the conversation, proposal, contract and invoice are all WeAreMedia's. The brand's store access is granted to named WeAreMedia team members for the duration of the project.

Six months later, the brand sees MerchNivo and wants to try it. That is a completely separate relationship. The brand signs up to MerchNivo directly and connects its store under MerchNivo's terms. MerchNivo does not inherit anything from the WeAreMedia engagement — not the brand's data, not its account history, not its contacts. If the brand wants to stop using either service, each relationship ends independently.

It is slightly more administration than a single "Oryvelon does everything" relationship. It is also exactly what a careful client would want.

What a services business teaches a product portfolio

Beyond specific observations about stores and campaigns, running a services company alongside products teaches habits that product teams tend to lack.

Selling is a skill, not a launch event. An agency has to win every client through conversation, proposals and trust. Product companies sometimes expect a good landing page to do all that work. Watching how services are actually sold — what questions prospects ask, what reassures them, what makes them hesitate — shapes how our product sites are written and how onboarding explains things. See Onboarding and trust in AI products.

Deadlines are real. Client work has launch dates that cannot move. That discipline carries into product work: a phase-zero site shipped this month beats a perfect one next quarter.

Operators care about outcomes, not features. A store owner does not want "an AI assistant". They want to know which products to reorder, why refunds jumped and whether the new campaign is working. Every product brief in the group is better for having been tested against that kind of plain question.

Reporting has to be honest. Agencies that inflate results lose clients eventually. The same attitude — show the numbers as they are, from the system that owns them — is built into MerchNivo's approach of taking figures from the store rather than from a model.

When this structure is the wrong choice

We think the structure works for us. It is not right for everyone, and it has costs.

It adds administration. Separate contracts, separate invoices, separate access and separate reporting take time. A two-person team with one product and a few clients may reasonably decide it is not worth it yet.

It can split attention. Founders involved in both services and products are always choosing where to spend the next hour. Without clear priorities and protected product time, services win by default because clients are waiting.

It can confuse the market if the boundaries are weak. If the websites, email addresses and sales conversations blur the two, the structure adds complexity without adding clarity.

It only works if the services business is healthy. A struggling agency inside a group becomes a drain on attention and capital. WeAreMedia is judged on its own results, like any other company.

If you are considering a similar setup, a short test: could you explain to a client in one sentence which company they are contracting with, who has access to their data and what happens to that data when the project ends? If the answer takes a paragraph, the boundaries need work before the structure will help.

A checklist for structuring services inside a group

For founders with an agency who are starting to build products, these are the decisions we would write down early:

1. Which legal entity and brand contracts client work, and which never does?
2. Where do inbound service requests go if they arrive at the group or a product company?
3. What client data does the services team hold, where, and for how long after an engagement ends?
4. Which product companies are explicitly forbidden from using client data, and how is that enforced in access, not just policy?
5. How are group companies charged when they use the services company?
6. What metrics judge the services business, separately from product metrics?
7. Who reviews access across companies and engagements, and how often?

Common mistakes founders make when mixing services and products

Letting the agency name become the group name. Once clients know you as an agency, every product you launch looks like a side project. Separate brands avoid that.

Treating client data as a product asset. Even if contracts technically allow some use, the trust cost is high and the practice rarely survives scrutiny.

Subsidising products with unbilled services. It hides the true cost of the product and starves the services business.

Letting services revenue decide product strategy. Services pay monthly; products take time. It is easy to keep pushing product work back because a client needs something now. Protected time and separate goals help.

Building "productised services" and calling them software. Some services can become products, and that is a legitimate path. But a product that needs a human behind every delivery is still a service, and it should be priced and staffed as one.

Summary

Oryvelon is a company builder, not an agency. Client work — web, Shopify, paid media, SEO, creative, content and AI automation — is contracted, delivered and billed by WeAreMedia, a separate services company within the group with its own brand, domain, metrics and source of truth. The boundaries are explicit: services are sold only as WeAreMedia; client data stays within each engagement and never reaches Oryvelon products; group companies that use WeAreMedia are scoped and invoiced as clients; and people's access is separated by company and engagement. What flows from services into products is general operating knowledge, never client data, and real-store testing happens on Noveniq, which the group owns. The structure keeps each business honest about its economics and gives clients the clarity they deserve.

Questions and answers

Is Oryvelon an agency?

No. Oryvelon builds, owns and operates independent companies. Agency services such as web, Shopify, paid media, SEO and creative are provided by WeAreMedia, an Oryvelon company.

Can WeAreMedia client data be used by Oryvelon products?

No. Client data belongs to each client engagement and is not shared with MerchNivo or any other Oryvelon company. What the group learns from services is general operating knowledge, not client data.

Do Oryvelon companies get WeAreMedia services for free?

No. When a group company uses WeAreMedia, the work is scoped and priced as a client engagement so that each company's costs and margins stay honest.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Marketplaces & Consumer Products

NextServices, education and digital products: building a founder-led expertise business →