Keep your own consent design without building every layer from scratch. Compare c15t with a custom implementation, including AI-assisted code.

Get started

Choose c15t when your team wants a custom consent experience with a supplied engine, framework components and backend. Your developers can focus on how consent fits the product.

A custom implementation can match these features. The difference is which parts your team must design, test and support. This comparison includes code written by people or with AI assistance.

What you need	With c15t	With your own implementation
Show a consent interface	Use framework components or build a custom UI through headless APIs	Build the banner, preference controls and application state
Separate permissions from choices	A shared consent model distinguishes the two	Define what each state means and which events record a choice
Offer category and vendor choices	Configure the supplied preference controls and vendor rules	Design the choice model and connect it to each vendor
Control scripts, requests and embeds	Register supported integrations and explicit rules	Build or adopt controls for each way that a vendor can run
Resolve policy for a visitor	Configure policy rules and the fallback for unknown locations	Build policy selection, fallback behaviour and policy updates
Store remote records	Inth hosts the backend and stores records in its database. Self-hosting is optional	Build or adopt record storage, delivery and recovery from failures
Support server output	Follow the selected framework's server or browser path	Handle initial state, hydration and saved choices in each framework
Handle withdrawal	Use the runtime's withdrawal flow and configured cleanup	Define how each vendor stops and which data your code can remove
Support future changes	Review c15t updates and test your integrations	Own updates across the implementation and its dependencies

The c15t column still needs setup and tests. It describes reusable software, not a completed consent deployment.

AI can help you write a banner, a custom consent system or an integration with c15t. Your team still owns the design decisions and checks the result.

The useful comparison is the complete visitor flow. A button that saves a cookie covers only part of it.

Check a fresh visit, a saved refusal, a later change of mind and a failed backend save. Also check navigation, policy changes and each vendor's behaviour.

For example, a banner can save a refusal while a separate analytics script still runs. Both a custom implementation and c15t need that unconditional loader removed.

Use AI to build your product's interface on c15t's headless APIs. You keep control of the design and reuse the consent model underneath it.

Get started

docs/comparisons/build-your-own.md