BATCH STATUS · BONFIRE v1.0.1 · NO BLACK-BOX MAGIC CONSULTANCY · WHAT YOU BUY · HOW YOU LEAVE
CandyFactory product company · México ENES
§ CONSULTANCY · WHAT YOU BUY, AND HOW YOU LEAVE

You already have something running. Here is what you would be buying.

The method page explains how we attach to a system we did not write. This page answers what the engagement is, and what happens the day it ends.

Tell us what you have Read the method
§ WHAT YOU ARE BUYING

Three shapes. You can stop after any of them.

A bounded first look at your system. What it covers is agreed in writing before anything starts, and it does not commit you to anything after it.

The build, if you want one. We build inside the comprehension the first piece produced: in your repositories, under your accounts, through the review your team already uses. Scope and what done means are settled before we write anything.

Ongoing operation, if you want that. Hosting, monitoring, dependency upkeep, new work on a cadence you set. It is something you buy on purpose, never a subscription that switches itself on.

§ THE QUESTION NOBODY ASKS OUT LOUD

The day it ends, and what you walk away with.

Letting an outside team into your system usually means part of it stops being legible to you, and leaving gets expensive on purpose. So we write the exit down before the work starts, not when you ask for it.

YOURS

Your system, your data, your deliverable.

All three are named as yours in the contract before any work begins, and they go back to you in a state your own people can operate. Nothing is held back to make leaving hard.

OURS

Our engine leaves with us.

The tooling and the method we bring in are ours and stay ours. You are not renting our internals, and you are not buying a dependency on us.

NEVER OURS

We keep the method. Never your code.

What we take away is how we work. What we learned about your business goes to you in writing. It does not go into anybody else's project.

AN OPTION, NOT AN ASSUMPTION

Who maintains it afterwards is your call.

If you want your own team to carry it, they can: what we hand over when we detach is written down, and your own people can operate it without us. If you would rather we kept running it, that is a separate agreement you opt into. Being quiet about this is how a handover turns into a bill nobody agreed to.

§ HOW THE FIRST CONVERSATION STARTS

Start with what you have already written down.

Most operations are already half described in a project chat with somebody's own model. Our intake protocol is a plain text file you paste into that chat. It interviews you one question at a time and produces a spec bundle you read before you send anything. It is free and there is nothing to sign.

client-intake-protocol.md ~/your-project 
# CandyFactory · Client Intake Protocol
# Paste this into the project where your model
# already knows your business.

ROLE
  You are an intake interviewer for a software
  factory. Your job is to produce a complete,
  unambiguous specification of one business
  operation. You write down rules. You never
  invent them.

METHOD
  1. Read this whole project first. In five
     bullets, tell me what you already know about
     this business and its rules. Mark each
     [known] or [assumed].
  2. Interview me one question at a time. Wait
     for my answer before the next.
  3. Never guess. If an answer is ambiguous,
     re-ask, narrower, until it is a rule you
     could hand to a stranger.
  4. Prefer real examples over abstractions:
     "show me one real case."
  5. Treat exceptions as first-class. The edge
     cases are the product.
  6. Stop when a full pass surfaces no new rules.
     Do not pad.

DIGEST
  When the interview is done, emit the bundle
  below and nothing else, inside one code block,
  ready for me to inspect and send. Keep these
  five headers exactly as written, because the
  factory parses them verbatim.

  ## DOMAIN
    [one paragraph: what this operation is and
     the outcome it must produce]
  ## ENTITIES
    [the nouns: each with the fields that matter
     and who owns them]
  ## RULES
    [numbered, each one testable by a machine]
  ## EXCEPTIONS
    [the cases that break the rules, and what
     must happen instead]
  ## GLOSSARY
    [every term of art, defined the way your
     people use it]

GUARDRAILS
  - Nothing leaves this project until you copy
    the bundle out yourself.
  - If you are about to assume, stop and ask.
  - One question at a time. No filler.
Download .md plain text · ~1.6 kb

↳ the protocol, exactly as it runs.

▸ client-spec.bundle.md EXAMPLE
## DOMAIN

Quote approval for a mid size engineering firm. A request becomes a priced, signed quote without a partner re-keying anything twice.

## ENTITIES
  • Request · client, scope, site, received at (front desk)
  • Quote · line items, margin, validity, approver (estimator)
  • Client · tier A/B/C, terms, credit flag (finance)
## RULES
  1. Margin below 18% needs a partner's approval before send.
  2. Tier C clients are quoted prepaid only, never on net 30.
  3. Validity defaults to 30 days, and is never longer than 60.
  4. A revision supersedes the prior quote; the old PDF is archived, not deleted.
## EXCEPTIONS
  • Repeat client, same scope won in 90 days → reuse pricing, five minute partner glance.
  • Site outside the metro → add a travel line; never fold it into margin.
## GLOSSARY
  • Partner · a signing principal, not a senior engineer.
  • "Won" · client signed, not "verbally agreed."

↳ an illustrative bundle.

§ WHAT IS TRUE TODAY

We practice this on ourselves, and we will not pretend past that.

Why there are no logos on this page.

We have not yet attached to an outside company's system for hire, so there is nothing we could honestly show you there. The method is proven on our own work and offered outward. Where we do have clients, their work is theirs to publish, not ours.

What stands behind it is thirty years of building and running production software, written down as gates a machine enforces. You can read those gates: bonfire-ai on PyPI is the engine we build with, and the open repositories carry them inside.

§ OBJECTIONS, ANSWERED

The fears worth naming.

Where does my data go?
Nowhere you do not send it. The intake protocol runs inside your own model account, and your rules stay there until you copy the bundle out and send it.
How does pricing work?
We do not quote off a catalogue and we do not publish figures, because the first piece of work is shaped by what you already have. You tell us what you are running, we scope it with you, and you get a number for that specific piece before anything starts. You approve it, or you do not, and nothing has been built either way.
§ START ON YOUR SIDE OF THE TABLE

Tell us what you have. Not what you wish you had.

Start a conversation Get the intake protocol
● WHAT YOU KEEP IS NAMED BEFORE WORK STARTS  ·  ● YOUR SYSTEM LEAVES WITH YOU  ·  ● MAINTENANCE IS AN OPTION, NOT AN ASSUMPTION  ·  ● NO REWRITE · NO MIGRATION  ·  ● bonfire-ai ON PYPI  ·  ● WHAT YOU KEEP IS NAMED BEFORE WORK STARTS  ·  ● YOUR SYSTEM LEAVES WITH YOU  ·  ● MAINTENANCE IS AN OPTION, NOT AN ASSUMPTION  ·  ● NO REWRITE · NO MIGRATION  ·  ● bonfire-ai ON PYPI  ·