Feature by feature

Use this page as the index for comprehensive one-file-per-feature documentation.

This page now works as an index. Every major KilatKoding feature has its own dedicated documentation file so the explanation can stay more complete, easier to scan, and easier to maintain over time.

How to use this page

1. Use the quick map below to find the feature area that matches your product.
2. Open the dedicated feature page for the full explanation.
3. If you are still unsure which combination fits, use the feature combinations and decision matrix sections first.

Each dedicated feature page now includes deeper documentation such as:

• what the feature includes
• who uses it
• main dependencies and the env values that usually matter
• routes or flows that are commonly involved
• where teams usually customize it
• when the feature should be disabled or simplified
• a validation checklist after changes

Quick feature map

Feature	Who uses it	Main dependencies	Where it is usually customized
Landing page and marketing pages	Public visitors	Page content and config	copy, CTA, visuals, legal
Auth	Logged-in users	Supabase public env and callback URLs	login flow, copy, providers, redirects
User dashboard	Logged-in users	Auth enabled	menu, product data, empty states
Billing and payments	Paying users or trial users	Payment provider, service role, auth	pricing, plans, checkout flow
Admin dashboard	Internal operators	admin role, auth, service role	metrics, role flow, operations
Contact form	Public visitors	NEXT_PUBLIC_ENABLE_CONTACT, Resend	sender, inbox target, form copy
Waitlist	Public visitors	NEXT_PUBLIC_ENABLE_WAITLIST, Supabase	CTA, validation copy, launch funnel
Blog and MDX content	Public visitors	Blog content files	articles, taxonomy, SEO content
AI features	Users who use AI	NEXT_PUBLIC_ENABLE_AI, AI provider	prompts, UX, limits, monetization
Email and communication	Users and operators	Resend and email templates	sender, templates, triggers
Roadmap, status, open startup, changelog	Public visitors	Config and page content	public messaging, transparency, positioning
Testing and readiness	Developers and operators	env, build, Playwright, CI	smoke tests, regression checks, deploy gate

Dedicated feature pages

Public-facing area

• Landing page and marketing pages: public pages such as the landing page, CTAs, legal pages, and marketing content.
• Contact form: contact flow, email requirements, and when it is better to disable it.
• Waitlist: pre-launch funnel, demand validation, and how it connects to the landing page.
• Blog and MDX content: content structure, SEO content, and what to clean up during rebranding.
• Roadmap, status, open startup, and changelog: public communication and transparency surfaces.

Logged-in product area

• Auth: login, signup, Magic Link, OAuth, callbacks, and redirect behavior.
• User dashboard: the post-login workspace, dashboard navigation, and key user states.
• Billing and payments: checkout, subscriptions, payment provider setup, webhooks, and billing flows.
• AI features: AI routes, providers, quotas, UX, and setup caveats.

Operational area

• Admin dashboard: internal panel, admin role, metrics, and operational workflows.
• Email and communication: welcome email, invoice email, contact email, and sender setup.
• Testing and readiness: env checks, health checks, tests, and launch verification.

Most common feature combinations

If you do not want to choose every feature from scratch, start from the combination that is closest to your product.

Waitlist first, full app later

• Features usually enabled: landing page, waitlist, optional contact, blog, roadmap, and status.
• Features usually disabled: auth, dashboard, payments, admin, and AI.
• Why this combination is safe: you can validate demand faster without preparing every product area at once.
• What still needs cleanup: login CTA paths, subscription pricing, and any copy that promises the full app too early.
• Read next: KilatKoding use cases, Preset recipes by use case, and Launch checklists.

Classic subscription SaaS

• Features usually enabled: auth, user dashboard, billing, payments, admin, landing page, and contact.
• Features usually optional: waitlist, blog, roadmap, status, and AI.
• Why this combination is natural: this is the KilatKoding shape that is closest to a default SaaS boilerplate path.
• What still needs cleanup: pricing, plan benefits, upgrade flow, webhooks, and the admin metrics that actually matter for operations.
• Read next: Services setup, Environment variables, and API reference.

Member or client portal

• Features usually enabled: auth, user dashboard, settings, a simpler landing page, and optional blog.
• Features usually disabled: payments, public checkout, AI, and admin if it is not needed yet.
• Why this combination fits: the product value lives in the gated area, not in public checkout.
• What still needs cleanup: dashboard menus, permissions, public CTA copy, and pricing areas that could confuse users.
• Read next: Components and UI, Database map, and No-code vs developer.

Subscription AI SaaS

• Features usually enabled: auth, user dashboard, payments, admin, AI features, landing page, and billing.
• Features usually optional: waitlist, contact, blog, open startup, and roadmap.
• Why this combination makes sense: users need accounts, plans, and quota-aware AI usage as part of the core product.
• What still needs cleanup: per-plan quotas, AI error states, AI pricing, cost awareness, and support flow when the provider fails.
• Read next: AI and tooling, End-to-end flows, and Operational runbook.

White-label base for agencies

• Features usually enabled: landing page, auth, a basic dashboard, contact, email, and sometimes payments depending on the client.
• Features usually disabled: any modules the client did not buy, including AI, waitlist, or admin when not needed.
• Why this combination is efficient: you start from one stable foundation, then shrink or expand the feature set based on the client scope.
• What still needs cleanup: branding, legal pages, sender email, placeholder content, navigation, and any user path the client will not use.
• Read next: Rebranding recipes, Customization, and Testing and deployment.

Quick decision matrix

If you want an even faster shortcut, use this table. Start with the biggest questions around login, payments, AI, and who will operate the product.

Main question	Closest answer	Combination that usually fits	Read next
Is the product not fully open yet and you mainly want to validate demand first?	Yes	Waitlist first, full app later	KilatKoding use cases
Do users need to log in to use the core product?	Yes	Member or client portal, subscription SaaS, or AI SaaS	No-code vs developer
Do users need to pay to unlock access or plans?	Yes	Classic subscription SaaS or paid AI SaaS	Preset recipes by use case
Is AI a core part of the product rather than a small add-on?	Yes	Subscription AI SaaS	AI and tooling
Do you need an internal operations panel for revenue, roles, or webhooks?	Yes	Classic subscription SaaS or AI SaaS with admin enabled	Operational runbook
Will this project be reused for multiple clients?	Yes	White-label base for agencies	Rebranding recipes

How to read this matrix

1. If your first answer is “the product is not fully open yet,” it is usually safer to start with a waitlist than to enable everything.
2. If the product needs login but does not need public payments, the path is usually closer to a member or client portal.
3. If the product needs both login and payments, the path is usually closer to a classic subscription SaaS.
4. If the product needs login, payments, and AI as a core value driver, the path is usually closer to a paid AI SaaS.
5. If the main need is fast delivery across different client projects, the white-label base is usually the more efficient path.

If you want to start from the route and endpoint map first, open Features and routes. If you want to see how env toggles affect each product area, continue to Feature toggle matrix. Then open the most relevant dedicated feature page from the list above.