Nos conectamos a lo que ya tienes.
Repositorios, backend, infraestructura, en el estado en que estén. Sin reescritura. Sin migración a nuestro stack. Sin "primero, reemplaza todo". No paras tu operación para que nosotros podamos empezar la nuestra.
MÉTODO · CÓMO TOMAMOS UN PROYECTO
No importa lo que ya tengas corriendo. Nos acoplamos a eso, y construimos ahí dentro.
Ya tienes un sistema. Repositorios que escribió alguien más, un backend que nadie recuerda por completo, infraestructura que funciona y que no se puede detener. La respuesta de siempre es que hay que reemplazarlo antes de poder meter algo nuevo. Esa es la frase que venimos a borrar.
LA PARTE QUE TODOS ESQUIVAN
La industria insiste en reescribir porque comprender el sistema de alguien más cuesta más que volver a construirlo.
Por eso te siguen diciendo que empieces de cero.
Leer el código de alguien más es lento, poco vistoso y difícil de cotizar, así que la industria prefiere no tocarlo y proponer una reescritura completa. Todos los días se rechazan proyectos cuyo único problema es que ya existen.
Nuestro método va directo contra ese costo. Tratamos la comprensión como un trabajo de ingeniería, con sus propias herramientas y sus propias compuertas, no como algo que una persona deba absorber leyendo durante tres semanas. Cuando comprender sale barato, tomar tu sistema tal como está deja de ser la opción cara. Ese es todo el argumento.
LOS CUATRO TIEMPOS
Acoplar. Comprender. Construir. Desacoplar.
Tu sistema se vuelve una capa en nuestro grafo.
Lo recorremos pieza por pieza y dejamos por escrito lo que encontramos, con estructura: qué llama a qué, qué parte es dueña de cada dato, dónde están enterrados los supuestos. Con eso, tu sistema deja de vivir únicamente en la cabeza de una persona. Donde haga falta un conector o un parser para llegar ahí, lo escribimos.
Este es el paso que nadie más da, y por eso podemos tomar proyectos que otros rechazan.
Construimos dentro de la comprensión.
Lo nuevo lo construimos sobre esa comprensión, y nuestras compuertas se ejecutan todo el tiempo. Las pruebas van primero: las escribe un agente de pruebas, y un agente distinto escribe el código que tiene que pasarlas. Un tercero verifica el resultado por su cuenta, y nada se integra hasta que la suite completa pasa con los cambios ya integrados, no solo sobre la rama aislada.
Te quedas con lo que el contrato dice que es tuyo. Nuestro motor se va con nosotros.
Tu sistema se va contigo.
LA SALIDA, ESCRITA ANTES DE QUE LA PIDAS
Acoplarse no es lo mismo que quedar amarrado.
El miedo que nadie dice en voz alta.
Cuando dejas entrar a un equipo externo, casi siempre una parte de tu sistema deja de ser legible para ti, y salirse resulta caro por diseño. Es un miedo razonable. Por eso no arrancamos el trabajo hasta que la salida esté por escrito.
Este es nuestro compromiso. Tu código, tus datos y tu sistema en operación quedan asentados como tuyos en el contrato antes de que empiece el trabajo, y se van contigo en un estado que tu propia gente puede operar. Lo que se va con nosotros es nuestro propio motor: las herramientas y el método con los que llegamos.
No estás comprando una dependencia. Estás contratando nuestra capacidad por un tiempo definido.
LA ENTREGA
Qué recibes exactamente.
Software funcionando en tus propios repositorios, sobre tu propia infraestructura y en tus propias cuentas. Pasa por el mismo proceso de revisión que tu equipo ya tiene, así que nada llega sin que tu gente lo haya visto.
Junto con eso: las pruebas que lo sostienen, escritas para que las entienda quien las herede, y la comprensión de tu sistema documentada, en un formato que tus ingenieros puedan seguir usando cuando ya no estemos. Esa comprensión suele ser justo la parte que se va con el proveedor. Aquí se queda contigo.
LO QUE ES CIERTO HOY
Lo aplicamos sobre nosotros mismos, todo el tiempo.
El método es la forma en que construimos nuestro propio software, incluida esta página. Las compuertas se ejecutan en cada cambio nuestro y nos frenan cuando el trabajo no está bien. Nada sale sin que una persona lo autorice.
Lo que respalda eso es público, para que lo verifiques en lugar de creernos de palabra: bonfire-ai en PyPI es el motor con el que construimos, y los repositorios abiertos traen esas compuertas adentro, donde las puedes leer. El equipo de agentes que hace el trabajo es real, y lo ponemos a correr frente a ti.
Lo que no te vamos a decir es que ya hicimos esto con el sistema de otra empresa, por contrato. No lo hemos hecho. El método está probado en nuestro propio trabajo y así lo ofrecemos. Cuando eso cambie, cambia este párrafo.
QUIÉN HACE ESTO
Detrás hay treinta años de software en producción.
El método no es una teoría que llegó con los modelos. Es lo que queda de tres décadas construyendo sistemas que no se podían caer, en negocios donde una caída costaba dinero. Los agentes son nuevos. La disciplina que obedecen no lo es.
La versión larga está en la página Acerca de.
EL VOCABULARIO DE LA FÁBRICA
Nunca vas a tener que aprender nada de esto.
La fábrica tiene partes con nombre, porque a una parte con nombre se le pueden escribir pruebas. Bonfire es el motor abierto. CandyFactory OS es el sustrato. El Constable vigila la deriva, el Prophet escribe en público, CandyCane acelera la revisión.
Nada de eso es vocabulario que necesites para trabajar con nosotros. Si de todos modos quieres el diagrama, está en la página principal, y el motor tiene su propia página en Bonfire.
EMPECEMOS POR TU LADO DE LA MESA
Cuéntanos qué tienes.
No lo que te gustaría tener. Mientras más desordenada sea la descripción, más nos sirve, porque el desorden es justamente lo que estamos equipados para leer.