# ⚙️ Band of Builders in practice Last updated: 2026-04-30 Version: 1.0.0 The **Band of Builders in Practice** document is one implementation of an operational framework and governance model that implements the [[Band of Builders philosophy]] This framework functions as a cooperative studio operating system. It defines how small teams (bands) form, execute projects, and distribute ownership. A short overview of how this works in practice: * We operate as a cooperative studio regardless of the legal wrapper. * Small bands form around useful, durable, non-extractive projects. * Every project explicitly covers structure, mechanism, impact, and attention. * Governance is distributed: member-level for foundational questions, project-level for execution. * Day-to-day authority is clear, reviewable, and documented. * IP is held centrally for coherence; economic participation is tracked per project. * Contribution persists; stewardship is active, reviewable, and rewarded. * Remote is the default; in-person is intentional. * Good faith is assumed, but systems are designed to expose bad faith early. * Money is treated as a condition for continuity, not as the purpose of the work. * The goal is to make things worth sustaining without consuming the people making them. - defaulting to remote work - separating centralized legal structures from decentralized human agreements - distributing economic upside based on cumulative contribution (60%) and active stewardship (40%) - using explicit, reviewable roles rather than permanent hierarchy to build useful, durable products **Note:** This is a working interpretation of the philosophy. If practice stops reflecting the core philosophy, the practice is changed. If repeated reality exposes a gap in the philosophy, the philosophy is revised explicitly. ## What this document is for This document exists to answer practical questions such as: * who can participate, and how * how bands form * how decisions get made * how projects start, continue, and stop * how contribution is recognized * how stewardship is rewarded * how conflict is handled * how trust is preserved under pressure Its purpose is not to eliminate judgment. Its purpose is to make judgment more legible, more consistent, and less vulnerable to manipulation. ## Purpose We exist to build useful, durable, non-extractive things with people we trust. In practice, that means we optimize for work that is: * cooperative by nature * remote by default and in-person by choice * small-band by default * product- and asset-biased over labor-for-hire * playful in exploration and disciplined in delivery * economically viable without depending on hidden sacrifice * designed for stewardship, not just launch ## Core operating assumptions ### 1. The legal structure is a wrapper The formal entity exists to do formal things: * sign contracts * hold IP * receive revenue * pay people * manage liability * satisfy compliance requirements * interface with institutions that expect an entity We will use whatever legal structure best enables the work. That structure is not the source of legitimacy. The real organization is the human system composed of: * the philosophy * the practice * the agreements we make * the roles we accept * the responsibilities we carry * the decisions we record * the ways we repair harm * the ways we share value ### 2. We operate as a cooperative studio Even if the legal wrapper is not a formal cooperative, we operate as a cooperative studio in practice. That means: * bands form around projects * contributors materially shape the work * stewardship counts alongside origination * upside is linked to contribution and care * nobody is treated as a disposable labor input * governance should remain close to the people affected by it ### 3. Governance is values made operational We do not use consensus everywhere. We do not use hierarchy everywhere. We do not pretend flatness removes power. We use the lightest governance that preserves: * clarity * accountability * speed * fairness * trust * quality * room for repair ## Participation model There are three default levels of participation. ### Contributors Contributors work on a project, initiative, or shared function. They may be: * short-term * long-term * part-time * specialized * experimental * invited for a specific need Contributors: * have clear scopes * are credited for what they materially do * participate in project decisions that affect their work * may earn project-level economic participation * do not automatically receive org-wide governance rights ### Members Members are ongoing stewards of the whole. Members: * carry governance responsibility * maintain the shared system, not only their own project * can form and join bands * participate in major studio decisions * are expected to uphold the philosophy in behavior, not just language Membership is not a status prize. It is an agreement to carry shared responsibility. ### Stewards Stewards are members holding explicit cross-org responsibilities for a defined period. Typical stewardship functions include: * finance * legal and admin * tooling and infrastructure * membership process * doctrine and practice upkeep * conflict process * archive and knowledge continuity Stewardship roles: * are explicit * have named responsibilities * are reviewable * should rotate when useful * do not create permanent rank ## Band shape Prefer bands of **3 to 6** people. Default heuristic: * 3 is essential * 4 is standard * 5 is full * 6 is orchestrated * beyond that, sub-bands or much clearer interfaces become necessary A band should be only as large as the work requires. ### Essential capacities Every meaningful piece of work must explicitly cover four capacities: * **Structure:** coordination logic, incentives, roles, pacing, interfaces, decision rights, and system coherence * **Mechanism:** implementation, architecture, operations, craft, and how the thing actually works * **Impact:** real-world effects, intended outcomes, unintended consequences, harms reduced, harms created, and who bears the cost * **Attention:** discovery, explanation, trust, interpretation, adoption, and the responsible handling of audience demand These are capacities, not mandatory separate headcount. In a small band, one person may carry more than one. What matters is that none of them are neglected. No project should proceed for long with one of these capacities unowned. ## Roles inside a band Every active project should have, at minimum: * **Project Lead** * holds the through-line of the project * keeps scope coherent * makes final day-to-day calls after input * ensures decisions are logged * is accountable for overall movement, not every task * **Capacity Accountables** * at least one named accountable person for each essential capacity * one person may hold multiple capacities in a small band * their job is to maintain standards, surface risks, and keep blind spots from becoming failures * **Contributors** * execute, shape, critique, improve, and maintain the work * are expected to act as co-makers, not passive ticket-fulfillers “Everyone writes songs” means everyone can materially shape the work. It does not mean everyone has equal authority on every question. ## Governance and decision rights We use four classes of decisions. | Decision class | Examples | Default method | |---|---|---| | Philosophy | mission, non-negotiables, foundational principles | member supermajority | | Studio governance | legal structure, budgets, membership rules, stewardship structure | member supermajority | | Project formation | whether to start, continue, pause, or stop a project | affected members plus committed band consent | | Project execution | roadmap, design, technical choices, launch timing, experiments | project lead after relevant input | ### Default thresholds * **Philosophy changes**: 80% of members * **Practice changes**: 75% of members * **New member admission**: 75% of members after trial process * **Project launch using shared resources**: consent of the committed band plus approval from relevant stewards * **Day-to-day project calls**: project lead decides after consulting affected capacity accountables * **Emergency legal, security, or harm-reduction calls**: the nearest responsible person acts immediately, then records the decision within 24 hours ### Vetoes A veto is rare and must be specific. A veto is valid only when a person can clearly show one of the following: * legal exposure * serious ethical violation * material financial risk to the studio * direct contradiction of philosophy * unreasonable security or maintenance burden being imposed without consent * major harm risk to users, contributors, or the organization A valid veto must include: * the reason * the likely consequence if ignored * a workable alternative when possible Vetoes are not preference weapons. ## How projects start A project may begin from any member and, in some cases, from a contributor sponsored by a member. Every proposal should answer: * What problem are we solving? * For whom? * Why does it matter now? * Why are we well-positioned to do it? * What would make it useful rather than merely interesting? * How does it reduce exploitation or avoid creating new forms of it? * What is the smallest viable version? * What would make it economically self-sustaining? * Can a small remote band build and maintain it? * What are the obvious risks? ### Greenlight criteria A project moves forward when: * at least 2 committed people want to build it * the four essential capacities are explicitly covered * the maintenance burden is believable * there is a plausible path to usefulness * there is a plausible path to viability * it does not violate the philosophy * it has a named project lead * it has a written first-stage scope ### Project stages Every project exists in one of five stages. | Stage | Meaning | |---|---| | Seed | framing, research, problem definition | | Incubation | prototyping, validation, first tests | | Active | actively built, launched, sold, or deployed | | Sustain | stable, maintained, and improving gradually | | Sunset | archived, wound down, sold, open-sourced, or ended | A project should never live in permanent ambiguity. Its stage should be explicit. ### Stage reviews A project changes stage only through a documented review that answers: * what was learned * what changed * what risks remain * whether the original case still holds * whether the team still wants to carry it * whether the economics still make sense ## Product and customer filter We do not build everything we could build. A project should be rejected if it primarily depends on: * deception * dark patterns * surveillance as a business model * addiction loops * prestige without utility * hidden-value extraction * endless custom work with no path to leverage * growth that requires ethical self-betrayal * maintenance obligations that obviously exceed probable value A project is more attractive when it: * solves a real and felt problem * creates compounding value * can be explained simply * respects user attention * reduces hidden costs for others * improves through stewardship * can become durable with bounded maintenance * remains worth building even if it becomes moderately successful rather than massively famous ## Contribution, ownership, and economics This is the most important system to keep explicit. ### Legal ownership By default, the legal entity owns project IP so the work can be managed coherently. This avoids: * fragmented control * unworkable licensing ambiguity * dead cap-table-like fragmentation * projects becoming impossible to maintain, transfer, or sell Legal ownership is about coherence of control. It is not, by itself, the same thing as fair economic participation. ### Economic participation Economic participation is tracked primarily at the **project level**. Each project should maintain: * a named band * a project record * a split sheet * a contribution ledger * a stewardship record * a reserve policy * a decision log ### The default value model Our default principle is: **Contribution is measured by consequence, care, and stewardship.** That means we recognize value through: * what is originated * what is built * what is clarified * what is improved * what is maintained * what is protected * what is made possible * what risk is reduced * what burden is absorbed * what trust is created or preserved Hours may inform judgment. They do not define value. ### Default split model v1 For each project’s distributable contributor pool: * **60%** is allocated by cumulative contribution * **40%** is allocated by active stewardship This split exists to reward both creation and continuity. #### Cumulative contribution Cumulative contribution reflects meaningful past work such as: * origination * design * engineering * systems work * customer development * writing * launch work * key relationship creation * essential problem solving * decision-making labor that materially shaped the project This share persists after someone steps back unless a prior written agreement says otherwise. #### Active stewardship Active stewardship reflects current responsibility such as: * maintenance * support * updates * compliance * operations * iteration * documentation * attention stewardship * user relationship care * infrastructure upkeep This share is recalculated on a regular cadence and decays when stewardship stops. That gives us both: * enduring credit for real creation * ongoing reward for real maintenance ### Future contributor reserve At project formation, a portion of the project split should remain unassigned for future contributors. Default range: **10% to 20%**, depending on project stage and uncertainty. This prevents founders from behaving as if all meaningful value has already been created. ### Revenue waterfall Revenue is distributed in this order: 1. taxes, fees, refunds, and direct costs 2. studio operating reserve 3. project maintenance reserve 4. contributor distributions according to the project ledger 5. strategic reinvestment when explicitly approved Reserve levels should be set per project and reviewed quarterly. ### Contribution review cadence Contribution ledgers should not be updated continuously by vague sentiment. They should be reviewed on a clear cadence. Default: * light update monthly for active projects * formal review quarterly * special review at major stage changes * freeze and reconciliation at exit, sale, or sunset ### When hours are used Hours may be logged for: * planning * estimating * budgeting for client work * legal or compliance needs * postmortem learning Hours should not silently become the moral unit of the organization. ## Communication norms We are remote by default, so clarity is part of the craft. ### Default communication rules * write important things down * prefer asynchronous communication for non-urgent matters * make decisions legible * keep documents close to the work * do not rely on memory for significant agreements * use meetings to resolve, not to discover what should already exist in writing * distinguish draft thinking from committed decisions ### Meeting defaults Each active band should have: * **Weekly band sync** * priorities * blockers * decisions needed * scope changes * **Weekly build or review session** * show work * test assumptions * request critique * adjust direction * **Monthly steward sync** * finances * legal and admin * tooling * member health * cross-project issues * **Quarterly reset** * project review * philosophy-practice tension check * role refresh * sustainability review * optional in-person gathering Meetings should be small, clear, and necessary. ## Chosen presence Remote is the default operating mode. In-person time should be used intentionally for things that benefit disproportionately from co-presence, such as: * trust-building * difficult repair conversations * deep design work * strategic resets * celebration * onboarding intensives We do not use co-location as a substitute for weak systems. ## Quality, accountability, and metrics At any time, every active project should be able to answer: * What are we making? * For whom? * Why does it matter? * What stage is it in? * Who is accountable for what? * What are the current risks? * What are we measuring? * Is it helping? * Is it sustainable? * What maintenance burden is it creating? ### Default metrics Not every project uses the same metrics, but each project should track some combination of: * user value * adoption * retention * revenue * margin * maintenance burden * trust indicators * support load * harm signals * team energy * cycle time * reliability If something is “working” only because people are quietly overextending, it is not actually working. ## Good faith in practice We assume good faith first. We do not assume it forever without evidence. In practice, good faith looks like: * speaking directly before resentment hardens * surfacing risks before they become emergencies * distinguishing disagreement from disloyalty * asking for clarification before assigning motive * updating behavior after feedback * accepting accountability when impact exceeds intent ### Designing against bad faith Bad faith becomes easier when systems reward ambiguity, hidden power, and vague ownership. So our practice should make bad faith harder by default through: * legible decisions * explicit scopes * clear responsibility * visible contribution records * visible stewardship expectations * reviewable authority * documented exits * documented conflict pathways ## Conflict, repair, and exit Conflict is normal. Avoidance is expensive. ### Conflict process When tension appears: 1. direct conversation between the people involved 2. if unresolved, one mediated conversation with a mutually trusted third party 3. if still unresolved, steward review with a written summary 4. decision, repair plan, role change, or separation The goal is not forced harmony. The goal is clarity, repair where possible, and clean separation where necessary. ### Serious breaches The following patterns count as serious breaches: * repeated ambiguity games * hidden agendas in material decisions * taking credit while evading responsibility * withholding critical information * manipulating contribution records * contempt as a recurring communication style * creating avoidable legal or ethical risk without disclosure * retaliating against honest dissent * refusing repair after clear harm A demonstrated pattern of bad faith is grounds for removal from roles, projects, or membership. ### Exits When someone leaves: * active responsibilities are handed off explicitly * access is transitioned cleanly * contribution records are reconciled or frozen by agreement * active stewardship share decays according to project rules * cumulative contribution share remains unless removed for cause or superseded by prior agreement We aim to leave cleanly, with documented transitions, preserved dignity, and minimal operational damage. ## Joining and becoming a member New people should not be rushed into membership. Default path: * collaborate on a specific project or trial period * review fit in terms of craft, trust, and working style * evaluate philosophy alignment in behavior, not just rhetoric * offer membership by 75% member approval Membership criteria should include evidence that the person: * improves the work * improves the clarity of the work * improves the trust environment * carries responsibility without dramatizing it * can handle disagreement without corrosion The best signal is not whether someone says the right things. It is whether they make the work clearer, stronger, calmer, and more alive. ## What we optimize for We optimize for: * useful work * small bands * legible decisions * durable products * fair participation * responsible attention * stewardship * calm execution * honest economics * trust under pressure We do not optimize for: * headcount * performative busyness * consensus theater * founder mystique * growth at any cost * vague ownership * martyrdom * permanent urgency * attention without value ## Amendment rule This document is versioned. It should be reviewed: * quarterly in light touch * annually in full * whenever repeated reality exposes a failure mode Changes to this document require a **75% member supermajority** unless they alter philosophy-level principles, in which case the philosophy threshold applies.