Live data from Hacker News

Ask HN: Handling customers that want feature previewing?

news.ycombinator.com

11–20 of 68 posts

Re: Ask HN: Handling customers that want feature previewing?

#11
I also had a handful of customers like this. We ended up creating an opt-in “beta” channel that we treated as a first-class citizen along with “prod”.

Basically we had 2 production stacks with CI/CD for each. The only shared thing was the AWS ALB. Our customers each have their own subdomain so we used that to point to different EC2 ASGs.

We would continue pushing bug fixes to “prod”. Once a beta period ended, we merged to master and re-deployed master to both prod and beta channels. Rinse and repeat.

It works out pretty well. Occasionally there’s a really important bug fix that we have to cherry pick from prod to beta, but it’s rare enough to not be a huge concern.

Oh, and, charge them for it. I never got any pushback.

Re: Ask HN: Handling customers that want feature previewing?

#12
Context: financial SaaS of interest to banks, brokerages and RIAs; no direct-to-consumer at this time.

We have two special case preview environments. They're set up just like production, but with lower capacity and no SLA.

The first one is general previews of what we're planning on releasing; it's a normal part of our release process and every release is there for 2-14 days before going to production. All customers have access; some use it extensively, and some basically ignore it.

The second one is for specific in-development features; in theory we can spin up multiples of this, but in practice we don't want to diverge too wildly. Generally we showcase one feature at a time, and we gate the features by customers.

Re: Ask HN: Handling customers that want feature previewing?

#14
post #9

Feature flags is usually how we handle this. We have the flags anyway for developer use, so making them user specific was not that much incremental effort though we have had a few cases where old workflows were not removed when they should have been. We did once have a customer with their own environment with a different version deployed, as they were initially a major client with such demands but after a few years i…

Agree on this. We delivered new versions to customers once a week, but every new version should not have been noticed by a customer at all.

The roll out of feature flags is a separate process.

Re: Ask HN: Handling customers that want feature previewing?

#15

I also had a handful of customers like this. We ended up creating an opt-in “beta” channel that we treated as a first-class citizen along with “prod”. Basically we had 2 production stacks with CI/CD for each. The only shared thing was the AWS ALB. Our customers each have their own subdomain so we used that to point to different EC2 ASGs. We would continue pushing bug fixes to “prod”. Once a beta period ended, we merg…

Thanks for sharing!

Was the beta channel that you had in the pipeline for prod? i.e. prod would have no chance of getting ahead of beta because prod was always deployed based on what was last on the beta release?

Hot or bug fixing is an interesting topic because you could end up with diverging histories if you're not careful. Did you try to maintain `master` as the single source of truth or did you make separate release and deploy branches for each environment?

Re: Ask HN: Handling customers that want feature previewing?

#16
I had a similar situation in fintech. We had 3 different release cycles and hosting farms for fast, medium and slow accepting customers. Fast went to the customers who didn't require approvals, and who were flex when it came to errors in the release. Then there was a medium channel where the other customers were fine as long as a couple of the major customers in that pack approved things. The slow channel basically was for customers who had large validation or training requirements associated with releases.

Re: Ask HN: Handling customers that want feature previewing?

#17

Sounds to me like the customer is trying to solve a problem and is coming to you with their chosen solution. My suggestion: Find out what problem they are trying to solve, and address that . Also, you might look at cPanel's notices that they send out where they explain upcoming feature updates well in advance of the rollout. They also have different release cycles, where the newest features are released to the EDGE c…

> Sounds to me like the customer is trying to solve a problem and is coming to you with their chosen solution. My suggestion: Find out what problem they are trying to solve, and address that.

This.

Problems they might be trying to solve:

   * want to be able to jump on new features as soon as they are released, but need to plan with the eng team
   * want to be "in the know" so not surprised by new features
   * want to be able to give feedback and help direct the roadmap
   * have been bitten by bugs in your software (or other vendors) and want burn in time, especially if you upgrade them without their choosing (as is typical in some SaaS models)
I'm sure there are others, but it's worth asking why they are requesting this if you haven't done so already.

Re: Ask HN: Handling customers that want feature previewing?

#18
post #13

Seems like you need advanced feature flags.

In your comment here, what's the distinction of advanced vs. a regular feature flag?

Regular feature flag is just on and off. When you start getting into the advance you can change it for user groups, specific users, timable so it's only enabled for a timeframe, only on a specific env. The possibilities are endless.

I make the distinction so people don't just think they can put a single if statement in and be able to handle this sort of scenario.

Re: Ask HN: Handling customers that want feature previewing?

#19
post #13

Earlier quoted context omitted.

In your comment here, what's the distinction of advanced vs. a regular feature flag?

Regular feature flag is just on and off. When you start getting into the advance you can change it for user groups, specific users, timable so it's only enabled for a timeframe, only on a specific env. The possibilities are endless. I make the distinction so people don't just think they can put a single if statement in and be able to handle this sort of scenario.

Got it - that clarifies it.
Post reply on HN