4 ms·

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

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 24d ago
[flagged]
aleksiy123 24d 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 24d ago
Launchdarkly and Statsig are both well-established companies that basically do feature flags+add-ons.
gejose 24d 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 24d 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.

horizonwingtech 24d ago

[flagged]

aleksiy123 24d 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 24d ago

Launchdarkly and Statsig are both well-established companies that basically do feature flags+add-ons.

gejose 24d 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 24d 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.