Our philosophy

Caputchin is built on one posture, seen from three sides: we are permissive with what you can do, open with how we do it, and minimal with what we keep. We gate the managed experience and how far a change travels, never the raw capability, and we hold nothing about your visitors because there is nothing we need.

This page lays out that stance. Customization is where you feel it most directly, so it leads, but the same belief runs through how we price, what we open-source, and what we refuse to collect.

The principle

We gate the dashboard experience and how far a change travels. We do not gate the raw capability.

Two questions decide which side of the line any customization falls on:

If you author it on your own page, it is yours for free. If you ask Caputchin to author it for you and serve it to every embed, that is the paid experience.

What every plan can do on its own page

These are open to all plans, including Solo, because they live on your page, not in our dashboard. Nothing here checks your tier.

Recolor the whole widget. The shell exposes its colors as CSS custom properties you can override from your own stylesheet. See Style the widget with CSS.
Restyle, relayout, or hide any part, including our branding. The widget renders in an open shadow root and exposes its structural pieces as CSS parts, so you can target and restyle them, or hide the brand block entirely. Also covered in Style the widget with CSS.
Hand-author a custom game skin and locale per embed. On the <caputchin-game> element you can pass an inline skin or locale object to override colors, assets, and strings for that one embed. It is a property of your own markup, so it works on any plan. See Skin a game and Customize a game's language.
Pick the language and theme. The locale and skin attributes select any bundled language or light and dark theme. See How the widget resolves its language and skin.

The open shadow root is a deliberate choice, not an oversight. It exists so this CSS surface works. We are not going to close it to protect a paywall, because that would break a documented feature for the developers we are trying to serve.

What the paid tiers add

The dashboard path is the same capability, made managed and given reach. This is what a tier buys:

Author once in the dashboard, serve to every embed. A change you make in the dashboard propagates to every widget mount across every page and site key, with no per-page CSS to copy and keep in sync. The free path is per-page and manual by nature.
Team and per-site scope. Dashboard customization resolves with a troop baseline and per-site-key overrides, so a team can set a brand once and override exceptions per key. A stylesheet has no notion of that scope.
Reach surfaces your CSS cannot. The hosted embed page that native apps load in a WebView is served by Caputchin, so you own no CSS or JavaScript on it. A dashboard-authored preset is the only way to brand that surface. See Mobile apps integration.
Do what a page genuinely cannot. Rewriting the shell's wording, repointing its brand-strip links, and swapping its logo cleanly are not reachable from a stylesheet at all. These are the genuine exclusives of white-labeling the widget.

Which axis sits at which tier (game configuration, game language and skin, and the widget shell) is summarized in the game customization tier table, with the widget shell, our top rung, covered in white-label.

Why we draw the line here

The split keeps two audiences happy at once without compromising either.

An advanced developer is never blocked. Everything they can express in CSS or in their own markup is theirs immediately, on the free plan, so the product does not get in the way of someone who knows what they want. A team buying a paid tier is paying for the part that is actually hard to do well by hand: authoring in one place, governing it across many sites, keeping it in sync, and reaching surfaces they do not control. That is real, ongoing value, and it is honest to charge for it.

It also means we never have to fight our own customers. We do not need anti-tamper, a closed shadow root, or a policy that forbids using the styling surface we document, because we are not pretending a free capability is a paid one. The capability is free. The convenience and the reach are the product.

White-label is the top of the ladder, not a wall

White-labeling is often read as the feature that finally lets you remove our branding. It is not. You could already hide our branding for free with one CSS rule. White-labeling is the top rung of the same ladder every other customization sits on: the dashboard-authored, served-everywhere version, plus the few things a page cannot do on its own, namely rewriting wording, repointing links, swapping the logo cleanly, and covering the hosted embed page native apps load in a WebView. It is more reach and less work, not a gate around something you were otherwise denied.

Open by default, all the way down

The permissiveness on this page is not a marketing posture. It is structural: the widget and the SDK you embed are open source, Apache-2.0 licensed, and developed in the open on GitHub. You can read every line of the code that runs on your visitors' pages, fork it, audit it, and open an issue or a pull request against it. Our first-party games are open source too.

We do this for two reasons. First, we have nothing to hide. A verification widget that asks for your visitors' trust should be inspectable, not a black box. Second, the developers who push the customization surface to its limits are exactly the people we learn from. Stretching the CSS surface, hand-authoring a game skin, or building against the SDK contract: when that surfaces a rough edge or a missing hook, the fix can come straight back to us as a contribution. We reward advanced users with maximum flexibility, and we welcome them as contributors to the code itself.

The widget and SDK packages: github.com/Caputchin/caputchin-sdk.
First-party games, the Caputchin Core Pack: github.com/Caputchin/games.

Minimal by default

The same instinct that makes us open makes us minimal: we keep what we need and nothing more. We collect no data about the people solving your challenges. No IP, no User-Agent, no fingerprint, no behavioral telemetry. This is architectural, not a policy promise, because the widget protocol has nowhere to put a visitor identifier, so there is none to leak, subpoena, or sell. The game reaches the same end without profiling anyone: it re-derives whether a round was actually cleared rather than guessing from mouse paths and tap timing, which is the gaming anti-cheat stance.

For you, the customer, we hold the minimum an account needs: your email, your site key configuration, and an audit log of your own actions. Deletion is hard, with no soft-delete keeping a quiet copy. The full posture is in our Privacy Policy, and the same no-visitor-data rule carries through hosted verification.

Permissive, open, and minimal are one belief from three angles: we give you the most control we can, we show you exactly how it works, and we ask for the least we can in return.