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

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:

1. Allow dev to prod conversion - preserve users' design work
2. Smart detection of environment dependencies - remind users to update necessary parameters
3. 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:

1. Solve the most urgent pain first - stop users from repeating configuration work
2. 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:

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:

1. They're not "configuring a system," they're "designing a system"
2. Environments aren't the goal, getting to production safely and quickly is
3. 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".