Monoes · Build First
Modernize your stack.
Pay only if it meets your Spec.
We write an Acceptance Spec with you, build against it in a staging environment, and you test the result with your own checklist. Stack modernization, process automation or a new product.
No upfront payment. You pay only if the build meets every requirement in your Acceptance Spec.
If every requirement passes, you proceed on the terms agreed beforehand, or a Build Fee applies. Terms apply.
How the offer works
Write the Acceptance Spec together
A 60 to 90 minute call produces a checklist. Every row has exact test steps and an expected result. You sign it before any work starts, and the price is agreed in writing at the same time.
We build it in staging
Monoes and vetted contributors build against the frozen Spec. You get named access to a staging environment we control. No production data and no production access are involved.
You run the checklist
If every row passes, we move on to the agreed terms. If a row fails, we get one fix cycle. If it still fails, you owe nothing and the staging build is taken down.
How the Acceptance Spec works
The Acceptance Spec is the whole offer. It replaces the opinion of what counts as done with a list your team can run. Here is the shape of a Modernize Spec.
| ID | Requirement | Test steps | Expected result | Status |
|---|---|---|---|---|
| S-01 | Every endpoint returns the same response on the new build as on the legacy system. | Replay the agreed golden request set against both systems and diff the responses. | No differences in the agreed fields. | Pass |
| S-02 | The order export page meets the agreed load time. | Measure on the agreed reference device and network with the agreed tool. | Result is at or under the agreed threshold. | Pass |
| S-03 | Your existing automated test suite passes. | Run the suite from the staging repository. | Zero failures. | Fail |
| S-04 | The dependency scan reports no critical vulnerabilities. | Run the agreed scanner on the delivered build. | Zero critical findings. | Not run |
- Every row is binary: it passes or it fails. Words like “fast” or “intuitive” become a measurable threshold or are left out.
- The Spec is signed by the person who decides, then frozen. The build clock starts from that signature.
- Changes after the freeze are written change requests. They never stretch the build beyond its agreed scope.
- A row fails only with the row ID and the steps that reproduce it. Preferences go to the paid backlog.
Who it is for
- You have an aging system, a manual process or a product idea, and a named person who can sign off.
- You can pay the agreed price if the build meets your Spec.
- Someone can join Spec calls and answer questions within two business days.
- You can write down what success looks like, with our help.
Who it is not for
- Hardware, or work that needs production credentials or production data before you sign.
- Open-ended exploration with no testable end state. If a requirement cannot be tested, it cannot go in the Spec.
- Companies that want AI digital workers deployed on their existing ERP and CRM. That is Monoes Workforce.
What we build
- Modernize
- Move a legacy stack to a modern one for performance, efficiency and maintainability, with behaviour parity as the pass test.
- Flow
- Build process automations from scratch, with the approval and error paths written into the Spec.
- Launch
- From research to a complete product, with user stories turned into scripted acceptance flows.
Questions we expect
What is the catch? Nobody builds for free.
The build costs you nothing until you accept it. We carry that cost because we expect to be chosen when a build meets your Spec. The conditions are public: we qualify applicants, scope is bounded, the Spec is signed first, the build stays in staging, and if every row passes you proceed on the agreed terms or a Build Fee applies. The full conditions are in the terms.
Who decides whether it passes? Will you just say it is fine?
You do, through your own internal sign-off. The Spec is the checklist: each row has test steps and an expected result, and a row passes only when the steps produce that result. Preferences and new ideas that were not in the Spec go into the paid backlog and do not count as failures.
What about our data and security?
We never need production data or production access before you sign. The build runs on synthetic or sample data in a staging environment we control, under a mutual NDA, with access logging. For Modernize we need your source code: it stays yours, and we delete it and anything derived from it if you do not accept.
What does it cost if it passes, and are we locked in?
The price is agreed in writing before work starts, so there is no surprise after a pass. How it is charged depends on the line: Modernize is priced from the size of the code, Flow per live automation, Launch per product. Details are in the terms. Support after handover is optional and quoted separately.
Can you actually build this?
Within the scope we agree, yes, and we say no early if something is out of scope. You can inspect our open-source engineering today, linked in the trust section below.
Who does the work?
The Monoes team and vetted contributors under confidentiality and IP agreements. Monoes reviews everything before you see it. Where personal data is involved, a data processing agreement covers it.
How is this different from Monoes Workforce?
Workforce deploys AI digital workers on your existing ERP and CRM, starting with a Discovery audit that you pay for after delivery. Build First is for modernization, new automations and new products, where we build first and are paid only if the build passes.
Apply for a build slot
Ten questions. We review every application ourselves and reply within two business days. Applying costs nothing and commits you to nothing.
What you can verify today
Open source
Our engineering is public: Monomind (Apache 2.0) and Mono Agent (MIT).
Written terms
Scope limits, IP, staging rules and the Build Fee are published in full.
Who is behind it
Offered by Nokhodian UG (haftungsbeschränkt), founded by Morteza Nokhodian, author of Monomind.
Run the checklist before you commit.
If a build meeting your own written requirements would change how you decide, apply for a slot.
Apply for a build slot →If every requirement passes, you proceed on the terms agreed beforehand, or a Build Fee applies. Terms apply.