R-03 · Creator guide
What makes a great FormaBase product
FormaBase products are small, focused and built to run with little human help. This guide explains what we look for, how proposals are evaluated, and how to write one that gets a yes.
The best FormaBase products solve one specific problem extremely well. They are:
- Narrow in scope and easy to explain in a sentence
- Useful enough that people pay without a sales call
- Subscription-based where that fits the value
- Fast to build with modern AI-assisted tools
- Inexpensive to run
- Largely automated, with little ongoing human work
- Clear about who it is for
- Easy for Affiliates to recommend to an audience
| Category | For example |
|---|---|
| AI utilities | Real-estate photo enhancement, document generation, website chat |
| Professional tools | Property valuation reports, automated realtor websites, niche professional software |
| Workflow automation | Lead processing and routing, small workflow automations |
| Calculators and reports | Specialized calculators and report generators for one profession |
| Marketing utilities | Tools that make one marketing task faster or better |
Every complete proposal is reviewed on the same five questions, first with AI assistance and then by people:
| Question | What we look at |
|---|---|
| Duplication | Is it meaningfully different from products already in the catalog or in development? |
| Feasibility | Can it be built on the FormaBase stack, with approved services, at a sensible size? |
| Economics | Will customers pay enough, often enough, to cover running costs and reward everyone? |
| Legal risk | Does it avoid regulated advice, sensitive data and content risks that need special handling? |
| Market potential | Is there a clear audience that Affiliates can reach? |
You receive a written decision within 10 business days of a complete submission. If we need more information, the review period restarts when you provide it. If we decline, your proposal stays yours.
| Section | What to include |
|---|---|
| Product name | A working name; it can change before launch |
| Problem and audience | Who has the problem, how they solve it today, and why they would pay |
| Scope | What the first version does, and what it deliberately leaves out |
| Deliverables | What you will hand over: the working product, tests and documentation |
| Creators | Everyone building it, and how the 20% royalty pool is split between them |
| Prior materials | Any existing code, designs or content you are bringing in |
| Outside services | Every third-party service, model, dataset or license it would use |
| Prototype | Optional, but a working prototype is the strongest proposal there is |
- Lead with the problem, in the customer's words
- Keep version one small; it can grow later
- Show evidence people want it: searches, communities, your own experience
- Name a price and explain why it is fair
- Propose a platform; propose one sharp tool
- Depend on enterprise sales, custom contracts or heavy ongoing support
- Rely on services we cannot approve or data you do not have rights to
- Include confidential details on public forms; formal proposals go through the portal