English

saas
environment
configuration

Why I said "no" for a year: rethinking dev-to-prod environment promotion

How we learned that environment isolation doesn't mean configuration isolation, and why that matters for developer-focused SaaS.

Yijun

Developer

7/10/20253 min read

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

This week, we finally shipped a feature that users had been asking for over a year: converting a development tenant to a production tenant.

As the engineer who built this feature, I want to share the story behind it. This isn't just about building a feature. It's about how we came to rethink the seemingly simple concept of "environment management". If you're building a SaaS product for developers, I hope our journey offers some insights.

"This goes against best practices"

A year ago, when the first user asked for this feature, my immediate response was: "No, this goes against best practices."

At Logto, our dev tenant has a clear purpose:

Test new features during internal development
Debug and iterate freely without affecting production
Access all paid features for free to enable testing

This is standard environment isolation. As engineers, we know the dangers of mixing development and production environments.

So when a user said "I want to convert my dev tenant directly to prod," my inner voice screamed: "Do you know how dangerous that is?"

More importantly, we had more urgent features to build. This seemingly "anti-pattern" request naturally sank to the bottom of our backlog.

More and more "special cases"

But over time, similar requests kept coming.

Cloud users were saying: "Our RBAC model took a month to get right. Is there a way to export the configuration?"

Open source users discussing in our Discord: "Can you provide configuration templates? We have to reconfigure everything for each new deployment."

What really got us was discovering some users were running production workloads on dev tenants, accepting all the limitations rather than reconfiguring.

When this feedback shifted from "occasional" to "frequent," we realized it was time to revisit this shelved request.

Understanding the real pain point

During our monthly user feedback review, this request came up again. This time, it had evolved from "someone mentioned it" to "high-frequency demand".

After careful analysis, we discovered an interesting pattern. User requests fell into two categories:

"I want to migrate these":

"Complex RBAC permission models"
"All Application and API Resource definitions"
"Carefully designed Organization template"

"I know these need reconfiguring":

"OAuth Client IDs (dev uses test accounts)"
"SSO endpoints (pointing to different environments)"
"Webhook URLs (different servers for dev and prod)"

Wait, users actually know exactly what should migrate and what shouldn't?

This discovery led us to a key realization: We had been conflating "environment" and "configuration" all along.

Environment ≠ configuration

After deeper reflection, we found:

Environment is the runtime boundary:

Data isolation (test users vs real users)
Resource limits (request limits in dev)
External connections (different third-party services)

Configuration is the user's design work:

Permission models are their business logic
Application structure is their system architecture
These should be consistent across any environment

What users spend hours designing and debugging in dev environments are these "configurations". Asking them to rebuild these designs in each environment is like asking programmers to rewrite code for each deployment.

What truly needs environment-specific management are those "connection parameters".

From "no" to "yes, but do it right"

Once we understood this fundamental distinction, the solution became clear:

Allow dev to prod conversion - preserve users' design work
Smart detection of environment dependencies - remind users to update necessary parameters
Maintain data isolation - migrate configuration only, not data

Why it took a year

You might ask: why did it take a whole year to reconsider this request?

Honestly, the reasons were practical:

Priority sorting - at a startup, there's always something more urgent
Cognitive bias - we genuinely believed this was an "anti-pattern"
Weak signal - initially just scattered requests, easy to overlook

Only when this request became increasingly frequent in user feedback did we realize this wasn't a "special need" of individual users, but a common pain point.

Sometimes product teams need enough signal accumulation to recognize their blind spots.

The version we shipped is relatively simple, supporting only basic dev to prod conversion. Because:

Solve the most urgent pain first - stop users from repeating configuration work
Mature solutions need more validation - advanced features like configuration versioning and smart sync are still being explored

Insights for product design

If you're building a SaaS product for developers, these lessons might help:

Distinguish "environment" from "configuration"

This is the core cognitive shift. When we say "environment isolation," we often conflate two concepts:

Environment: runtime isolation (data, resources, limits)
- Test data vs production data
- API rate limits
- Strictness of error handling
Configuration: user settings and rules
- Business logic (permission models, workflows)
- System architecture (application structure, API design)
- These are users' intellectual work

Once you understand this distinction, you realize: environments must be isolated, but configurations should flow.

Support multiple modes, not a single path

Different teams work differently:

Team type	Working style	Features needed	Focus
Progressive teams	Explore in dev, refine gradually, then migrate to prod	Dev → Prod upgrade path	Preserve design work, update environment parameters
Strict management teams	Dev strictly for internal development, Prod configured separately	Clear environment boundaries	Prevent mistakes, audit trails
DevOps teams	Configuration as code, managed through CI/CD	Configuration import/export	Version control, automated deployment

Good products should support all these modes, not force users into one.

Design features based on user workflows

Most importantly, understand how users actually work:

They're not "configuring a system," they're "designing a system"
Environments aren't the goal, getting to production safely and quickly is
Repetitive work is the biggest productivity killer

When you understand these points, many "unreasonable" requests start making sense.

Final thoughts

From "absolutely not" to "actually, we can do this," building this feature changed how I think about product design.

Good products don't educate users on the "correct" way to do things. They understand real user needs and find balance between technical principles and user experience.

Sometimes, saying "no" for a year is how you find a better "yes".

"This goes against best practices"#

More and more "special cases"#

Understanding the real pain point#

Environment ≠ configuration#

From "no" to "yes, but do it right"#

Why it took a year#

Insights for product design#

Distinguish "environment" from "configuration"#

Support multiple modes, not a single path#

Design features based on user workflows#

Final thoughts#

"This goes against best practices"#

More and more "special cases"#

Understanding the real pain point#

Environment ≠ configuration#

From "no" to "yes, but do it right"#

Why it took a year#

Insights for product design#

Distinguish "environment" from "configuration"#

Support multiple modes, not a single path#

Design features based on user workflows#

Final thoughts#

"This goes against best practices"

More and more "special cases"

Understanding the real pain point

Environment ≠ configuration

From "no" to "yes, but do it right"

Why it took a year

Insights for product design

Distinguish "environment" from "configuration"

Support multiple modes, not a single path

Design features based on user workflows

Final thoughts

"This goes against best practices"

More and more "special cases"

Understanding the real pain point

Environment ≠ configuration

From "no" to "yes, but do it right"

Why it took a year

Insights for product design

Distinguish "environment" from "configuration"

Support multiple modes, not a single path

Design features based on user workflows

Final thoughts