Zenmanage

When I decided to build official SDKs for Zenmanage across 14 languages and platforms, I knew I couldn't do it the slow way. Here's the process I landed on, and the unexpected tool that made me actually trust each one.

The Problem with Shipping SDKs Solo

SDKs are deceptively hard. Every language has its own idioms, package registries, async patterns, and testing conventions. Writing Python feels nothing like writing Swift, which feels nothing like Kotlin. If I did each one from scratch the traditional way, I'd spend weeks context-switching before writing a single meaningful line.

I wanted a repeatable process that could produce high-quality, idiomatic code in each language, fast. That meant leaning on AI.

The AI-Assisted SDK Development Process

Each SDK follows the same structure:

1. Prompt for language-specific best practices. Before writing code, I explicitly prompt the AI to follow the current language's best practices, idioms, and architecture patterns.

2. Enforce quality gates early. I make sure code coverage, code style, and static analysis all pass as part of the development loop, not just at the end.

3. Validate package ecosystem support. I ensure each SDK uses and supports the appropriate package libraries for that language and runtime.

4. Mimic proven SDK behavior. I mirror the core functionality and behavior of existing Zenmanage SDKs so the developer experience stays consistent across languages.

5. Write comprehensive unit tests at all layers. I require unit test coverage across transport, client, evaluation, caching, and error-handling layers of the SDK.

6. Iterate with AI, then review with intent. AI accelerates implementation, but I still run a focused human review pass for correctness, security-sensitive paths, and language feel.

The Fully Integrated Test Harness: The Part That Actually Builds Confidence

Code coverage tells you your tests pass. It doesn't tell you your SDK works in a real project.

For each SDK, I build a test harness, a minimal but runnable project in that language's ecosystem that connects to a live Zenmanage environment. It:

• Initializes the SDK against a real account

• Evaluates a set of flags with different contexts

• Displays the results in a simple UI or CLI output

On top of that, every SDK has to pass the same shared live test project with 30+ scenarios (defaults, target rules, rollouts, and scheduled releases), so I know they're all being validated against the same real-world checklist.

This sounds simple, but it surfaces issues that tests never catch:

• Auth and transport bugs: the HTTP client behaving differently than mocked

• Serialization edge cases: flag values that parse fine in tests but break on real API responses

• Initialization race conditions: especially in async SDKs where the client isn't ready before the first evaluation

• Package distribution issues: the published package behaving differently than the local dev version

The test harness is the final gate before I call an SDK ready to ship. If I can run it against my account and consistently get the expected flag results, it passes. In practice, the Python harness surfaced two issues that full unit test coverage missed. I fixed the SDK and added test coverage for both cases, so future iterations stay protected against the same regressions.

What This Looks Like In Practice

Right now I'm prioritizing the most widely used, highest-impact upcoming languages first: Python, .NET, Java, and Go. Python releases this week. The rollout is still aggressive, but the plan is to ship all SDKs incrementally over the summer. AI makes that pace possible. The test harness makes it trustworthy.

The Honest Tradeoffs

This process isn't magic. AI-generated SDK code still needs:

• A human who can read the language well enough to spot idiom violations

• Careful review of any security-sensitive code paths (auth headers, token handling)

• Real integration testing; coverage alone is not enough

But for a solo founder building infrastructure across 14 platforms, it's the only approach that makes shipping on this timeline realistic.

What's Next

I'll share launch updates on the Zenmanage blog as new SDKs and APIs go live: [https://zenmanage.com/blog](https://zenmanage.com/blog). If you're building in any of these languages and want early access, reply here, happy to share.

I want to be honest about something before I start: my grand plan was to find a way to quit my day job and run a software SaaS full time. I also wanted to build something most engineering teams actually need, with a focus on making the development lifecycle better.

I work full-time as a software engineer building tools for a company in the financial sector. We have a large user base and use feature flags to manage deployments safely. We pay for a feature flag platform. It works. But over time I noticed something: the tools kept growing into things we didn't need. More configuration surfaces, more integrations, more dashboard real estate dedicated to capabilities that a working engineer rarely touches. The useful core kept getting buried under the accumulated weight of everything the product had become.

That observation sat in the back of my head for a while. Then it sharpened into something more specific: I started noticing the things that were missing. Not table-stakes flagging functionality; the tooling landscape has that well covered. I mean the features that would actually change how it feels to be an engineer working with flags day to day. Workflows that don't exist yet. The stuff where you think "why does nobody build this" and then go back to whatever workaround you've been using.

I kept a list. It kept growing.

That was the spark.

Not a eureka moment. More like a slow accumulation of observation that finally crossed some threshold into: I think I should just build this.

What I'm actually building

Zenmanage is a feature flag and rollout management platform. The foundation is the expected stuff: flags, environments, percentage rollouts, targeting rules, kill switches, and SDKs for the popular languages. I'm building that out now, getting the core right before I layer anything on top of it.

The part I'm more excited about comes after that. The features from that list. The things I kept thinking were missing. I'm not going to detail them here because I'm not there yet, and I don't want to over-promise on a roadmap I'm building in personal time. But that's the actual motivation: not to rebuild what already exists, but to build the layer on top of it that I kept wishing existed.

That distinction matters to me. It's what keeps this from feeling like "another feature flag tool" in my own head, which is a thing I have to keep in check because the category looks crowded from the outside.

And it is crowded. Feature flagging is becoming a commodity. The baseline expectations are high. If you're going to ask anyone to trust your platform with how they ship software, you need to cover a lot of ground just to be taken seriously. There's a real feature parity problem to solve before you can even make the case for anything differentiated. I think about that a lot. It's a long road to reach the point where the tooling is solid enough across the board that the things I actually want to build become the story.

The infrastructure side compounds this. Feature flags sound simple until the app using them is handling serious scale: high request volumes, low latency requirements, availability expectations that don't care about your side-project maintenance window. Building something that works for a small team today and doesn't fall over when that team's app grows is a real engineering problem, not a configuration one. I'm thinking about that architecture now rather than later, because retrofitting it is worse. At the same time I'm trying to stay disciplined about the frontend: build only what's actually needed, keep the interface honest. The trap I'm trying to avoid is the exact thing that frustrated me about existing tools: a surface that grew faster than the substance underneath it.

One other thing worth mentioning: I'm using AI heavily to build this. Not as a shortcut. As a force multiplier. Building a solo side project to enterprise-grade quality is a different challenge than building the same thing with a full team, and I've spent real time learning how to use AI tools in a way that produces code I'd actually be proud to ship. The slop problem is real. AI can generate a lot of plausible-looking code that doesn't hold up under scrutiny: wrong abstractions, missed edge cases, security issues that a reviewer would catch immediately. So part of this project has become learning how to work with AI in a way that raises the bar rather than lowering it: clear context, tight review, understanding what was generated rather than just accepting it. That's a skill in itself, and it's one I think matters more as these tools get more capable, not less.

The part nobody talks about: staying motivated after hour eight

One thing I want to be direct about: I take the boundary between my job and this project seriously. I don't want there to be any question of impropriety: no working on Zenmanage during work hours, no blurred lines. So I schedule it explicitly: nights and weekends, on my own time, on my own equipment. That constraint is non-negotiable for me, and honestly it makes the whole thing feel cleaner.

The tradeoff is that it's slow. Slower than you think. Not because the work is hard in any dramatic sense, but because the time is fragmented. An hour here after dinner. A longer session on Sunday morning. A week where something comes up at the day job and you make zero progress.

I went through a phase around month three where I questioned whether I was actually building something or just doing a very elaborate form of procrastination. I had a codebase but no customers. I had a product but no proof it would be useful to anyone other than myself.

What got me through that phase was something unglamorous: I went back to the thing that started this. The tools work. They're fine. But fine isn't the same as great, and great is achievable with the right developer-focused features built on top of the foundation. That gap kept being the answer every time I asked myself why I was still doing this.

It is not motivational poster stuff. It is just: do you actually care about the problem? Because the problem is what you're going to spend most of your time with. The market validation, the revenue graphs, the "I quit my job" thread. Those are downstream of whether you care enough about the problem to keep working on it when the output is invisible.

What I'd say to someone starting

A few things I've learned that feel worth sharing:

The day job is actually useful. Not just for the income, but for the perspective. I test assumptions about Zenmanage almost every week against real engineering problems I see at work. That feedback loop is slow but it's grounded.

You don't have to find the next big thing. Find something that actually motivates you. The market for "next big thing" ideas is crowded and most of them don't get built anyway. Something that genuinely bothers you, that you'd find satisfying to fix, is a better starting point than something that sounds impressive in a pitch.

Know the difference between what you need to reach feature parity and what your actual differentiators are. The parity work is a checklist. You have to do it, but it's not where the interesting decisions live. The differentiators are where you iterate, experiment, and learn. Treating them the same way leads to premature optimization on the wrong things: over-engineering features that need to stay flexible, or shipping the parity work half-finished because you got distracted by the exciting stuff.

Ship something that delivers on what it promises and does that well. The initial release doesn't have to be groundbreaking to be valuable. Before you ship anything, be able to clearly define the value it provides. Not a vague sense of usefulness. A specific thing it does for the person using it. If you can't articulate that, you're not ready to ship it. If you can, that's your bar, and hitting it cleanly matters more than adding more surface area around it.

I'm still employed. Still building. Right now I'm heads-down on the core, getting the feature flagging foundation solid before I start working on the features that are the real reason I started.

Happy to answer questions in the comments about the technical side, the tooling decisions, or just the experience of building in this space while working full-time.

This is not a success story yet. It's the part before the success story, if there is one. I'm writing it down while I'm in it because I find that more useful than retrospectives written from a comfortable distance.

I've been building Zenmanage — a feature flag management platform — and this week we shipped a capability I've wanted since the first version: progressive rollouts.

I want to share what we built and why, because the problem it solves is something every team shipping software runs into eventually, and the decision-making behind the rollout workflow might be useful to other builders here.

The problem we kept hitting

Feature flags already let you separate deployment from release. You deploy the code, then flip the flag when you're ready. But "ready" still means ready for everyone. The flag is binary — on or off.

For low-risk changes, that's fine. But for anything with real blast radius — a new payment flow, a rewritten dashboard, a performance-heavy backend change — flipping to 100% of users on day one is a gamble. If something breaks, everyone is affected. A bug at 1% of traffic is a contained incident. A bug at 100% is a crisis.

We kept running into this ourselves, and we kept seeing the same pattern with teams evaluating the product: they wanted to release gradually, observe what happens, and expand only when the numbers looked right.

What we built

Progressive Rollouts are built directly into our flag targeting system. Instead of on/off, you now control what percentage of users see a change — 1%, 5%, 10%, all the way up. There are two modes:

Manual mode — you set the percentage and advance it yourself. Start at 5%, check your dashboards, bump to 20% after a few hours. You decide the pace. This is the right default for anything high-stakes: payment flows, data migrations, anything where you want a human making the call at each stage.

Automatic mode — the system advances through predefined stages on a daily cadence: 1% → 2% → 5% → 10% → 20% → 50% → 100%. You configure the stages, and Zenmanage handles the progression. You can still pause or complete early at any time. This works well for lower-risk UX changes or internal tooling where you trust the rollout to advance on its own.

Both modes support pause, resume, and instant rollback — no redeploy required.

One technical detail that matters more than it sounds: deterministic bucketing. Each user is hashed to a stable position in a virtual bucket. If a user qualifies at 5%, they stay in the rollout as you ramp to 10%, 20%, 50%. No flickering. No reshuffling. This is critical for a good user experience — nobody wants to see a new checkout flow one moment and the old one the next.

The workflow teams can copy right now

We wrote a full playbook for this, but the short version of the lifecycle is four phases:

1. Configure — Pick manual or automatic. Set the initial percentage. For high-risk changes, start at 1–5%. For internal or low-risk changes, 10–20% is reasonable. Save and activate.

2. Monitor — Watch error rates, p95/p99 latency, business events (conversion, activation), and support volume. Give it at least one full traffic cycle — usually 24–48 hours — before advancing. The first stage is the most important.

3. Expand — If metrics are stable, advance. In manual mode, double the percentage at each step as a rough heuristic: 5% → 10% → 20% → 40% → 80% → 100%. In automatic mode, the system handles it. Soak time at each stage matters more than speed.

4. Complete — When you're at 100% and metrics look good, complete the rollout. This promotes the new value as the flag's published default and clears the rollout state. Then schedule a cleanup ticket to remove the flag from code — leaving flags around indefinitely is how you build tech debt.

The decision matrix we use internally: if error rate spikes and cause is unknown, pause immediately. If the spike is confirmed unrelated, resume and document. If the regression is clearly caused by the rollout, use a kill switch — don't just reduce the percentage. If early data is strongly positive, complete early rather than leaving users on an older code path unnecessarily.

Why I think this matters for small teams especially

Big companies have built internal systems for this — they have release engineering teams and custom tooling. But if you're a small team or a solo founder shipping a SaaS product, you probably don't have the bandwidth to build phased release infrastructure from scratch.

Progressive rollouts turn a high-ceremony release into a routine operation. You ship when you're ready, ramp up gradually, and roll back instantly if something's off. The cost of a bad release goes from "everyone is affected, scramble to fix" to "1% saw it, we paused, we're investigating."

That changes how often you're willing to ship. And shipping more often — safely — is one of the best competitive advantages a small team can have.

I'd genuinely like to hear how other builders here handle phased releases. Are you doing percentage-based rollouts already? Rolling your own? Just yolo-ing to production and hoping for the best? Curious what the range looks like.