What to Customize
A map of the DirectoryLaunch codebase by upgrade cost — what is free to change, what will conflict when you merge a release, and what you should leave alone.
Everything here is yours to edit. But some edits cost you nothing at upgrade time and others cost you a merge conflict every release. Knowing which is which up front is the difference between a five-minute update and an afternoon.
Free — costs you nothing, ever
These never conflict, because they aren't in code you and we both edit.
| What | Where | How |
|---|---|---|
| Colours, typography, radius, shadows | Database | /admin/design → Theme |
| Card & page layouts, homepage sections | Database | /admin/design → Layout |
| Map projection & lighting | Database | /admin/design → Map |
| Categories, spheres, listings | Database | /admin |
| Blog posts | Database | /admin/changelog, /admin blog editor |
| Sponsors, promotions, social proof | Database | /admin/advertising, /admin/social-proof |
Anything you can change from the admin panel is stored in your Supabase project. Merges cannot touch it.
Protected — yours, kept automatically
Listed in .gitattributes with merge=ours. Once you've run pnpm setup:upstream, an
upstream merge keeps your version of these with no conflict at all:
- config/
- site.config.ts — brand, tagline, URLs, logos, contacts, socials, SEO
- platform.config.ts — which vertical you run
- features.config.ts — feature flags
- plans.config.ts — pricing tiers, Stripe price IDs
- directory.config.ts — page size, sorting, seed categories
- marketing.config.ts — ad banner copy
- pricing.config.ts — the cards on /pricing (prices come from plans.config.ts)
- advertising.config.ts — sponsor & promotion pricing
- payments.config.ts / email.config.ts / analytics.config.ts / i18n.config.ts
- messages/
- en.json — UI translations
- public/assets/ — logos, favicon, OG image
Keeping your version also means not getting new keys we add. Feature flags are handled
for you — config/features.config.ts holds only your overrides, and anything you have not
set falls back to config/defaults/features.defaults.ts, which is core and does update. So
a flag introduced by a release arrives with its intended value and your settings still win.
The other configs have no such fallback yet. After merging a release, skim ours for
additions: git diff HEAD...MERGE_HEAD -- config/site.config.ts
Will conflict — edit freely, expect a merge
Real code that you may well need to change, and that we also change. This is normal git; the
changelog marks these releases [ui] so you see them coming, and git rerere means a
conflict you resolve once stays resolved.
| File | Why you'd edit it |
|---|---|
app/(marketing)/faq/page.tsx | Your FAQ — the shipped copy is example content |
app/(marketing)/pricing/page.tsx | Layout only — the cards moved to config/pricing.config.ts |
app/(marketing)/terms/page.tsx | Your terms — the shipped text names our legal entity |
app/(marketing)/privacy/page.tsx | Your privacy policy |
app/(marketing)/help/page.tsx | Your help content |
components/layout/Header.tsx, Footer.tsx | Nav links, footer columns |
app/globals.css | Only for the pre-login default look — colours belong in /admin/design |
components/shared/DirectoryLaunchBadge.tsx | The "Built with DirectoryLaunch" badge — delete it and its two call sites if you don't want it |
terms, privacy and cookies ship as example text, not legal advice, and the terms
page names the boilerplate's own operator. Rewrite all three for your business.
Leave alone — take our version
Change these and every release becomes a manual merge, with no upside: the behaviour you want is almost always reachable through config or the admin panel instead.
- lib/ — business logic, Supabase layer, validations, payments
- app/api/ — every API route
- components/ui/ — Base UI primitives
- middleware.ts
- next.config.ts
- supabase/ — schema and migrations
- types/
Need behaviour that isn't there? Add a file rather than editing one. A new route under
app/(marketing)/, a new component in components/, a new helper in lib/ — new files never
conflict, because we don't have a version of them.
The rule, in one line
Configure what you can, add new files where you must, and edit shared files only when there's
no alternative. Then pnpm upgrade:check will keep telling you your merges are clean.