> ## Documentation Index
> Fetch the complete documentation index at: https://belajarkoding.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Feature by feature

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

<Info>
  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.
</Info>

## 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](/en/kilatkoding/features/landing-and-marketing-pages): public pages such as the landing page, CTAs, legal pages, and marketing content.
* [Contact form](/en/kilatkoding/features/contact-form): contact flow, email requirements, and when it is better to disable it.
* [Waitlist](/en/kilatkoding/features/waitlist): pre-launch funnel, demand validation, and how it connects to the landing page.
* [Blog and MDX content](/en/kilatkoding/features/blog-and-mdx-content): content structure, SEO content, and what to clean up during rebranding.
* [Roadmap, status, open startup, and changelog](/en/kilatkoding/features/public-updates): public communication and transparency surfaces.

### Logged-in product area

* [Auth](/en/kilatkoding/features/auth): login, signup, Magic Link, OAuth, callbacks, and redirect behavior.
* [User dashboard](/en/kilatkoding/features/user-dashboard): the post-login workspace, dashboard navigation, and key user states.
* [Billing and payments](/en/kilatkoding/features/billing-and-payments): checkout, subscriptions, payment provider setup, webhooks, and billing flows.
* [AI features](/en/kilatkoding/features/ai-features): AI routes, providers, quotas, UX, and setup caveats.

### Operational area

* [Admin dashboard](/en/kilatkoding/features/admin-dashboard): internal panel, admin role, metrics, and operational workflows.
* [Email and communication](/en/kilatkoding/features/email-and-communication): welcome email, invoice email, contact email, and sender setup.
* [Testing and readiness](/en/kilatkoding/features/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.

<AccordionGroup>
  <Accordion title="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](/en/kilatkoding/use-cases), [Preset recipes by use case](/en/kilatkoding/preset-recipes), and [Launch checklists](/en/kilatkoding/launch-checklists).
  </Accordion>

  <Accordion title="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](/en/kilatkoding/services-setup), [Environment variables](/en/kilatkoding/environment-variables), and [API reference](/en/kilatkoding/api-reference).
  </Accordion>

  <Accordion title="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](/en/kilatkoding/components-and-ui), [Database map](/en/kilatkoding/database-map), and [No-code vs developer](/en/kilatkoding/no-code-vs-developer).
  </Accordion>

  <Accordion title="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](/en/kilatkoding/ai-and-tooling), [End-to-end flows](/en/kilatkoding/end-to-end-flows), and [Operational runbook](/en/kilatkoding/operational-runbook).
  </Accordion>

  <Accordion title="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](/en/kilatkoding/rebranding-recipes), [Customization](/en/kilatkoding/customization), and [Testing and deployment](/en/kilatkoding/testing-and-deployment).
  </Accordion>
</AccordionGroup>

## 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](/en/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](/en/kilatkoding/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](/en/kilatkoding/preset-recipes) |
| Is AI a core part of the product rather than a small add-on?                    | Yes            | Subscription AI SaaS                                    | [AI and tooling](/en/kilatkoding/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](/en/kilatkoding/operational-runbook)   |
| Will this project be reused for multiple clients?                               | Yes            | White-label base for agencies                           | [Rebranding recipes](/en/kilatkoding/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.

<Tip>
  If you want to start from the route and endpoint map first, open [Features and routes](/en/kilatkoding/features-and-routes). If you want to see how env toggles affect each product area, continue to [Feature toggle matrix](/en/kilatkoding/feature-toggle-matrix). Then open the most relevant dedicated feature page from the list above.
</Tip>