How we learned that environment isolation doesn't mean configuration isolation, and why that matters for developer-focused SaaS.
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.
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:
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.
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.
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":
"I know these need reconfiguring":
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.
After deeper reflection, we found:
Environment is the runtime boundary:
Configuration is the user's design work:
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".
Once we understood this fundamental distinction, the solution became clear:
You might ask: why did it take a whole year to reconsider this request?
Honestly, the reasons were practical:
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:
If you're building a SaaS product for developers, these lessons might help:
This is the core cognitive shift. When we say "environment isolation," we often conflate two concepts:
Once you understand this distinction, you realize: environments must be isolated, but configurations should flow.
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.
Most importantly, understand how users actually work:
When you understand these points, many "unreasonable" requests start making sense.
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".