Constraint-Native Business Model Design

The paper offers constraint-native business model design as a design mode, quota-bounded autonomy as a governance mechanism, a coded log of 43 review defects, and seven testable propositions. Evidence is the venture's code, documents, commit history and three days of usage telemetry checked against the cloud provider's own analytics. It is a single pre-revenue case, so its propositions are offered for testing, not as established findings.

Abstract

Generative AI coding tools and generous cloud free tiers have pushed the cash cost of building a working software business towards zero. When building stops being the scarce input, the design problem for a new venture changes. This paper asks what a business model looks like when it is designed around hard external constraints rather than despite them, and what new scarcities appear when a small team can build almost anything quickly.

The paper reports a design-science case study of TightBucket, a website "revenue-leak" auditing service built in three days in October 2026 by its owner working with AI coding agents. The owner set explicit constraints. The budget was zero. Checkout had to run entirely on a third-party merchant platform. Email had to go through a free mailbox. Four customer audiences had to be served under one brand. The system had to operate autonomously, with a human only for important decisions. And it had to stay at or below 20% of every free cloud quota while running at full capacity.

Drawing on the venture's code, its documentation, its commit history, a log of 43 defects found in two review passes, and three days of usage telemetry compared against the cloud provider's own analytics, the paper makes four contributions.

1. Constraint-native business model design. It conceptualises this as a distinct design mode in which constraints are first-class design inputs, recorded in a constraint ledger, rather than environmental conditions to be overcome.
2. Quota-bounded autonomy. It specifies this as a governance mechanism for autonomous operations, built from four steps: measure, cross-check, pace and degrade. It reports that the venture's self-meter agreed with provider analytics on AI use and, after the first day, on reads, but under-counted writes by a factor of 2.7 to 11. That gap justifies the rule "govern by the higher of the two numbers".
3. The autonomy boundary. It derives this from two properties of an action, its reversibility and its externality to third parties, and explains why the venture automated first-touch email but kept social-network outreach and every reply in human hands.
4. Verification debt. It introduces this as the liability created when AI produces systems faster than people can check them. In the case, 40 of the 43 defects were silent rather than visible, about half would have affected people outside the firm, and a fifth were residues of decisions the owner had changed.

The paper closes with seven testable propositions and a Constraint-Native Business Model Canvas for practitioners.

Keywords: business model design; constraints; bootstrapping; freemium; design science; AI-assisted software development; autonomy; platform dependence; serverless computing; verification debt

Contents

1. Introduction
2. Theoretical background
3. Method
4. The case: TightBucket
5. Findings: eight design principles
6. Frameworks and propositions
7. Discussion
8. Conclusion
9. References