right now to disable a certain part of the app you need to comment the code out, which causes merge conflicts.

it would be great to have an area inside console.cal.com where you can activate and de-activate certain features for your self-hosted platform product

• every link in navigation (i.e. disable "App Store" or "Workflows" link)
• send emails
• ...

what else?

EDIT: by @zomars

Types of feature flags

Basically we have 4 kinds of feature flags (taken from this nice article):

• Release Flags
• Experiment Flags
• Operation Flags
• Permission Flags

Release flags

These are used to turn certain features on or off. This helps us work on new features without breaking anything that's already working. Product managers can also use Release Flags to hide new features from users until they're ready. Release Flags are temporary and usually only last for a short time, and they're easy to change if needed. Using Release Flags is a way to make sure that new things are added to software without causing problems for users.

Experiment flags

These are used to test different versions of a feature to see which one works better. We can put different people into different groups and send them down different paths to see what happens. This helps us figure out what people like and what they don't like, and we can use this information to make things better. Experiment Toggles need to stay in place for long enough to get lots of information, but not too long that the information becomes outdated. They're always changing because different people use them all the time.

Operation Flags

These can turn parts of the system on and off, just in case there's a problem. For example, if we add a new feature to our system and we're not sure if it will work properly, we can use an Ops Toggle to quickly turn it off if we need to. Most Ops Toggles are only used for a short time, but some are kept for a long time, like a "Kill Switch," which helps us turn off less important parts of the system when there's too much work to do. It's important to be able to change these buttons quickly in case something goes wrong, so we don't have to wait too long to fix things.

Permission Flags

These control which users can access certain features or product experiences. For example, we may have special features that only paying customers can use, or we may have features that are only available to our internal team or a specific group of beta testers. This technique of turning on new features for a set of internal or beta users is called a Champagne Brunch. It's similar to a Canary Release, which exposes new features to a randomly selected group of users. Permissioning Toggles may be used for a long time, especially when managing features that are only accessible to premium users. This is because permissions are user-specific, so the toggle decision needs to be made for each user request.

Possible usage examples (taking inspiration from happykit)

On client:

// pages/index.js
import { useFlags } from "@calcom/features/flags/client";

export default function IndexPage(props) {
  const { flags } = useFlags();

  return flags.new-booking === "true"
    ? "You get the new booking"
    : "You get the old booking";
}

On server:

import { GetServerSideProps } from "next";
import { getFlags } from "@calcom/features/flags/server";

export const getServerSideProps = async (
  context
) => {
  const { flags, data } = await getFlags({ context });
  return { props: { flags, data } };
};

On middleware:

import { NextRequest, NextResponse } from "next/server";
import { getEdgeFlags } from "@calcom/features/flags/edge";

export const config = { matcher: "/demo/middleware" };

export async function middleware(request: NextRequest) {
  const { flags, cookie } = await getEdgeFlags({ request });

  const nextUrl = request.nextUrl.clone();
  nextUrl.pathname = `/demo/middleware/${flags?.checkout || "full"}`;
  const response = NextResponse.rewrite(nextUrl);

  if (cookie) response.cookies.set(...cookie.args);

  return response;
}

_{From SyncLinear.com | CAL-1143}