8 ms·

I am on my second feature flag startup, but I also somewhat agree with this. Every project should have flags, but many projects need just the basics and a serv

by jdwyah 15d ago

I am on my second feature flag startup, but I also somewhat agree with this. Every project should have flags, but many projects need just the basics and a service is overkill. Rolling your own JSON still feels like something we ought avoid though. Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be nice if the json could conform to a schema… and then eventually you are like damn I really want to change these without deploying. Or you want to read the same flag from multiple services. I’ve tried to incorporate this lowest common denominator into https://quonfig.com https://quonfig.com Use it totally free & open source as SDK, and it’s just loading JSON that you can track in git. Agents love it, hot reloads, SDK in lots of languages. But vs rolling your own you’ve got a lot of headroom on the design. A bunch of targeting operators. Segments etc. And then if you do want to get a nice UI / delivery network for real time updates, then you can use the paid side of things. Local use description: https://docs.quonfig.com/docs/how-tos/open-source-local https://docs.quonfig.com/docs/how-tos/open-source-local

quietbritishjim 15d ago
Your second startup dedicated to feature flags? Aren't these just some booleans with optional support to toggle them at runtime? Maybe I've just not been in the right domain, but I would have thought that if someone's use of feature flags is so complicated that they need a whole company to support it then they've massively overengineered their code.
- horizonwingtech 15d ago
  [flagged]
- aleksiy123 15d ago
  You can do much more with feature flags like ab testing/experiments, integrations with analytics. There can be whole UIs and tooling and infrastructure to manage around them and that’s what the sass offer
- ambicapter 15d ago
  Launchdarkly and Statsig are both well-established companies that basically do feature flags+add-ons.
- gejose 15d ago
  The author literally spells out why this isn't always the case: > Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be nice if the json could conform to a schema… and then eventually you are like damn I really want to change these without deploying. Or you want to read the same flag from multiple services.
- jdwyah 14d ago
  heh. yes. First one got acquired. But also I wish I'd built it differently from the start (git based, other lessons learned), so started over. It's true that it's a pretty simple thing, but you do want them to be of the utmost level of reliability. Its ideal if you can use feature flags & dynamic config (which I think of as the same problem) right at boot time. But then of course you have an external dependency to booting you app. So the reliability angle becomes imperative. So I do think the SaaS can play a good (or bad) role in overall reliability vs something you implement in house. The other major advantage is telemetry. Once you have things toggling on and off, immediately engineers will get confused about whether something is on or off and why. Basic internal apps usually don't have any good telemetry / debugging. So a good SaaS should give you all kinds of ways to ensure that you can see what context is being passed around to the SDK to do their eval. Sanity checking etc. My og experience was at HubSpot where we used the hell out of dynamic config. Once you get used to things like instantly targeting debug log levels for a single class to a single org its hard to go back.

by jdwyah 15d ago

quietbritishjim 15d ago

Your second startup dedicated to feature flags? Aren't these just some booleans with optional support to toggle them at runtime? Maybe I've just not been in the right domain, but I would have thought that if someone's use of feature flags is so complicated that they need a whole company to support it then they've massively overengineered their code.

horizonwingtech 15d ago
[flagged]
aleksiy123 15d ago
You can do much more with feature flags like ab testing/experiments, integrations with analytics. There can be whole UIs and tooling and infrastructure to manage around them and that’s what the sass offer
ambicapter 15d ago
Launchdarkly and Statsig are both well-established companies that basically do feature flags+add-ons.
gejose 15d ago
The author literally spells out why this isn't always the case: > Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be nice if the json could conform to a schema… and then eventually you are like damn I really want to change these without deploying. Or you want to read the same flag from multiple services.
jdwyah 14d ago
heh. yes. First one got acquired. But also I wish I'd built it differently from the start (git based, other lessons learned), so started over. It's true that it's a pretty simple thing, but you do want them to be of the utmost level of reliability. Its ideal if you can use feature flags & dynamic config (which I think of as the same problem) right at boot time. But then of course you have an external dependency to booting you app. So the reliability angle becomes imperative. So I do think the SaaS can play a good (or bad) role in overall reliability vs something you implement in house. The other major advantage is telemetry. Once you have things toggling on and off, immediately engineers will get confused about whether something is on or off and why. Basic internal apps usually don't have any good telemetry / debugging. So a good SaaS should give you all kinds of ways to ensure that you can see what context is being passed around to the SDK to do their eval. Sanity checking etc. My og experience was at HubSpot where we used the hell out of dynamic config. Once you get used to things like instantly targeting debug log levels for a single class to a single org its hard to go back.