DEV Community: Andrew Lee Jenkins

MIT vs GPL vs AGPL vs Proprietary - which license fits your CRM build?

Andrew Lee Jenkins — Fri, 29 May 2026 14:16:30 +0000

I've shipped three CRM forks under three different licenses, and the license decision has caused me more long-term pain than any code decision I've made.

If you're picking a codebase to fork, or deciding what to release your own under, this post is the cheat sheet I wish I'd had in February.

TL;DR

MIT, Apache 2, BSD: ship whatever you want, attribute correctly, move on
GPL v2/v3: anyone you distribute the binary to gets the source
AGPL: anyone who uses your software over a network gets the source. This is the SaaS killer
Proprietary: your problem to write and enforce, but you control everything

Pick Apache 2 if you're forking and shipping SaaS. Pick proprietary if you're selling source code as a product. Skip AGPL unless you're prepared to release every backend change you make.

The quick license table

License	Distribute closed source?	SaaS without releasing code?	Patent grant?	Attribution required?
MIT	Yes	Yes	Implied only	Yes (short notice)
Apache 2.0	Yes	Yes	Explicit	Yes (NOTICE file)
BSD 3-Clause	Yes	Yes	No	Yes (short notice)
GPL v2	No	Yes (loophole)	No	Yes (full license)
GPL v3	No	Yes (loophole)	Explicit	Yes (full license)
AGPL v3	No	NO	Explicit	Yes (full license)
Proprietary	Depends	Depends	Depends	Depends

That table is your 90% answer. The rest of this post is the why.

MIT - the "do whatever" license

MIT is four paragraphs of plain English. You can fork it, close-source it, sell it, ship it as SaaS, and the only thing you have to do is keep the copyright notice in the source.

Here's the actual obligation:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

That's it. You don't need a NOTICE file, you don't need to publish anything, you just keep the header in the source files you redistribute. If you compile MIT code into a binary and ship that binary, technically you're supposed to surface the license text somewhere your users can find it (an About screen, a /legal route, a LICENSES.md in the install bundle).

In a CRM context, MIT is gold for utility libraries. If you find an MIT-licensed React table component, you can use it forever, never publish your fork, and ship it to clients without a second thought.

What MIT does NOT give you: an explicit patent grant. If the original author has a patent that covers what their code does, MIT doesn't expressly license that patent to you. Courts have generally treated MIT as an implied patent license, but if you're shipping a real product with real revenue, this is the gap that Apache 2.0 closes.

Apache 2.0 - MIT with adult supervision

Apache 2.0 is what I'd recommend to anyone forking a permissively-licensed CRM and shipping SaaS. It gives you:

The same "do whatever" rights as MIT
An explicit patent grant from contributors
A termination-on-patent-litigation clause (if you sue someone for patent infringement on the project, your license dies)
A NOTICE file mechanism for attribution

The NOTICE piece is what trips most people up. If the upstream repo ships a NOTICE file, you have to redistribute its contents in any derivative work. So if you fork an Apache 2.0 CRM, you can't just delete NOTICE and replace it with your own. You can ADD to it. You can't subtract.

Here's what an Apache 2.0 source file header looks like:

/*
 * Copyright 2024 Original Author Name
 * Copyright 2026 Your Company Here
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 */

And your NOTICE file might look like:

Acme CRM
Copyright 2026 Acme Inc.

This product includes software developed at
Upstream Project (https://github.com/upstream/crm-core).
Copyright 2024 Original Author Name

If you're shipping a JS bundle, the convention is a LICENSES.txt in your /public directory linked from a /legal page or your app footer. I've seen plenty of "Apache 2.0 violating" forks in the wild because the founder didn't realize that minifying away source headers is technically a violation.

BSD - like MIT, lawyer-flavored

BSD comes in 2-Clause and 3-Clause flavors. 3-Clause adds a "you can't use my name to endorse your fork" provision. For CRM purposes, BSD is functionally MIT with extra text. Keep the notice, ship the product.

The only thing to watch: there's an older "4-Clause BSD" that requires an advertising clause ("All advertising materials mentioning features must display..."). This is GPL-incompatible and rare in modern code, but if you're forking something from before 1999, check the LICENSE file carefully.

GPL v2 and v3 - copyleft for distributed binaries

Here's where most developers get confused.

GPL says: if you distribute a binary built from GPL code, anyone who gets that binary has the right to demand the source code, modifiable and rebuildable. This is "copyleft."

In a CRM SaaS context, GPL is fine in practice. You're not distributing the binary. Your users hit a web app. The binary sits on your server. They never receive a copy. So technically, GPL doesn't trigger.

This is the "SaaS loophole" the AGPL was written to close.

You CAN fork a GPL CRM, modify it, run it on your servers, sell SaaS access, and never release a single line of code. Legally clean. Ethically, that's a conversation for the project's community.

But the moment you ship a desktop app, a mobile app, or an on-prem installer to a client? You're distributing. Source code must be available. And not just on an "I'll send it if you ask" basis. GPL v3 requires you to either:

Include the corresponding source with every binary, or
Provide a written offer valid for 3 years to send the source, or
(For non-commercial distribution) Pass along the offer you received

Here's the kicker: any code you LINK to GPL code typically has to be GPL too. So if you fork a GPL CRM core and add your closed-source billing module, the billing module is supposed to be GPL also. This is the "viral" nature of GPL that scares enterprise lawyers.

GPL v3 adds explicit patent grants and an anti-Tivoization clause (you can't ship a device where the user can't actually modify and reinstall the GPL software). For CRM SaaS, v2 vs v3 rarely matters in practice.

AGPL - the SaaS killer

If GPL is "copyleft on distribution," AGPL is "copyleft on network use."

The relevant section is AGPL Section 13:

Notwithstanding any other provision of this License, if you modify
the Program, your modified version must prominently offer all users
interacting with it remotely through a computer network ... an
opportunity to receive the Corresponding Source of your version by
providing access to the Corresponding Source from a network server
at no charge ...

Translation: if your users hit your CRM over the internet, AND you've modified the source, AND the project is AGPL, you have to make YOUR modified source available to those users.

So if you fork an AGPL CRM, build it into your SaaS product, and a customer logs into your dashboard, that customer can demand your full source code. Including the billing logic you wrote, the integrations you built, the security patches you applied.

Some people are fine with this. Some companies used AGPL as a strategic moat: nobody can host a competing version of our product without releasing all their improvements. That's the whole point.

But if you're a small agency or solo dev planning to stand out on the proprietary stuff you build on top, AGPL will torch your plan. I evaluated two AGPL-licensed CRM projects in February before deciding it wasn't worth the legal exposure for a SaaS play.

If you want to ship SaaS with an AGPL-licensed base, you have exactly two options:

Release your modifications under AGPL (the project's intent)
Buy a commercial license from the copyright holder (the project's revenue model)

There is no option 3.

How to read a LICENSE file in 60 seconds

When I'm evaluating a codebase, here's the script I run mentally:

Open LICENSE, LICENSE.txt, or COPYING in the repo root. No file? Walk away. Unlicensed code is "all rights reserved" by default, which means you have no rights.
Look at the first identifying line. Is it "MIT License," "Apache License Version 2.0," "GNU GENERAL PUBLIC LICENSE Version 3," etc.? That tells you 90% of what you need.
Check for a NOTICE file. If present, you must redistribute its contents. Open it.
Look at package.json or pyproject.toml. The license field should match the LICENSE file. Mismatches happen and they're a red flag.
Search the repo for "Commons Clause," "Business Source License," or "SSPL". You'll see more of these lately. They look like open source but explicitly forbid commercial use or SaaS hosting. They're not OSI-approved and they don't behave like the licenses above.

Here's a one-liner I use to check a repo before forking:

curl -sL https://api.github.com/repos/OWNER/REPO/license \
  | jq -r '.license.spdx_id, .license.name, .download_url'

That returns the SPDX identifier, friendly name, and a URL to the raw license text. If spdx_id comes back NOASSERTION or null, GitHub's auto-detection couldn't figure out the license. That's almost always bad news.

The real story - why I built mine from scratch instead

I had a decision to make in February. I'd been paying GHL monthly for years to run my agency, and I was tired of the subscription treadmill. The play was either:

Fork an existing AGPL or GPL CRM, eat the license obligations, and rebrand
Buy a commercial source-code license from a proprietary CRM vendor
Build from scratch

I went deep on the open source side. The two most viable forks I looked at were both AGPL. One had a beautiful UI and decent architecture. The other had a more mature feature set but a Frankensteined backend.

The math didn't work. Both would have meant either:

Releasing every backend modification to my customers under AGPL Section 13, or
Buying a commercial license that cost more than building from scratch

So I closed the tabs, opened Cursor, and started writing Next.js + Convex code. 800+ hours later, I had a CRM I could license however I wanted, because I owned every line.

I'm shipping it under a proprietary source-code license. One-time payment, you get the code, you can modify it, you can't resell it as a competing product. That model doesn't work with AGPL upstream. It barely works with GPL upstream. It works fine with Apache 2.0 upstream (which is why my dependency tree is almost entirely Apache 2.0 and MIT). And it works perfectly with code I wrote myself.

This is the same lesson I keep relearning in agency work: ambiguity will absolutely DESTROY you. I had a client rebrand a while back and Google basically lost its mind trying to figure out what they did. I spent weeks playing detective with press releases and citation cleanup, the leads coming in were unqualified, and we eventually parted ways. Same principle for licenses. If you don't know exactly what you're allowed to do with your codebase, you'll spend more time playing lawyer than shipping product.

Attribution - the bare minimum

For any permissively-licensed dependency in your CRM, here's the minimum attribution stack.

In your package.json:

{
  "name": "your-crm",
  "license": "SEE LICENSE IN LICENSE.txt",
  "dependencies": {
    "some-apache-thing": "^1.0.0"
  }
}

In /public/licenses.json or /legal/oss, dump the output of:

npx license-checker --production --json > public/licenses.json

That gives you every dependency, its license, and its copyright notice in one file. Most courts and most lawyers consider this sufficient for permissive licenses. For Apache 2.0, also concatenate any upstream NOTICE files into a single NOTICE.txt in your distribution.

In your app footer or settings page:

<a href="/legal/oss" className="text-xs text-gray-500">
  Open source licenses
</a>

This is the part most "I forked a CRM in a weekend" tutorials skip. It takes 20 minutes. Do it once, never think about it again.

Compatibility matrix

The question I get most: "can I combine X-licensed code with Y-licensed code in the same project?"

Combining	MIT	Apache 2	BSD	GPL v2	GPL v3	AGPL v3	Proprietary
MIT	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Apache 2	Yes	Yes	Yes	NO	Yes	Yes	Yes
BSD 3-Clause	Yes	Yes	Yes	Yes	Yes	Yes	Yes
GPL v2	Yes	NO	Yes	Yes	NO	NO	NO
GPL v3	Yes	Yes	Yes	NO	Yes	Yes	NO
AGPL v3	Yes	Yes	Yes	NO	Yes	Yes	NO
Proprietary	Yes	Yes	Yes	NO	NO	NO	Yes

Key gotcha: Apache 2.0 is incompatible with GPL v2 (because of the patent retaliation clause), but compatible with GPL v3. That's why the Linux kernel (GPL v2 only) can't directly include Apache-licensed code, but plenty of GPL v3 projects do.

Combining GPL-family code with proprietary code in a single distributable binary is generally not allowed. Some projects use a "linking exception" to permit this. Most don't.

What to actually do

If you're forking, pick a project under Apache 2.0 or MIT. Do the attribution work upfront. Build your SaaS, sleep well.

If you're forking AGPL and planning to ship SaaS, either commit to releasing your modifications or buy a commercial license. Don't try to find a loophole. There isn't one that won't blow up during due diligence.

If you're writing your own and selling source code, write a proprietary license. Get a lawyer to review it. The standard structure: perpetual license to use and modify, no right to resell as a competing product, attribution preserved. That's the lane I'm in with Seedly, and I wrote up the white-label playbook for reselling CRM code if you want the business side of it.

If you're not sure what license your dependency is under, run the SPDX check above. If you're still not sure, drop the repo link in the comments. Happy to take a look.

If the white-label side is what you're actually weighing, I broke down the three real options (license a SaaS, fork open source, or buy a codebase outright) in this Quora answer.

Not a lawyer. Just a guy who's read more LICENSE files this year than he ever wanted to.

Exporting CRM data is messier than you think: migration scripts for Honeybook, Dubsado, and 17hats

Andrew Lee Jenkins — Sat, 16 May 2026 15:00:36 +0000

I've scripted CRM migrations from Honeybook, Dubsado, and 17hats. The CSV exports are dirtier than you'd expect. Here are the scripts I use.

Related reading on owning your CRM stack - https://seedlycrm.com/blog/gohighlevel-alternatives-where-you-own-the-code

Why this post exists

I run an agency for home service businesses. A lot of my onboarding work isn't the fun stuff. It's getting a client's data out of whatever boutique CRM they're stuck in and into a schema that doesn't make me want to punch a wall.

Each of these three platforms exports differently, and each one has its own brand of "yeah we technically gave you your data" energy.

Export reality: Honeybook

Honeybook's export is a zip with multiple CSVs. Contacts, projects, payments, files. Quoting is inconsistent across older exports, so a naive pd.read_csv will eat it alive.

Things to know going in:

Phone numbers come through as strings with formatting characters baked in.
Project status uses internal codes that aren't documented in the export.
Notes can contain raw HTML from rich-text inputs.
Date fields are ISO-ish, but they don't tell you the timezone is UTC.

import pandas as pd

contacts = pd.read_csv(
    "honeybook_export/contacts.csv",
    engine="python",         # the C engine chokes on inconsistent quoting
    dtype=str,               # never trust pandas type inference on dirty CSVs
    keep_default_na=False,
    encoding="utf-8-sig",    # strip the BOM honeybook adds
)

Export reality: Dubsado

Dubsado makes you export each section separately. Clients, projects, leads, invoices. There's no "give me everything" button. You'll be clicking for ten minutes.

The clients CSV has a tags column that's a single string of comma-separated tags. So now you have commas inside a comma-delimited file. The export wraps that field in quotes most of the time, but I've seen cases where it doesn't.

The bigger problem is custom fields. Dubsado lets clients add custom fields per-project, and those come through as columns named whatever the user typed. I once opened an export with 60+ columns because someone got creative with their intake form.

def load_dubsado_clients(path):
    df = pd.read_csv(path, dtype=str, keep_default_na=False)

    core = {"name", "email", "phone", "company", "address", "tags", "status"}
    custom_cols = [c for c in df.columns if c.lower() not in core]

    # collapse unknown columns into a single notes blob
    df["_custom_blob"] = df[custom_cols].apply(
        lambda row: "\n".join(
            f"{k}: {v}" for k, v in row.items() if v.strip()
        ),
        axis=1,
    )
    return df.drop(columns=custom_cols)

If the client wants those custom fields preserved, you map them to your target CRM's custom field schema. If they don't care (most don't), it goes in notes.

Export reality: 17hats

17hats gives you contacts and projects as separate CSVs. The contact identifier isn't called contact_id. It's called Contact #. With a space and a hash symbol. Welcome to migration.

The phone column can contain multiple numbers in one cell, separated by a slash or an "alt:" prefix. So (804) 555-1234 / alt: 804-555-9999 is a real value I've parsed.

import re

PHONE_RE = re.compile(r"[\d\(\)\-\s\+]+")

def split_17hats_phones(raw):
    if not raw:
        return []
    parts = re.split(r"[/;]|alt:", raw, flags=re.IGNORECASE)
    cleaned = []
    for p in parts:
        match = PHONE_RE.search(p)
        if match:
            digits = re.sub(r"\D", "", match.group())
            if len(digits) >= 10:
                cleaned.append(digits[-10:])
    return cleaned

You'll thank me when your SMS sender isn't trying to text "alt:" as a destination.

The CSV pitfalls that bite everyone

I keep a checklist I run before I touch anything:

BOM at the start of the file. UTF-8 with BOM is common in older exports. Use encoding="utf-8-sig".
Mixed line endings. Windows \r\n and Unix \n in the same file. pandas usually handles it. csv.reader sometimes doesn't.
Embedded newlines in fields. Notes with line breaks will split into multiple "rows" if you read line-by-line. Always use a real CSV parser.
Smart quotes. Curly quotes from someone who pasted in from Word will not match your search filters. Normalize to straight quotes.
Trailing whitespace in emails. john@example.com is not john@example.com to most CRMs. Strip.
Duplicate contacts. Same person entered twice with different formatting. Match on lowercase trimmed email first, then on (name, phone) as a fallback.
Empty strings vs nulls. Some CSVs use "", some use NULL, some use N/A. Normalize on load.

def normalize_email(s):
    if not s:
        return None
    s = s.strip().lower()
    return s if "@" in s else None

def normalize_phone(s):
    if not s:
        return None
    digits = re.sub(r"\D", "", str(s))
    if len(digits) == 11 and digits.startswith("1"):
        digits = digits[1:]
    return digits if len(digits) == 10 else None

The reusable script template

Every migration I write follows the same shape. Load, normalize, map fields, validate, write. I keep it boring on purpose.

# migrate.py
import pandas as pd
import json
import sys
from pathlib import Path

def load(source, path):
    loaders = {
        "honeybook": load_honeybook,
        "dubsado":   load_dubsado,
        "17hats":    load_17hats,
    }
    return loaders[source](path)

def normalize(df):
    df["email"] = df["email"].apply(normalize_email)
    df["phone"] = df["phone"].apply(normalize_phone)
    df["name"]  = df["name"].str.strip()
    return df

FIELD_MAP = {
    # source_column : target_column
    "email":        "primary_email",
    "phone":        "primary_phone",
    "name":         "full_name",
    "company":      "company_name",
    "tags":         "tag_list",
    "_custom_blob": "notes",
}

def map_fields(df, mapping=FIELD_MAP):
    out = pd.DataFrame()
    for src, dst in mapping.items():
        out[dst] = df[src] if src in df.columns else None
    return out

def validate(df):
    errors = []

    no_contact = df[df["primary_email"].isna() & df["primary_phone"].isna()]
    if len(no_contact):
        errors.append(f"{len(no_contact)} rows have no email or phone")

    dupes = df[df["primary_email"].duplicated(keep=False) & df["primary_email"].notna()]
    if len(dupes):
        errors.append(f"{len(dupes)} duplicate emails")

    return errors

def write(df, out_path):
    df.to_csv(out_path, index=False, encoding="utf-8")

if __name__ == "__main__":
    source, in_path, out_path = sys.argv[1], sys.argv[2], sys.argv[3]
    df = load(source, in_path)
    df = normalize(df)
    df = map_fields(df)
    errs = validate(df)
    if errs:
        print("VALIDATION FAILED:")
        for e in errs:
            print(" -", e)
        sys.exit(1)
    write(df, out_path)
    print(f"wrote {len(df)} rows to {out_path}")

Usage:

python migrate.py honeybook ./exports/contacts.csv ./out/contacts.csv

Validate before you import. Always.

The thing that has saved me from "hey Andrew our CRM thinks every customer has the same email" is dry-running the import against a staging instance and diffing the counts.

My validation pass checks:

row count matches the source (no silent drops)
every row has at least one contact method
no duplicate primary emails
phone numbers are exactly 10 digits after normalization
timestamps parse cleanly
tag list has no empty strings

If any of those fail, the script exits non-zero and I don't touch the prod CRM. If I'm feeling fancy I pipe the validation report to a JSON file the client can review before I press the button.

def write_report(df, errs, path):
    Path(path).write_text(json.dumps({
        "total_rows": len(df),
        "rows_with_email": int(df["primary_email"].notna().sum()),
        "rows_with_phone": int(df["primary_phone"].notna().sum()),
        "errors": errs,
    }, indent=2))

Client sees the report. Client signs off. Then I import. Has saved my ass more than once when someone went "wait, we don't have 4,000 contacts, we have 400" and we caught it before it hit production.

What I'd do differently starting today

Skip the CSV middle step entirely if the source has a real API. Honeybook does, kind of. Dubsado does not in any meaningful sense. 17hats is a no.

If you're stuck with CSVs, version-control them. Drop the raw export into a git-ignored folder, commit the normalized output, and you'll have an audit trail when the client emails you in six months asking why a contact looks different.

Also: write the script for your worst client, not your best one. The one with 14 years of half-finished projects and free-text status fields where someone typed "idk?" 47 times. If your script handles them, it handles anyone.

If you've done one of these migrations and hit something I didn't cover, drop it in the comments. I'm building my own CRM right now specifically so I never have to do another Dubsado export, and I'd love to know what I'm missing on the import side.

I've white-labeled the same CRM codebase 7 times for 7 different clients. I never touch the core. Here's how the override layer works.

Andrew Lee Jenkins — Wed, 13 May 2026 17:20:36 +0000

This is the pattern I wish someone had handed me two years ago when I was still git-branching every client into their own forked repo (yes, really, it was as bad as it sounds). One client needs different colors. Another needs their logo on the login screen. A third wants to hide the entire invoicing module because they only use it for lead capture. If you fork the core for each of those, you're signing up to merge bug fixes across 7 repos forever.

Don't do that. Here's what I do instead.

The mental model: core stays sacred, everything else is config

The trick is treating your CRM as two things stacked on top of each other:

Core app code. Routes, business logic, database schema. Untouchable. Same for every tenant.
A branding + feature override layer. Env vars, CSS tokens, email templates, assets, feature flags. This is the ONLY thing that changes between deployments.

When I onboard a new white-label client, I clone the same repo, drop in a new .env, swap a few files in /public/brand/, flip a couple flags, and ship. No git diff against the core. Ever.

Let me walk you through each layer.

Step 1: environment-based branding

This is where most people start, and most people stop. The env file is doing way more work than just storing API keys.

# .env.production (client A: Apex Plumbing)
NEXT_PUBLIC_APP_NAME="Apex CRM"
NEXT_PUBLIC_APP_DOMAIN="crm.apexplumbing.com"
NEXT_PUBLIC_SUPPORT_EMAIL="help@apexplumbing.com"
NEXT_PUBLIC_BRAND_PRIMARY="#0F4C81"
NEXT_PUBLIC_BRAND_ACCENT="#F4A300"
NEXT_PUBLIC_LOGO_PATH="/brand/apex/logo.svg"
NEXT_PUBLIC_FAVICON_PATH="/brand/apex/favicon.ico"
NEXT_PUBLIC_LOGIN_BG="/brand/apex/login-bg.jpg"

Same repo, different .env:

# .env.production (client B: Riverside Roofing)
NEXT_PUBLIC_APP_NAME="Riverside HQ"
NEXT_PUBLIC_APP_DOMAIN="hq.riversideroofing.com"
NEXT_PUBLIC_SUPPORT_EMAIL="ops@riversideroofing.com"
NEXT_PUBLIC_BRAND_PRIMARY="#1A3A2A"
NEXT_PUBLIC_BRAND_ACCENT="#C7522A"
NEXT_PUBLIC_LOGO_PATH="/brand/riverside/logo.svg"
NEXT_PUBLIC_FAVICON_PATH="/brand/riverside/favicon.ico"
NEXT_PUBLIC_LOGIN_BG="/brand/riverside/login-bg.jpg"

Then I read those once in a single brand.config.ts so the rest of the app doesn't have to care:

// lib/brand.config.ts
export const brand = {
  appName: process.env.NEXT_PUBLIC_APP_NAME ?? "CRM",
  domain: process.env.NEXT_PUBLIC_APP_DOMAIN ?? "localhost:3000",
  supportEmail: process.env.NEXT_PUBLIC_SUPPORT_EMAIL ?? "",
  colors: {
    primary: process.env.NEXT_PUBLIC_BRAND_PRIMARY ?? "#111111",
    accent: process.env.NEXT_PUBLIC_BRAND_ACCENT ?? "#FF6600",
  },
  assets: {
    logo: process.env.NEXT_PUBLIC_LOGO_PATH ?? "/brand/default/logo.svg",
    favicon: process.env.NEXT_PUBLIC_FAVICON_PATH ?? "/brand/default/favicon.ico",
    loginBg: process.env.NEXT_PUBLIC_LOGIN_BG ?? "/brand/default/login-bg.jpg",
  },
};

Now anywhere in the app, brand.appName and brand.colors.primary just work. No hardcoded strings, no per-client if (tenant === "apex") branches. The core doesn't know who it's deployed for and that's the WHOLE point.

Step 2: theme overrides via CSS variables

Tailwind is fine, but the second you start dynamic theming with pure Tailwind classes you end up with bg-blue-600 hardcoded in 200 components. Don't do that. Bind your brand colors to CSS custom properties at the root, then point Tailwind at those.

/* app/globals.css */
:root {
  --color-brand-primary: 15 76 129;   /* RGB triplet, set at runtime */
  --color-brand-accent: 244 163 0;
  --color-bg: 255 255 255;
  --color-fg: 17 17 17;
}

[data-theme="dark"] {
  --color-bg: 12 12 14;
  --color-fg: 240 240 240;
}

// tailwind.config.ts
export default {
  theme: {
    extend: {
      colors: {
        brand: {
          primary: "rgb(var(--color-brand-primary) / <alpha-value>)",
          accent: "rgb(var(--color-brand-accent) / <alpha-value>)",
        },
        bg: "rgb(var(--color-bg) / <alpha-value>)",
        fg: "rgb(var(--color-fg) / <alpha-value>)",
      },
    },
  },
};

Then in your root layout, you inject the brand colors from the env at runtime so the same JS bundle works for every tenant:

// app/layout.tsx
import { brand } from "@/lib/brand.config";

function hexToRgb(hex: string) {
  const h = hex.replace("#", "");
  const r = parseInt(h.slice(0, 2), 16);
  const g = parseInt(h.slice(2, 4), 16);
  const b = parseInt(h.slice(4, 6), 16);
  return `${r} ${g} ${b}`;
}

export default function RootLayout({ children }) {
  const style = {
    "--color-brand-primary": hexToRgb(brand.colors.primary),
    "--color-brand-accent": hexToRgb(brand.colors.accent),
  } as React.CSSProperties;

  return (
    <html lang="en" style={style}>
      <head>
        <title>{brand.appName}</title>
        <link rel="icon" href={brand.assets.favicon} />
      </head>
      <body>{children}</body>
    </html>
  );
}

bg-brand-primary and text-brand-accent now resolve to whatever the env says. Zero code changes between tenants.

Step 3: email template overrides

This is where I see people fall over. They hardcode "Welcome to MyApp!" into the transactional emails and then have to fork the templates for every client. Same idea as above: read from brand, never hardcode.

// emails/welcome.tsx (using react-email)
import { brand } from "@/lib/brand.config";

export function WelcomeEmail({ firstName }: { firstName: string }) {
  return (
    <Html>
      <Body style={{ backgroundColor: "#f6f6f6" }}>
        <Container>
          <Img src={`https://${brand.domain}${brand.assets.logo}`} width="140" />
          <Heading>Welcome to {brand.appName}, {firstName}.</Heading>
          <Text>
            If you get stuck, hit reply or email {brand.supportEmail}.
          </Text>
          <Text style={{ color: "#888", fontSize: 12 }}>
            Sent by {brand.appName} | {brand.domain}
          </Text>
        </Container>
      </Body>
    </Html>
  );
}

For clients who want truly different copy (not just different branding), I add a thin override directory the build resolves before the default:

/emails
  /default/
    welcome.tsx
    invoice-sent.tsx
  /overrides/
    apex/
      welcome.tsx        <- only the files Apex wants different
    riverside/
      invoice-sent.tsx

Then a tiny resolver picks the override if it exists:

// lib/email/resolve.ts
import { brand } from "@/lib/brand.config";

const tenant = process.env.BRAND_KEY ?? "default";

export async function loadEmail(name: string) {
  try {
    return (await import(`@/emails/overrides/${tenant}/${name}`)).default;
  } catch {
    return (await import(`@/emails/default/${name}`)).default;
  }
}

Default lives in the core. Overrides live in a per-tenant folder. The core never gets touched.

Step 4: asset replacement

Logos, favicons, login backgrounds, OG share images. I keep them all under /public/brand/<key>/ and let the env path point at the right one.

/public
  /brand
    /default/
      logo.svg
      favicon.ico
      login-bg.jpg
      og-image.png
    /apex/
      logo.svg
      favicon.ico
      login-bg.jpg
      og-image.png
    /riverside/
      logo.svg
      ...

Components just reference brand.assets.logo. The build copies the right folder. Done.

One thing that bit me early on: don't forget the OG/Twitter card image. I shipped a client and his Slack previews still showed the default logo for 3 days because I forgot to update app/opengraph-image.tsx. Get it right the first time so you're not chasing it later.

// app/opengraph-image.tsx
import { ImageResponse } from "next/og";
import { brand } from "@/lib/brand.config";

export default async function OG() {
  return new ImageResponse(
    (
      <div style={{ background: brand.colors.primary, display: "flex" }}>
        <h1 style={{ color: "white" }}>{brand.appName}</h1>
      </div>
    ),
    { width: 1200, height: 630 }
  );
}

Step 5: feature flags per tenant

This is the unlock. Some clients want the invoicing module. Some don't. Some want SMS sequences enabled. Some don't have an A2P approval yet so SMS would just error. Feature flags let you toggle entire modules without if (tenant === "x") mess.

// lib/features.ts
export type FeatureKey =
  | "invoicing"
  | "sms_sequences"
  | "pipeline_automations"
  | "client_portal"
  | "ai_replies";

const flagEnv = process.env.NEXT_PUBLIC_FEATURE_FLAGS ?? "";
const enabled = new Set(
  flagEnv.split(",").map((s) => s.trim()).filter(Boolean)
);

export function feature(key: FeatureKey): boolean {
  return enabled.has(key);
}

# Apex .env
NEXT_PUBLIC_FEATURE_FLAGS="invoicing,client_portal,pipeline_automations"

# Riverside .env (no SMS yet, no invoicing)
NEXT_PUBLIC_FEATURE_FLAGS="client_portal,ai_replies"

Then in your nav, your routes, your settings UI...

{feature("invoicing") && (
  <NavItem href="/invoices" icon={Receipt}>Invoices</NavItem>
)}

{feature("sms_sequences") && <SmsSequenceBuilder />}

You can take this further with per-tenant config in your DB if you want flags to be toggleable at runtime. For SMB white-label work, env-level flags are usually enough and they're WAY easier to reason about.

Why I refuse to fork the core

I learned this from a client situation that could've gone really sideways. The setup: one client, two brands. The main brand was established and ranking. The sister brand had ZERO online presence, tumbleweeds-blowing-through-the-desert kind of nothing. We needed to spin up a second tenant fast, borrow from the existing brand's authority to bootstrap the new one, and not babysit two codebases while doing it.

Because the CRM was wired up like the steps above, deploying tenant #2 was literally:

Clone the repo
New .env
New /public/brand/sister/ folder
New deploy on a subdomain
Done

Maybe an hour, most of which was waiting for DNS. If I'd forked, I'd have been merging hotfixes across two repos for the rest of the year while trying to actually run a marketing campaign for the second brand. No thanks.

Forking feels productive in the moment because you can hack on the new client's code without breaking anyone else. But you've just signed yourself up to maintain N repos forever. The override layer takes one weekend to build and saves you that work for the entire lifespan of the product.

The one rule

If you find yourself reaching for git checkout -b client-acme to add a brand-specific feature... stop. Go back to the override layer and ask "is this a config thing, an asset thing, an email thing, or a feature flag thing?" 95% of the time, the answer is one of those four and your core never needs to know the client exists.

The other 5% is where you have an honest conversation with the client about whether the customization is worth the complexity, or whether they should just use the product as it stands. (Spoiler: it almost always is the latter, they just haven't been told no yet.)

My CRM source code ships with this override layer built in: env-driven branding, CSS-variable theming, email overrides, asset folders, and the feature flag system above, all already wired up. Link in profile if you want to see how it's structured.

Howdy!

Andrew Lee Jenkins — Tue, 12 May 2026 22:33:46 +0000

Hey, I'm Andrew. Engineer turned marketer turned engineer-again. Glen Allen, VA.

The short version: I spent over a decade in engineering and design consulting for Fortune 500 companies. Left to start a marketing agency for home service businesses (contractors, cleaners, HVAC, the trades). Spent years watching my clients get fleeced by SaaS vendors that triple their prices on renewal. Eventually got annoyed enough to start building the software myself.

What I'm building

Seedly CRM is a self-hosted, source-available CRM I sell as source code. One payment of $1,050, you own it forever. No per-seat fees, no monthly bill, no vendor holding your customer data hostage. Built for service businesses and the agencies that serve them.

Other things I ship (mostly WordPress-adjacent right now): a UTM lead-tracking dashboard, a bulk image processor, and a local-maps plugin called Maps Uncensored.

What I write about

Mostly building in public. Decisions behind Seedly, why I went source-available instead of SaaS, what breaks when you sell software to non-developers, the weird overlap between marketing infrastructure and developer tools.
Where else to find me

🌐 andrewleejenkins.com
🌱 seedlycrm.com
🎙️ Growth Unfiltered (podcast)
💼 LinkedIn
📺 YouTube