Can I use Mochlion for product design, or only business apps?

Mochlion specifies software applications. That includes internal business apps, such as a tool room checkout or an approvals workflow, and software products you plan to sell to customers. It isn't built for designing physical products, and it doesn't do visual or screen design.

What it produces is a Build Specification: what the software must do, for whom, under which rules, with which data and connected systems, and how anyone will know it works.

Can I use it for a software product I plan to sell?

Yes, if it's one software system. A web version and a mobile version of the same system count as one application. The questions go to whoever knows the work the product supports: you, your co-founders, people who have done the job your customers do, the person who will support it. The more of that knowledge you can bring in, the more the specification has to work from.

It can also specify an application that takes some actions on its own, such as an AI agent inside the app. In that case the specification spells out the limits on what it may do and how those limits are checked.

What isn't it for?

• Physical products. Hardware, devices, packaging and industrial design need other kinds of engineering and testing.
• Visual design. The specification covers what the software must do, not how the screens look. Layout and interface design are left to the designer or builder.
• Several systems at once. One credit covers one application. Two systems that are deployed separately are two applications.
• Building it. Mochlion doesn't write, host or run the software. The specification goes to your own team or an outside practitioner.
• Regulated data. It isn't set up for health records or payment card data, so those shouldn't be uploaded.

Do I need an existing business process?

No, but it helps. For an internal app, the knowledge usually already exists in the people doing the work today. For a new product, more of the answers will be decisions you make rather than facts someone reports, and the specification records them as decisions, with who made them and why. Open assumptions stay marked as assumptions until a person confirms them.

Is a Build Specification the same as a product requirements document?

They cover a lot of the same ground. A Build Specification is written to be built from: every requirement can be tested, every item traces back to a person or a decision, and disagreements are settled before handoff. It also comes as a structured package that AI coding tools can read directly.

How do I find out if my idea fits?

Look at the sample specification to see what one covers, or contact us with a few sentences about what you want built.