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 backups and evolve the product.

The customer buys a finished service.

That promise still holds. But in conversations with large organizations, I see more and more requests that stretch 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 security events be pushed into our SIEM?"

These requests can look very different from one another.

In practice, they often tell the same story.

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

And that shift isn't only technical or regulatory.

It's cultural too.

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 isn't necessarily a spectacular feature.

But behind that sentence there may be an ISO audit, a security policy, a cybersecurity team, a central SIEM, an investigation procedure, or simply a corporate culture in which every access must be traceable.

Same thing with user management.

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.

And that would be true.

But it would miss the point.

The product we build to solve the customer's business problem is only part of what they are 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 domain knowledge, our rules, our workflows, our orchestration, our ability to solve a problem better than an alternative.

The whole product is everything that has to surround that value so a given customer can actually buy, deploy and operate the product.

SSO probably isn't our differentiation.

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 kill a deal.

They don't necessarily create the value.

They let that value enter the enterprise.

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

The most interesting case is probably the database.

Imagine payroll software.

Everyone immediately understands what kind of data is involved: salaries, contracts, personal information, the company's org structure.

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

Now imagine a large organization telling us:

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

That isn't an absurd request.

And in our case, it's 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 their question isn't necessarily:

"Are you capable of hosting my data properly?"

It may be:

"Does my data stay under my organization'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 organization:

"This data stays with us."

That isn't always a regulatory obligation.

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

Controlling where data lives is not controlling the product

Giving the customer more control does, however, introduce a boundary that has to be preserved.

The business engine stays with the vendor.

Its intellectual property stays with the vendor.

And above all, its ability to evolve the product must stay with the vendor.

Take database migrations.

Suppose we add a feature that requires a new column, an index or a schema change.

If every production release means sending a procedure to the customer's team, waiting for approval, booking a maintenance window and then manually checking that the migration was applied, the model doesn't hold.

It is already barely compatible with a SaaS that ships several times a week.

And it will be even less so tomorrow.

AI-assisted software development is already increasing our ability to produce, test and modify software. It's reasonable to expect delivery cadence to keep rising.

Building an architecture today that requires more human intervention at every customer for every change would go in exactly the opposite direction.

Very quickly, one customer applies the migration on Tuesday.

Another waits until Friday.

A third postpones it to the following month.

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

You lose one of the structural advantages of SaaS: continuously evolving a single shared product for all customers.

Yet the customer asking to keep its data in its own environment isn't necessarily asking to manage our migrations.

It wants control over where its data lives.

Not over how our product evolves.

The boundary then becomes fairly simple:

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

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

Control also shifts responsibilities

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 becomes 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"

doesn't work.

To the user, it's our SaaS that stopped working.

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

That doesn't mean administering the customer's whole infrastructure for them.

It means having the necessary signals: availability, latency, connection errors, saturation, health status, events useful for diagnosis.

That observability is indispensable operationally.

But it's also indispensable contractually.

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

Shared responsibility only truly exists if incidents can be attributed.

The customer pays for its database. Yet its SaaS may cost more.

Here an interesting paradox appears.

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

So you might think:

Since they pay for the database themselves, our SaaS should cost less.

Not necessarily.

Our cost of service isn't limited to the price of infrastructure.

Supporting databases in 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 reason about when something stops working.

Externalizing a resource can therefore lower our direct infrastructure cost while raising our cost of service.

Backups illustrate that split well.

If we commit to managing backups and guaranteeing the restore of a database located in the customer's environment, we take on an additional responsibility.

It requires technology.

Tests.

Monitoring.

Recovery procedures.

That responsibility has a cost, and it has to be priced.

Conversely, the customer may choose to manage backups themselves.

In that case, responsibilities have to be explicit: retention, backup quality, restore and the consequences of an unusable backup must sit with them.

BYO doesn't make responsibilities disappear.

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

Not every building block needs to stay on our side

Once that reasoning is in place, the database appears as the hardest case of a broader phenomenon.

One simple question helps you think about the other building blocks:

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

Take sending email.

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

Probably not.

The message is still sent at the right moment because our engine decided it should be.

Same for SMS.

Same, in some cases, for an LLM.

Our product can ship a default AI model.

But a large organization may prefer to use its own Azure OpenAI contract, its own keys, or a provider that's already approved.

If our value lies in the business workflow, the context, the rules, the data and the orchestration, changing the execution model shouldn't move the heart of the product.

That doesn't mean all providers are perfectly interchangeable.

One model can outperform another.

One email provider can have better deliverability.

But the right question remains:

is this the building block that carries the value the customer buys 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 substitutable.

If replacing it doesn't change the fundamental business value, it can become a candidate for configuration, substitution or BYO.

Not all substitutions cost the same

There's still an important difference.

An email gateway is relatively stateless.

Same for an SMS provider.

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

A database is different.

It holds the system's durable state.

You don't move from one SQL Server to another by swapping an API key.

Data has to be migrated.

Its consistency guaranteed.

Recovery planned for.

Backups handled.

Sometimes replication.

Substitutability isn't binary, then.

It's a gradient.

A building block can be non-differentiating for our product while being extremely important operationally.

That's particularly true of the database.

Don't turn the whole product into a catalogue

From there, the temptation could be to build every possibility.

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 isn't:

"What can we technically support?"

But:

"What do we need to support for the customers we've chosen to serve?"

If 90% of the large organizations 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 the one most likely to maximize our ability to sell into the market we target.

Conversely, supporting a database or a cloud that nobody in our segment asks for doesn't necessarily add value.

Breadth of technology support isn't a goal in itself.

It has to follow commercial positioning.

The whole product isn't a universal checklist of the "perfect enterprise SaaS".

It's the concrete answer to the question:

what do we need to add around our core product so the customers we've chosen to serve can actually buy it?

Understanding the need behind the request

That doesn't mean every customer request should be answered literally.

When a large organization says:

I want my data in my Azure.

The right answer isn't 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 desire for reversibility?

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

The solution may 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, you really will have to host the database in the customer's tenant.

Understanding why the customer is asking for control lets you offer the right level of control.

But that doesn't change the starting observation.

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

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

This isn't an infrastructure strategy

That's probably the most important point.

At first glance, this 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?

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 chooses the market.

And the whole product makes the core product compatible with the reality of that market.

If the large organizations we want to serve have a strong culture of controlling their data, their identities, their keys and their vendors, 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 remains simpler to operate, more homogeneous and easier to evolve.

BYO becomes an option when the market justifies it.

And its scope should be decided the same way.

We don't need to make every component interchangeable.

We don't need to support every technology.

Above all, we need to identify the constraints that genuinely prevent the customers we've chosen to serve from buying our product.

Then decide which of them we want to remove.

So BYO isn't first an infrastructure strategy. It's a whole product and commercial positioning decision.

The technical consequence may be a more modular SaaS.

The engine stays under our control.

Some data stays with the customer.

Some providers become substitutable.

Some responsibilities change hands.

But that isn't the starting point.

The starting point is still the market.

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