Caputchin
Entender Caputchin

Nuestra filosofía

Caputchin se construye sobre una postura, vista desde tres lados: somos permisivos con lo que puedes hacer, abiertos con cómo lo hacemos, y mínimos con lo que guardamos. Ponemos gate a la experiencia gestionada y a cuán lejos viaja un cambio, nunca a la capacidad en bruto, y no retenemos nada sobre tus visitantes porque no hay nada que necesitemos.

Esta página expone esa postura. La personalización es donde la sientes más directamente, así que va primero, pero la misma creencia recorre cómo ponemos precio, qué hacemos open-source, y qué nos negamos a recoger.

El principio

Ponemos gate a la experiencia del dashboard y a cuán lejos viaja un cambio. No ponemos gate a la capacidad en bruto.

Dos preguntas deciden de qué lado de la línea cae cualquier personalización:

Si lo creas en tu propia página, es tuyo gratis. Si pides a Caputchin que lo cree por ti y lo sirva a cada incrustación, esa es la experiencia de pago.

Lo que cada plan puede hacer en su propia página

Estos están abiertos a todos los planes, incluido Solo, porque viven en tu página, no en nuestro dashboard. Nada aquí comprueba tu nivel.

  • Recolorea todo el widget. El shell expone sus colores como CSS custom properties que puedes sobrescribir desde tu propia hoja de estilos. Mira Estila el widget con CSS.
  • Reestiliza, redistribuye u oculta cualquier part, incluida nuestra marca. El widget se renderiza en un shadow root abierto y expone sus piezas estructurales como CSS parts, así que puedes apuntar a ellas y reestilarlas, o ocultar el bloque de marca por completo. También cubierto en Estila el widget con CSS.
  • Crea a mano un skin y locale de juego a medida por incrustación. En el elemento <caputchin-game> puedes pasar un objeto de skin o locale inline para sobrescribir colores, assets y cadenas para esa única incrustación. Es una propiedad de tu propio markup, así que funciona en cualquier plan. Mira Skin de un juego y Personaliza el idioma de un juego.
  • Elige el idioma y el tema. Los atributos locale y skin seleccionan cualquier idioma incluido o tema claro y oscuro. Mira Cómo el widget resuelve su idioma y skin.

El shadow root abierto es una elección deliberada, no un descuido. Existe para que esta superficie CSS funcione. No vamos a cerrarlo para proteger un muro de pago, porque eso rompería una función documentada para los desarrolladores a los que intentamos servir.

Lo que añaden los niveles de pago

El camino del dashboard es la misma capacidad, hecha gestionada y dotada de alcance. Esto es lo que compra un nivel:

  • Crea una vez en el dashboard, sirve a cada incrustación. Un cambio que haces en el dashboard se propaga a cada montaje del widget en cada página y clave de sitio, sin CSS por página que copiar y mantener en sincronía. El camino gratuito es por página y manual por naturaleza.
  • Alcance de equipo y por sitio. La personalización del dashboard se resuelve con una base de equipo y overrides por clave de sitio, así que un equipo puede fijar una marca una vez y sobrescribir excepciones por clave. Una hoja de estilos no tiene noción de ese alcance.
  • Alcanza superficies que tu CSS no puede. La página de incrustación alojada que las apps nativas cargan en un WebView la sirve Caputchin, así que no posees CSS ni JavaScript en ella. Un preset creado en el dashboard es la única forma de marcar esa superficie. Mira Integración en apps móviles.
  • Haz lo que una página genuinamente no puede. Reescribir el texto del shell, reapuntar los enlaces de su franja de marca, y cambiar su logo limpiamente no son alcanzables desde una hoja de estilos en absoluto. Estos son los exclusivos genuinos del white-label del widget.

Qué eje se asienta en qué nivel (configuración de juego, idioma y skin de juego, y el shell del widget) se resume en la tabla de niveles de personalización de juego, con el shell del widget, nuestro peldaño más alto, cubierto en white-label.

Por qué trazamos la línea aquí

La división mantiene felices a dos públicos a la vez sin comprometer a ninguno.

Un desarrollador avanzado nunca queda bloqueado. Todo lo que puede expresar en CSS o en su propio markup es suyo de inmediato, en el plan gratuito, así que el producto no se interpone en el camino de alguien que sabe lo que quiere. Un equipo que compra un nivel de pago paga por la parte que de verdad es difícil de hacer bien a mano: crear en un solo sitio, gobernarlo entre muchos sitios, mantenerlo en sincronía, y alcanzar superficies que no controlan. Eso es valor real y continuo, y es honesto cobrar por ello.

También significa que nunca tenemos que pelear con nuestros propios clientes. No necesitamos anti-tamper, un shadow root cerrado, ni una política que prohíba usar la superficie de estilado que documentamos, porque no estamos fingiendo que una capacidad gratuita es de pago. La capacidad es gratuita. La conveniencia y el alcance son el producto.

El white-label es la cima de la escalera, no un muro

El white-labeling se lee a menudo como la función que por fin te deja quitar nuestra marca. No lo es. Ya podías ocultar nuestra marca gratis con una regla de CSS. El white-labeling es el peldaño más alto de la misma escalera en la que se asienta cualquier otra personalización: la versión creada en el dashboard y servida en todas partes, más las pocas cosas que una página no puede hacer por su cuenta, a saber reescribir el texto, reapuntar enlaces, cambiar el logo limpiamente, y cubrir la página de incrustación alojada que las apps nativas cargan en un WebView. Es más alcance y menos trabajo, no un gate alrededor de algo que de otro modo te era negado.

Abierto por defecto, hasta el fondo

La permisividad de esta página no es una postura de marketing. Es estructural: el widget y el SDK que incrustas son open source, con licencia Apache-2.0, y desarrollados en abierto en GitHub. Puedes leer cada línea del código que corre en las páginas de tus visitantes, forkearlo, auditarlo, y abrir un issue o un pull request contra él. Nuestros juegos de primera parte también son open source.

Hacemos esto por dos razones. Primero, no tenemos nada que ocultar. Un widget de verificación que pide la confianza de tus visitantes debería ser inspeccionable, no una caja negra. Segundo, los desarrolladores que llevan la superficie de personalización a sus límites son exactamente las personas de las que aprendemos. Estirar la superficie CSS, crear a mano un skin de juego, o construir contra el contrato del SDK: cuando eso saca a la luz un borde áspero o un gancho que falta, el arreglo puede volver directo a nosotros como una contribución. Recompensamos a los usuarios avanzados con la máxima flexibilidad, y los acogemos como contribuidores al propio código.

Mínimo por defecto

El mismo instinto que nos hace abiertos nos hace mínimos: guardamos lo que necesitamos y nada más. No recogemos ningún dato sobre las personas que resuelven tus retos. Ni IP, ni User-Agent, ni huella, ni telemetría de comportamiento. Esto es arquitectónico, no una promesa de política, porque el protocolo del widget no tiene dónde poner un identificador de visitante, así que no hay ninguno que filtrar, citar judicialmente o vender. El juego llega al mismo fin sin perfilar a nadie: vuelve a derivar si una ronda se superó realmente en vez de adivinar de trayectorias de ratón y temporización de toques, que es la postura del anti-trampas de videojuego.

Para ti, el cliente, retenemos el mínimo que una cuenta necesita: tu correo, la configuración de tu clave de sitio, y un audit log de tus propias acciones. La eliminación es dura, sin soft-delete que guarde una copia silenciosa. La postura completa está en nuestra Política de Privacidad, y la misma regla de cero-datos-de-visitante recorre la verificación alojada.

Permisivo, abierto y mínimo son una creencia desde tres ángulos: te damos el mayor control que podemos, te mostramos exactamente cómo funciona, y pedimos lo menos que podemos a cambio.

Véase también

En esta página