Building a product to solve a problem I lived every day

The problem I was living

At Fraction, feature flags were everywhere and nowhere at the same time. Some lived in Vercel environment variables. Others were in .env files that may or may not have been committed to the repo. A few were hardcoded constants that nobody remembered setting. And some were in a Retool dashboard I'd built that only a handful of people knew existed.

When something went wrong in production — and in a financial platform, something going wrong has real consequences — the first question was always: can we turn that feature off while we fix it? Finding the answer took longer than the fix itself. Ten minutes of searching through four different systems to answer a yes/no question.

No single source of truth. No audit trail. No accountability. And no way for anyone outside the dev team to understand the current state of the product — which meant product managers and operations staff were always dependent on engineers for information they should have been able to access themselves.

Why not just use what exists

Enterprise feature flag platforms exist. LaunchDarkly, Split, Unleash. They're well-built and powerful. They're also priced per seat, designed for large organisations, and assume you're starting from scratch — that you'll migrate everything into their system and build around their SDK from day one.

That's not the reality for most small teams. The reality is flags already exist, scattered across multiple systems, and asking a team to abandon all of them to adopt a new platform is a significant migration cost that most teams won't take on. So the flags stay scattered, and the problem continues.

Winga's starting point is different: import what you already have first. .env files, Vercel environment variables, GitHub Secrets — bring them all in, see everything in one place, and then decide what to do next. The migration happens gradually, on the team's terms, without a big-bang cutover.

The product decisions

Building alone means every decision is yours — which is clarifying. There's no committee, no one to defer to. You either believe a decision is right or you don't ship it.

Import-first

The onboarding flow starts by importing existing flags, not creating new ones. This was the first and most important product decision. Every competing tool opens with an empty dashboard and asks you to create your first flag. That moment of emptiness is a friction point — it asks the user to imagine a future state rather than solve their current problem. Winga starts by making the current mess visible.

AI codebase scanner

Beyond importing existing flags, a Gemini-powered scanner reads the codebase and suggests where feature flags should exist but don't — hardcoded values, magic booleans, commented-out blocks. This surfaces the shadow flags that aren't in any system yet. It's a different kind of import: not from a config file but from the codebase itself.

Flat pricing

Per workspace, not per seat. A 10-person team pays the same as a 2-person team. This was a deliberate positioning decision — the per-seat model punishes growth and creates perverse incentives around access. If you want PMs and ops staff to have visibility into flag states, you shouldn't have to pay more to give it to them.

PM access as a feature

Giving non-technical team members safe access to toggle flags — without requiring a deploy — removes a whole category of developer interruptions. A PM can turn a feature on for a demo, or roll back a poorly-received release, without filing a ticket. The audit trail means there's accountability without gatekeeping.

Stack decisions

Building solo means the stack has to be maintainable by one person. Every choice was made against that constraint — no technology for its own sake, nothing that requires a team to operate.

// Three lines. That's it.
import { Winga } from '@winga/js'
const winga = new Winga({ apiKey: 'proj_live_xxx' })

if (winga.isEnabled('new-checkout')) {
  showNewCheckout()
}

What this demonstrates

Winga is a product I'm building because I needed it — which is the most honest reason to build anything. The problem is real, the solution is considered, and every decision has a clear rationale.

As a portfolio piece it shows something different from client work: what happens when there's no brief, no client, no team, and no deadline. Just a problem worth solving and a decision about how to solve it properly. The product thinking, the stack choices, the pricing model, the onboarding philosophy — all of it is mine.

It's also a demonstration of the technical depth that my day job has developed. Designing the product and building it in the same stack I use professionally isn't a coincidence — it's what happens when the line between designer and developer has been blurring for six years.