Why We Chose Spec-Driven Generation Over Code Upload

The obvious approach we rejected

The fastest way to build a marketplace for AI-generated code is to let creators upload it. Accept a zip file, run some linters, maybe a virus scan, publish it. Every existing code marketplace works this way — npm, PyPI, the VS Code extension marketplace. It is battle-tested, well-understood, and we decided against it within the first week.

The reason is trust, and the trust problem has a specific shape when the code is AI-generated.

The trust problem with uploaded AI code

When a human writes code and publishes it to npm, there is an implicit trust chain. The author has a GitHub profile, a commit history, maybe a track record of maintained packages. Other humans review it, file issues, submit PRs. The ecosystem provides ambient trust signals that let you make a reasonable judgment about whether to npm install something.

AI-generated code has none of this. The "author" is a language model that has no identity, no reputation, and no accountability. The person who prompted the model may have reviewed the output — or may not have. There is no way to know from the outside.

This creates a specific, quantifiable problem: the audit cost of verifying uploaded AI code can exceed the cost of regenerating it from scratch. If I can generate a rate limiter for $4.80 in Opus tokens, and auditing someone else's uploaded rate limiter costs $3.00 in tokens plus 15 minutes of my time, the rational choice is to regenerate.

The spec-driven alternative

NanoSaaS takes a fundamentally different approach. Nobody uploads code. Instead:

1. A creator writes a NanoSpec — a declarative specification that describes what the app does, its inputs and outputs, auth requirements, pricing, and trust constraints.
2. The platform validates the spec against a schema with cross-field rules (e.g., PHI data sensitivity requires domain-sensitive trust tier; per-use pricing requires a minimum price of $0.10).
3. The platform generates the code from the spec using its own models, with its own prompts, under its own control.
4. The platform analyzes the generated code for security issues, quality dimensions, and duplicate detection.
5. Only then is the app published.

The trust chain is completely different. The creator never touches the code. The platform controls the entire pipeline from spec to deployed Worker. The buyer trusts the platform's generation and analysis process, not an anonymous zip file.

What this costs us

This decision has real costs:

• Flexibility. Creators cannot use their own code. If they have a hand-crafted, battle-tested implementation that is better than what the platform generates, they cannot upload it. This is a genuine trade-off.
• Generation quality ceiling. The platform's code is only as good as the models and prompts it uses. If a creator could upload their own code, the quality ceiling would be higher in some cases.
• Complexity. Building a spec validation, code generation, and analysis pipeline is significantly more engineering work than accepting uploads and running linters.

We accepted all three costs because the trust argument is dispositive. If buyers cannot trust the code, the marketplace does not work. A marketplace where every purchase requires a manual audit is not a marketplace — it is a repository with a payment form.

The schema as the trust anchor

The NanoSpec schema is published at /schema/nanospec.json. It is the single source of truth for what a NanoApp can be. Every field has validation rules. Cross-field constraints are enforced at schema time, before any code is generated.

This is deliberate. The schema is the trust anchor. When a buyer sees a NanoApp listing, they know that the spec passed validation, the code was generated by the platform, and the analysis pipeline approved it. They do not need to audit the code themselves — they are trusting the platform's process, which is auditable, consistent, and versioned.

Whether that trust is warranted is an empirical question. We think it is, and we are building the analysis pipeline to justify that belief. But the architectural decision — spec-driven generation over code upload — is the foundation that makes it possible to ask the question at all.