For a long time, the SaaS promise was fairly simple.

You use the software. We take care of the rest.

We run the application, choose the infrastructure, host the database, handle the backups and keep the product evolving.

The customer buys a finished service.

That promise still holds. But in conversations with large groups, I see more and more requests that are shifting it.

"Can the data stay in our Azure environment?"

"Can we use our own SQL Server?"

"Can we use our own encryption keys?"

"Can we manage users and their permissions from our IAM?"

"Can we use our own LLM contract and provider?"

"Can we use our own email or SMS provider?"

"Can we send security events to our SIEM?"

These requests can look very different from one another.

In practice, they are often saying the same thing.

Large groups want to keep buying SaaS, but they want control back over certain building blocks.

And that shift is not only technical or regulatory.

It is also cultural.

When the customer's culture becomes a component of the product

Take a very simple request:

"I want to know who logs into the application."

Technically, that is not necessarily a spectacular feature.

But behind that sentence you may find an ISO audit, a security policy, a cybersecurity team, a central SIEM, an investigation procedure, or simply a company culture where every access has to be traceable.

User management works the same way.

The customer may not want to administer permissions inside every SaaS it buys. It wants identities, groups and sometimes permissions to be driven from its own IAM.

You could look at some of these requests and conclude that they create no business value at all.

And you would be right.

But you would be missing the point.

The product we build to solve the customer's business problem is only part of what it is actually buying.

This is where the distinction between core product and whole product becomes useful.

The core product holds what really makes our value: our knowledge of the domain, our rules, our workflows, our orchestration, our ability to solve a problem better than the alternative.

The whole product is everything that has to sit around that value for a given customer to actually buy, deploy and run the product.

SSO is probably not our differentiator.

Neither is the SIEM.

Neither is data residency.

Neither is the ability to use the customer's IAM.

But the absence of any one of them can be enough to block a deal.

They do not necessarily create the value.

They let that value get into the company.

"I want to use your SaaS, but keep my database on my side"

The most interesting case is probably the database.

Picture a payroll application.

Everyone immediately understands what kind of data is involved: salaries, contracts, personal information, the shape of the organisation.

In the classic SaaS model, the vendor runs the software and the database that goes with it.

Now picture a large group telling us:

We want your application, but the data has to stay in a SQL Server or Azure SQL database sitting in our own Azure environment.

That is not an absurd request.

And in our case it is even consistent with the market we want to serve: the vast majority of the customers we target already live inside the Microsoft ecosystem.

The SaaS engine would still be run by the vendor.

But its database could be hosted in the customer's environment.

Why would a customer ask for that when we know perfectly well how to host a database?

Because its question is not necessarily:

"Are you able to host my data properly?"

It may be:

"Does my data stay under my organisation's control?"

Sometimes the customer wants the resource to sit in its own Azure subscription.

It wants to apply its network rules.

Its security policies.

Its keys.

Its inventory mechanisms.

Its controls.

Its internal standards.

And above all to be able to tell its CISO, its auditor or its organisation:

"This data stays with us."

It is not always a regulatory obligation.

It can simply be a condition for the company to accept the product at all.

Controlling where the data sits is not controlling the product

Giving the customer more control does introduce a line that has to be held, though.

The business engine stays with the vendor.

Its intellectual property stays with the vendor.

And above all, the ability to keep the product evolving has to stay with the vendor.

Take database migrations.

Say we add a feature that needs a new column, an index or a schema change.

If every release means sending a procedure to the customer's team, waiting for approval, booking a maintenance window and then checking by hand that the migration was applied, the model does not hold.

It is already hard to reconcile with a SaaS that ships several times a week.

And it will be harder still tomorrow.

AI-assisted software development is already increasing our ability to produce, test and change software. It is reasonable to expect the delivery pace to keep rising.

Building an architecture today that demands more human intervention at every customer for every change would run exactly the other way.

Very quickly, one customer applies the migration on Tuesday.

Another waits until Friday.

A third pushes it to next month.

You end up with several versions of the engine, several states of the schema, and complexity that grows with every release.

You end up losing one of the structural advantages of SaaS: evolving one shared product continuously for every customer.

Yet the customer asking to keep its data in its own environment is not necessarily asking to manage our migrations.

It wants control over where its data lives.

Not over how our product evolves.

The line then becomes fairly simple:

the customer controls where its data lives; the vendor controls how the product evolves.

BYO-Database is therefore only genuinely compatible with SaaS if migrations can stay automated and driven by the vendor, inside a security framework the customer accepts.

Control moves the responsibilities too

Moving the database into the customer's environment has another consequence.

Part of the infrastructure our service depends on is no longer entirely under our control.

And the day the application goes down, that distinction gets very concrete.

Is it our engine?

The customer's SQL Server database?

Azure?

A network rule that was just changed?

A certificate?

An IAM configuration?

Connection saturation?

A quota?

A latency problem?

Saying:

"The database is on the customer's side, not our problem"

does not work.

For the user, it is our SaaS that has stopped working.

So BYO comes with a requirement I see as non-negotiable: we have to be able to monitor the database and its connectivity well enough to understand where an incident came from.

That does not mean administering the whole infrastructure in the customer's place.

It means having the signals we need: availability, latency, connection errors, saturation, health status, events that help with diagnosis.

That observability is essential operationally.

But it is just as essential contractually.

If our SLA excludes outages caused by a resource under the customer's control, we have to be able to establish objectively that an incident did come from that resource.

Shared responsibility only really exists if you can attribute incidents.

The customer pays for its database. Its SaaS can still cost more.

This is where an interesting paradox shows up.

The customer may pay directly for its Azure SQL or its SQL Server.

So you might think:

Since it pays for the database itself, our SaaS should cost less.

Not necessarily.

Our cost to serve is not limited to the price of the infrastructure.

Supporting databases inside customer environments can force us to handle more variants.

Different versions.

Different network constraints.

Replication mechanisms.

Backups.

Snapshots.

Restores.

Permissions.

Monitoring.

Specific configurations.

And above all more scenarios to work through when something stops working.

Moving a resource outside can therefore cut our direct infrastructure cost while raising our cost to serve.

Backups are a good illustration of how the split works.

If we commit to handling backups and guaranteeing the restore of a database sitting in the customer's environment, we take on an extra responsibility.

That takes technology.

Tests.

Monitoring.

Recovery procedures.

So that responsibility has a cost, and it has to be charged.

Conversely, the customer may choose to handle its own backups.

In that case the responsibilities have to be spelled out: retention, backup quality, restore, and the consequences of an unusable backup all have to fall to the customer.

BYO does not make responsibilities disappear.

It simply forces you to say much more precisely who carries which.

Not every building block has to stay with us

Once the reasoning is laid out, the database looks like the hardest case of a much wider phenomenon.

One simple question helps with the other building blocks:

if I replace this provider with another one, does the value of my service change?

Take sending emails.

If we swap our email provider for the customer's, does the business value of our product change?

Probably not.

The message still goes out at the right moment because our engine decided it should.

Same for an SMS.

Same, in some cases, for an LLM.

Our product can ship a default AI model.

But a large group may prefer to use its own Azure OpenAI contract, its own keys, or a provider it has already approved.

If our value sits in the business workflow, the context, the rules, the data and the orchestration, changing which model does the work should not move the heart of the product.

That does not mean every provider is perfectly interchangeable.

One model can perform better than another.

One email provider can have better deliverability.

But the right question remains:

is this the building block that carries the value the customer is buying our product for?

If replacing a provider destroys the value of the service, it probably sits too close to our core product to be freely swappable.

If replacing it does not change the fundamental business value, it can become a candidate for configuration, for swapping, or for BYO.

Not every swap costs the same

There is still an important difference.

An email gateway is relatively stateless.

Same for an SMS provider.

And an LLM can be too, as long as durable memory, business context and decisions stay inside our product.

A database is another matter.

It holds the durable state of the system.

You do not move from one SQL Server to another by changing an API key.

You have to migrate the data.

Guarantee its consistency.

Plan for recovery.

Handle backups.

Sometimes replication.

So swappability is not binary.

It is a gradient.

A building block can be entirely non-differentiating for our product and still be extremely important operationally.

That is especially true of the database.

Don't turn the whole product into a catalogue

From there, the temptation would be to build every possible option.

Azure.

AWS.

GCP.

SQL Server.

PostgreSQL.

Oracle.

Five AI providers.

Three email providers.

Four SMS gateways.

That would probably be a mistake.

The right question is not:

"What can we technically support?"

But:

"What do we have to support for the customers we have chosen to serve?"

If 90% of the large groups we target are already built around Microsoft and Azure, starting with Azure and SQL Server makes sense.

Not because SQL Server would be intrinsically better than another database.

But because that configuration is probably the one that maximises our ability to sell into the market we target.

Conversely, supporting a database or a cloud that nobody in our segment asks for does not necessarily add value.

How wide our technology support goes is not a goal in itself.

It has to follow the commercial positioning.

The whole product is not a universal checklist for "the perfect enterprise SaaS".

It is the concrete answer to the question:

what has to be added around our core product for the customers we have chosen to serve to actually be able to buy it?

Understanding the need behind the request

None of this means you should answer every customer request literally.

When a large group says:

I want my data in my Azure.

The right answer is not immediately:

Fine, let's build BYO-Database.

You have to understand why.

Is it a regulatory obligation?

A residency requirement?

A CISO policy?

A need to control the keys?

An audit constraint?

A wish to be able to exit?

Or simply a culture in which sensitive data has to stay under the company's direct control?

The solution can depend on that answer.

A dedicated region can sometimes be enough.

Customer Managed Keys can sometimes be enough.

A single-tenant environment can sometimes be enough.

In other cases, the database really will have to be hosted in the customer's tenant.

Understanding why a customer asks for control lets you offer the right level of control.

But it does not change the starting observation.

If you decide to sell to large groups, their governance culture is part of the market.

You cannot want their volumes, their budgets and their contracts while treating their audit, security or control constraints as annoying details.

This is not an infrastructure strategy

This is probably the most important point.

At first glance, the whole subject looks like an architecture discussion.

Where do we host SQL Server?

How do we connect the engine?

How do we migrate the schema?

How do we monitor it?

How do we handle backups?

Those are real questions.

But they come after another one:

which customers have we decided to serve?

The core product creates the value.

Positioning picks the market.

And the whole product makes the core product fit the reality of that market.

If the large groups we want to serve have a strong culture of controlling their data, their identities, their keys and their providers, then some of those capabilities probably have to become a component of our whole product.

Not because BYO would be better than fully managed.

Fully managed should probably stay the default choice.

It is still simpler to run, more homogeneous and easier to keep evolving.

BYO becomes an option when the market justifies it.

And its scope has to be decided the same way.

We do not need to make every component interchangeable.

We do not need to support every technology.

What we mainly need is to identify the constraints that genuinely stop the customers we have chosen to serve from buying our product.

Then decide which of them we want to lift.

BYO is therefore not first of all an infrastructure strategy. It is a whole product and commercial positioning decision.

The technical consequence may well be a more modular SaaS.

The engine stays under our control.

Some data stays with the customer.

Some providers become swappable.

Some responsibilities change hands.

But that is not the starting point.

The starting point is still the market.

We are not trying to give every possible choice to every customer. We are trying to build the whole product that lets our core product be bought by the customers we have decided to serve.