How We Made a B2B SaaS Product Configurable Without Code Changes

When we started building a pharma procurement B2B SaaS product, one thing became clear fairly quickly:

We didn't want the client to depend on us for every operational change.

Changing a company name, updating branding, modifying verification requirements, creating a new plan, disabling signups, putting the application into maintenance mode — these shouldn't necessarily require a developer to change code, test it, and deploy a new version.

So instead of treating the admin panel as a place to simply view data, we made it a control layer for the application.

The goal was simple:

The code should define what the application can do. The admin panel should control how the application operates.

The problem with hardcoded configuration

A common way to build an application is to put many of these decisions directly into the code.

For example:

• Is registration enabled? Put a boolean somewhere.
• What company name should appear in the header? Put it in the frontend.
• What verification documents are required? Define them in code.
• What plans are available? Create them in a database migration.
• What SEO title should the homepage use? Hardcode it.
• Is the application under maintenance? Change an environment variable.

None of these approaches are necessarily wrong when you're building the first version.

The problem appears later.

Every small business decision becomes an engineering task.

A marketing person wants to change the title.

A product manager wants to introduce a new plan.

Operations wants to temporarily disable registrations.

Compliance wants to change a verification requirement.

Suddenly, all of these become:

Create ticket → developer changes code → test → deploy → verify.

That isn't a good operational model for a SaaS product.

We treated configuration as a first-class part of the product

Instead of asking, "What settings should we put in the admin panel?", we asked a different question:

"What decisions might the business need to make without changing the underlying application?"

That changed how we designed the system.

The application still has hard boundaries defined by code. We don't allow administrators to arbitrarily change business logic.

But within those boundaries, configuration lives outside the codebase.

This created a clear separation:

Application Code
    ↓
Defines capabilities and business rules

Admin Configuration
    ↓
Controls operational behaviour

Database
    ↓
Stores the current configuration

The application reads the configuration and behaves accordingly.

That sounds straightforward, but it has a significant effect on how the product is operated.

What can now be controlled from the admin panel?

We gradually moved a large portion of the operational configuration into the admin system.

Basic application details

Administrators can update basic information used throughout the application without touching frontend code.

This includes things such as company information, application details and other global settings.

A change that previously required a deployment can now be made directly where the people operating the product already work.

Branding

Branding is another area that tends to get unnecessarily tied to code.

Instead, we made relevant branding configuration-driven.

This allows administrators to update things such as application branding and other visual identity settings without rebuilding the application for every minor change.

The frontend is responsible for rendering the branding.

The admin panel is responsible for defining what that branding should be.

Plans and pricing

Plans are particularly important for a SaaS product because they are expected to change.

We didn't want every new plan or pricing adjustment to require a code change.

Instead, plans can be managed through the administration layer.

That means the business can introduce, update or disable plans without modifying the underlying application.

The application understands the concept of plans.

The administrator controls the actual plans being offered.

That's the distinction we wanted.

Verification requirements

This was especially important for a pharma procurement platform.

Verification requirements aren't necessarily permanent.

The business may decide that a particular type of account needs additional information or documentation.

Rather than burying these requirements inside application logic, we made the requirements configurable.

The application knows how to process verification.

The administrator determines what information or requirements are currently applicable.

This gives the business more flexibility without weakening the underlying validation and security rules implemented in code.

Signup and access controls

Operational controls are another area where configuration becomes useful.

For example, administrators can control whether new users are allowed to sign up.

There are situations where a business may temporarily want to stop new registrations.

That shouldn't require a developer to deploy a new build.

The same principle applies to maintenance mode.

If the team needs to temporarily take the application into maintenance mode, the appropriate control should be available to the people responsible for operating the platform.

SEO without developer involvement

SEO configuration is another obvious example.

SEO requirements can change frequently.

Page titles, descriptions, indexing behaviour and other metadata shouldn't have to be hardcoded into the application whenever possible.

We therefore exposed the appropriate SEO configuration through the admin system.

The code handles the technical implementation.

The admin controls the content.

This makes the marketing and product teams less dependent on engineering for routine changes.

But we didn't make everything configurable

This is probably the most important part.

There is a temptation when building a configurable SaaS product to put absolutely everything into the admin panel.

We deliberately didn't do that.

Configuration should not become a backdoor for changing application logic.

For example, security rules, complex business workflows and core data relationships still belong in the application architecture.

The admin panel should control configuration, not replace engineering.

Our mental model became:

If it is a business decision that is expected to change, consider configuration.

If it is a fundamental rule that protects how the system works, keep it in code.

That distinction keeps the system flexible without turning it into an unmaintainable collection of switches.

The real benefit

The biggest benefit isn't actually the admin panel itself.

It's the reduction in dependency between operations and engineering.

Before this approach, a simple operational change could mean waiting for a developer and a deployment.

Now, many of those changes can happen immediately.

That gives the business more control, but it also gives developers more time to work on things that actually require engineering.

Instead of spending time changing configuration, developers can focus on improving the product, fixing real bugs and building new capabilities.

What we learned

Building a configurable SaaS product requires thinking about the product beyond its first release.

It's easy to hardcode something because you already know the value today.

But if you can reasonably predict that the value will change tomorrow, it may be worth designing it as configuration from the beginning.

We didn't build the admin panel simply because "every SaaS needs an admin panel."

We built it because the people operating the product should have control over the parts of the product that are actually operational decisions.

The end result is a system where many changes can happen without touching the codebase at all.

And that's the part we care about most:

The business can operate the application without needing engineering for every small decision.

The code provides the foundation.

The admin panel provides the control.