cells

bids and budgets

when a cell wins a project, their bid establishes a monthly cap — the maximum they can draw from the cooperative treasury each month for that project.

cells never work on spec. once a project is selected, the cycle works like this:

1. plan — the cell submits next month's planned budget by category (labor, hosting, tools, admin). drawn against the monthly cap.
2. review — the board reviews and approves against the project's pledge revenue. budgets at or below the original bid cap are auto-approved.
3. pay — the cooperative pays the cell upfront on the 1st. no net-30. no invoicing. no cash flow anxiety.
4. build — the cell does the work. code must pass automated quality gates (testing, IP provenance scanning, documentation, maintainability) before each release.
5. report — at month's end, the cell reports spend by category. category-level summaries are visible to all members. the board reviews detailed line items.
6. reconcile — the cell's margin is the difference between their bid cap and their actual spend. that margin is the cell's money — theirs to keep, no questions asked. unspent project-level funds beyond the cell's contract roll forward as project runway.

cells bid a fixed monthly cap. the difference between what the cooperative pays and what the cell actually spends is the cell's margin — exactly like any fixed-bid contract. this is how agencies make money, and it's how cells make money here.

projects transition from build phase to maintenance phase once the core product ships. the cell that built the project has right of first refusal on the maintenance contract. maintenance budgets explicitly include on-call and incident response costs. SLA tiers are defined per project during scoping.

ip and ownership

source code produced under cooperative contracts is owned by the cooperative. cells retain rights to any code, libraries, or tools they created before the engagement or independently outside of it. internal tooling, build scripts, testing frameworks — the cooperative owns the deliverable product, not the means of production.

governance

cells are equal members of the cooperative on structural decisions. if a cell underperforms on a project, replacement requires a supermajority of the project's pledging members and board approval, triggered only by measurable performance failures (SLA breaches, quality gate failures, budget overruns) — not by competing bids or popularity contests. the incumbent cell has right of first refusal to match any competing bid.

the cooperative owns all production infrastructure — cloud accounts, domains, databases, secrets. cells are granted deploy and operate access. if a cell is replaced, access is revoked and granted to the incoming cell. no cell ever controls the keys to a member's data.

the software survives the cell. always. the infrastructure is cooperative-owned, the code is collectively owned, and transition-ready documentation is required. no lock-in. no single point of failure.

why cells join

the cooperative replaces your sales pipeline. no more pitching, no more proposals that go nowhere, no more chasing invoices. projects arrive pre-funded with committed business members. you get paid upfront on the 1st. you keep your margin. you own your tools. you earn recurring revenue from access fees — this share vests over time and persists even if you hand off maintenance. and you're a co-owner with a vote — not a vendor begging for the next contract.

becoming a cell

cell certification is administered by the board against published criteria — portfolio, references, insurance, quality gate compliance. existing cells do not gate new entrants. denied applicants have a formal appeals process. once certified, you're a full member of the cooperative with all the rights and responsibilities that entails.

cells are how software gets built without venture capital, without enterprise sales teams, and without extracting wealth from the people who need it most. if you can ship product, there's a seat at the table — as an equal.