Product Partnership Rules

1. Purpose of these rules

NikaliSoft is the trading name of {{LEGAL_COMPANY_NAME}}. NikaliSoft reviews real business problems submitted by companies registered in the European Union and may develop a small number of selected opportunities into independent software products.

These rules explain the standard model. In particular:

• NikaliSoft does not offer free custom software development.
• The model is a selective product partnership, not a service engagement.
• A solution must have credible relevance beyond the submitting company alone.
• These public rules describe the standard model only; they are not the contract.
• A partnership is created solely by a separately signed final agreement.

2. Who can propose

A proposing partner must:

• be a legally registered company in an EU member state;
• submit through an authorised representative of that company;
• describe a real business problem it actually experiences;
• provide non-confidential information only;
• have access to relevant users and genuine domain expertise;
• be able to support validation and the initial route to market.

NikaliSoft may verify company identity and the authority of the representative before taking any proposal further.

3. What makes a problem suitable

A problem is normally suitable for this model when it is:

• recurring rather than a one-off situation;
• commercially meaningful;
• measurable in time, cost, errors, risk or missed revenue;
• experienced by multiple companies, not only the proposer;
• currently handled through manual, fragmented or expensive workarounds;
• technically and legally feasible to build;
• supported by access to real validation users;
• connected to a credible initial market.

Internal automation that benefits only one company, with no wider market, is not suitable for this model.

4. Evaluation and selection

• Every proposal is reviewed manually by people.
• NikaliSoft may ask for additional non-confidential information.
• NikaliSoft may accept a proposal, decline it, or simply stop evaluating it.
• NikaliSoft is not required to build every suitable proposal.
• No response time is guaranteed.
• Submitting a proposal does not reserve a market and creates no exclusivity.
• The public submission is not confidential.
• Confidential discussions require a separate written arrangement agreed in advance.

5. What a founding partner is expected to do

Where a proposal is selected, the founding partner is expected to:

• provide domain expertise;
• provide access to appropriate pilot users;
• explain the current workflow accurately and completely;
• give structured and timely feedback;
• support product validation;
• make relevant industry introductions where reasonably possible;
• support references, demonstrations or appropriate distribution efforts;
• use the accepted product under the subscription agreed in the final agreement;
• issue the valid accounting documents required for revenue-share payments.

These expectations become binding only through the signed final agreement.

6. What NikaliSoft is expected to do

For an approved product, NikaliSoft is expected to:

• fund the approved product development;
• perform product design and technical development;
• determine the technical architecture;
• operate and maintain the independent product;
• manage product infrastructure and product-level policies;
• manage external customer subscriptions and collections;
• calculate qualifying revenue according to the final agreement;
• provide the reporting agreed in the final agreement.

NikaliSoft gives no public undertaking to:

• accept any proposal;
• build requested custom features;
• meet a delivery date before a final agreement exists;
• fund paid advertising;
• guarantee sales, revenue or profit.

7. No custom-development fee

NikaliSoft does not charge an approved founding partner a custom-development fee for the approved independent product.

This does not mean the product is free to use. After the product acceptance and usage conditions agreed in the final agreement are met, the founding partner pays the standard annual subscription defined in that agreement. That subscription:

• is separate from development funding;
• is not included in the founding partner's revenue-share calculation;
• does not create ownership of the product;
• is documented in the final agreement.

No subscription price is fixed or promised in these public rules.

8. Qualifying External Net Collected Revenue

Qualifying External Net Collected Revenue means money actually received by the product operator from qualifying external customers for access to or use of the relevant product, after excluding:

• VAT, sales taxes and similar transaction taxes;
• refunds;
• chargebacks;
• reversed or failed payments;
• direct payment-processing fees;
• the founding partner's own subscription;
• subscriptions from related entities identified in the final agreement;
• amounts invoiced but not actually collected;
• revenue unrelated to the relevant product.

The final agreement will define:

• qualifying products and plans;
• qualifying external customers;
• related entities;
• currency conversion;
• accounting periods;
• corrections;
• the reporting evidence used.

This figure is collected revenue after the exclusions above. It is not profit.

9. The 35% participation

Subject to the final signed agreement, the founding partner receives 35% of Qualifying External Net Collected Revenue.

• The participation belongs to the partner company, not to the individual employee who submitted the form.
• It is a contractual revenue participation.
• It is not equity.
• It is not ownership in NikaliSoft.
• It is not ownership in the product.
• It provides no voting or management rights.
• It guarantees no minimum payment.
• No payment is due unless qualifying external revenue is actually collected.
• Tax treatment and invoicing obligations are handled by each party under applicable law and the final agreement.

10. How the 35% becomes effective

The 35% does not arise merely because a company submitted an idea.

It becomes effective only once every condition defined in the final agreement is completed, including at minimum:

• successful validation;
• signature of the final agreement;
• product acceptance under the agreed procedure;
• payment of the agreed founding-partner subscription.

No public policy can activate a revenue right without a signed agreement.

11. Duration

Once validly activated, the 35% participation continues for as long as the product exists, subject to the final agreement.

The final agreement must define:

• when a product is considered to exist;
• temporary suspension versus permanent discontinuation;
• replacement or migration to a successor product;
• material changes in product scope;
• sale or transfer of the product;
• merger into another product;
• treatment of revenue collected after termination;
• the consequences of a material contractual breach.

These rules do not give the partner any share of a sale price for a product or a company. Any such treatment exists only if the final agreement expressly provides for it.

12. Product independence and ownership

Each approved product may have its own:

• name and brand;
• domain;
• application;
• database;
• infrastructure;
• policies;
• customer contracts;
• pricing;
• accounting records.

Unless the final agreement expressly states otherwise:

• NikaliSoft or a designated product entity owns the developed product and its intellectual property;
• the founding partner keeps its own pre-existing intellectual property;
• product-user data belongs to the product, never to this proposal website;
• the founding partner's 35% is a contractual revenue right, not product ownership.

13. Initial market access

The founding partner is expected to actively assist with initial market access through domain knowledge, validation, introductions, references and appropriate distribution support.

• The exact contribution is defined in the final agreement.
• NikaliSoft may carry out its own marketing.
• NikaliSoft makes no public commitment to fund paid advertising.
• Neither party may make misleading claims about the product or about expected returns.

14. No financial guarantee

• There is no guarantee that a product will be built.
• There is no guarantee that a product will launch.
• There is no guarantee of customers.
• There is no guarantee of revenue.
• There is no guarantee of profit.
• There is no guaranteed minimum revenue-share payment.

15. The final agreement takes priority

If a proposal proceeds, the signed final agreement governs the actual partnership. These public rules do not replace it and do not summarise it completely.

Where these public rules and a signed final agreement conflict, the signed final agreement controls for that product and that partnership. All agreements are prepared, completed and signed manually outside this website.

Legal review required: confirm the priority clause and its interaction with the final agreement's entire-agreement wording.

16. Updates to these rules

Updated rules apply only to future submissions, unless an existing signed agreement expressly incorporates the update. A public update never silently changes an existing signed product partnership.

Every published version keeps its own version identifier and effective date, and the version accepted with a proposal remains retrievable.

Document identity

Document: Product Partnership Rules. Version 0.1-draft. Published by {{LEGAL_COMPANY_NAME}}, trading as NikaliSoft. Contact: nikalisoft@gmail.com.

Each published version keeps its own identifier, effective date and content fingerprint. A version that was accepted with a proposal always remains retrievable at /product-partnership-rules?version=0.1-draft.