1. What Is AAQDeals?

AAQDeals is a selective software-development path offered by AAQSoftware. Under this model, AAQSoftware funds its internal design and development work while you define the product, review milestones, provide feedback, and approve the delivered stages. When the project is complete, you decide whether to acquire it under the agreed price and commercial terms, or decline the acquisition without paying AAQ’s internal development cost.

AAQDeals is not free development. It is AAQ-funded development for selected projects, in exchange for AAQ retaining the right to keep and commercially use the product if you do not acquire it under the Deal.

2. AAQDeals vs. Normal Development

3. Application Wizard and Expected Price

Before submitting an AAQDeals application, you complete a guided wizard covering the product type, platforms, features, technical requirements, languages, design elements, and customization choices. The more accurate the information, the more accurate the project estimate can be.

During the wizard you will see an expected price or price range before submission. The purpose is to give you a clear financial expectation of what acquisition may cost if you decide to take the finished product. A limited, justified adjustment may occur as the final specification is confirmed, but AAQ will not turn a modest estimate into a dramatically higher price without a valid basis.

Your later fundraising, profitability, or improved financial position does not by itself change the agreed Deal price.

4. Which Projects Are Eligible?

• The project should be capable of public release or commercial marketing, or be commercially reusable by AAQ if you do not acquire it.

• Internal systems made for one company or organization normally move to Normal Development.

• Proof-of-concept (POC) projects normally move to Normal Development.

• An MVP should have a credible direction beyond the first version and a reasonable roadmap for continued development.

• AAQ may reject a project if founder dependency is too high, resale potential is too weak, or the technical cost, maintenance burden, or commercial opportunity does not fit AAQDeals.

• Acceptance into AAQDeals is selective and is not automatic.

5. Conflicts With Existing AAQ Products

AAQ will not build a project that materially duplicates or directly competes with an existing AAQ product, whether through AAQDeals or Normal Development. Broad category overlap is not enough to create a conflict; the key test is whether the target audience, core problem, core value, and essential product experience substantially duplicate an AAQ product.

For example, an AI music-generation product without a language-learning focus, or a language-learning product using AI-generated children’s stories, would not automatically duplicate Songuage. A project that reproduces Songuage’s essential concept—such as teaching adults languages through AI-generated songs—would be treated as a direct conflict. AAQ may instead offer to value the existing product and discuss a Product Resale transaction.

6. Ownership During AAQDeals

During development, AAQ-created deliverables—including source code, editable design files, and software assets—remain under AAQ ownership and control until the acquisition and payment conditions are satisfied. While you remain compliant with the Deal, you hold the contractual exclusive right to acquire the product under the approved terms.

Viewing a design, testing a build, or approving a milestone does not transfer source files or reusable rights to you. Ownership transfers only through the agreed acquisition process or through a paid work-in-progress purchase if you withdraw early.

Transfer does not automatically include AAQ internal libraries, proprietary tools, or third-party licenses that cannot legally be transferred. Transferable items will be identified in the delivery agreement.

7. The General Idea and What Happens If You Do Not Acquire

If you choose not to acquire the product, you do not pay the internal development cost funded by AAQ and your exclusive AAQDeals acquisition right ends. AAQ may then stop the project, continue it, redesign it, change its branding or monetization, publish it, license it, or commercialize it as an AAQ product.

You remain free to develop the general idea independently, yourself or with another company. However, after leaving the Deal, you cannot require AAQ to stop using, publishing, or commercializing the product AAQ developed under AAQDeals.

8. Your Responsibility for Submitted Materials

By submitting a project, you confirm that you have the legal right to submit and use all materials you provide to AAQ, including code, designs, data, specifications, and content. If the idea or relevant rights are shared with partners or other rights holders, they must be disclosed and the required owners must participate in the approval/signature process.

Your idea does not need to be unprecedented, but you must not provide third-party trade secrets, code, designs, or proprietary materials without authorization. Common product features such as dark mode, subscriptions, notifications, or AI search do not become exclusively reserved merely because they were mentioned in your project.

9. Fixed Scope and the Roadmap

The approved wizard output and onboarding specification define the AAQDeals scope. Fundamental mid-project changes or large new requirements that materially alter the original cost are not part of the Deal.

New ideas that fall outside the approved scope may be recorded for the future roadmap instead of being added to the current release. If you acquire the product, later development is handled through Normal Development. If you do not acquire it and AAQ continues the product, AAQ may use and revise the roadmap at its discretion.

10. Milestones and Formal Acceptance

The project is divided into defined milestones. At each milestone you receive the relevant specification and deliverables for review and formally approve the stage through the designated acceptance mechanism. Informal messages or general comments do not replace formal acceptance.

When you approve a milestone, you confirm that the visible and reasonably testable work at that stage conforms to the approved specification. You may not reopen an accepted milestone at final delivery merely because your preference changed. This does not waive AAQ’s responsibility for a hidden technical defect that could not reasonably have been discovered at the time of approval.

A Final Integration Acceptance is used before closure to confirm that the assembled product works as a whole against the overall specification.

11. Feedback Requirements

Feedback should be actionable: explain what the problem is, where it occurs, and why it is a problem. If you have an alternative solution, example, color, reference, or preferred direction, including it is encouraged, but it is not mandatory when the underlying problem is already clear.

Comments such as “I do not like it” or “change it” without useful detail do not obligate AAQ to make a change and may remain pending until they are clarified.

Commercial choices within scope generally remain yours. AAQ may refuse instructions that materially compromise security, engineering integrity, compliance, or maintainability.

12. Response Obligations and Project Abandonment

AAQDeals requires active participation. When the project status is Waiting for Client, you must provide the requested response or approval within the stated period.

Response clocks do not run while the project is Waiting for AAQ. Abandoning a project during development may make you ineligible for future AAQDeals unless AAQ later reinstates your eligibility due to exceptional circumstances. Reaching normal completion and choosing not to acquire the product is not treated as abandonment.

13. If You Withdraw During Development

You may request to end the Deal before completion. You then have two paths: purchase the work completed to date at a value proportional to the completed work and lower than the completed-project acquisition value, then receive the purchased transferable deliverables; or withdraw without purchasing the work, in which case you receive no AAQ source code, editable design files, or other AAQ deliverables, and AAQ may continue, use, or publish what it developed. You remain free to independently develop the general idea elsewhere.

14. If AAQ Stops the Project

AAQ may stop a project for commercial or operational reasons. If AAQ terminates without fault or breach by you, AAQ bears its internal development loss and provides you with the transferable work completed up to that point without charging development fees, excluding AAQ proprietary components and third-party assets that cannot be transferred.

15. Pricing and Estimation Responsibility

If AAQ materially underestimates its own development effort within the approved scope, AAQ bears that estimation risk. AAQDeals does not permit fundamental scope changes during development that justify major price increases; such ideas move to the roadmap or later development.

If the product becomes unexpectedly valuable before acquisition, or you raise investment or become more financially successful, AAQ remains bound by the agreed Deal price.

16. Acquisition, Payment, and Ownership Transfer

When the product is complete and you choose to acquire it, the agreed acquisition and payment terms apply. The commercial structure may be a full payment, installments, paid hosting/maintenance, revenue share, or a hybrid structure if both parties agree.

Final ownership does not transfer until the acquisition and payment conditions in the agreement are satisfied. If you default after paying part of the price, the acquisition agreement governs the treatment of paid amounts, cure periods, and restructuring. The parties may agree to convert the relationship into a partnership or revenue-sharing arrangement, but this requires a new mutual agreement and is not an automatic consequence of payment difficulty.

17. Accounts, External Services, and Production Publishing

During development, AAQ may use its available development or test accounts to demonstrate the product, including maps, AI services, servers, or Apple/Google environments. These are development resources and are not transferred as part of product ownership.

At acquisition you must provide the required production accounts and services, or agree to a paid AAQ service where applicable. If the project requires a service AAQ does not provide—such as a specific payment gateway—you must provide the required account and credentials.

A final product owned by you will not be published under AAQSoftware’s Apple App Store or Google Play developer accounts, even for an additional fee. Production publishing must use the account belonging to the product owner.

18. Warranty and Maintenance After Delivery

A defined warranty or maintenance period applies after acquisition and production release. A Bug is behavior that fails to meet the approved specification and is handled under the warranty terms. A Change is a new request or different desired behavior and is treated as new development. Third-party breakage—such as changes by Apple, Google, an API, payment gateway, or other external provider—is not automatically an AAQ defect unless the agreement states otherwise.

19. Transferring an AAQDeal to a Third Party

You may transfer your AAQDeal rights to another person or organization only with AAQ approval and a documented transfer. You must clearly and finally release your rights in the transferred Deal, and the incoming party must review and accept all existing specifications and prior milestone approvals and assume the existing and future obligations.

A transfer does not reopen the project scope. If the incoming party wants a fundamentally different product, that becomes a new project or agreement.

20. Sale of the Client Company or Change of Control

If the client is a company and it is sold or undergoes a change of control, the acquiring entity must reaffirm the AAQDeal and its obligations. Continuation with the new owner requires acceptance of the existing Deal rather than a full reset of previously approved work.

21. Death, Incapacity, or Company Closure

If continued communication becomes impossible because the contracting individual dies or becomes legally incapable, or because the client company closes, the agreement provides a defined period for an authorized estate representative or legal successor to appear. If no authorized party appears or communication ceases for the specified period, the project may be treated as abandoned. If an authorized representative appears, continuation, transfer, or termination is handled under the agreement and governing law.

22. Similar Ideas and Other Client Projects

AAQ performs a conflict review before accepting projects. If another project in the AAQ pipeline materially duplicates your concept, AAQ may reject the application due to a product-pipeline conflict without disclosing the other client’s identity or confidential product details.

If projects were legitimately different when accepted but later converge naturally, AAQ keeps client information separated and does not transfer feedback, roadmaps, or confidential information from one project to another. AAQ retains project communications, approvals, and change histories to document that each project developed independently from its own client inputs.

23. Confidentiality and AAQ Suggestions

AAQDeals is a development model, not an implied business-consulting or co-founder relationship. AAQ implements the approved commercial vision within the project scope and may offer limited suggestions when useful or necessary, but AAQ is not required to provide alternative business strategies, monetization models, or internal product ideas.

If you do not acquire the product and it becomes an AAQ product, AAQ may later redesign it, add or remove features, change branding, or change its monetization before release.

24. More Than One AAQDeal

You may submit more than one idea, but a second active Deal depends on your eligibility, the progress of your existing Deal, and AAQ’s available capacity. As an operating guideline, AAQ may consider an additional Deal when the existing project has passed approximately 85% completion, together with any additional criteria AAQ applies. A prior mid-development abandonment may prevent future AAQDeals.

25. End-of-Project Outcomes

26. Product Resale After an AAQDeal Ends

If a project becomes an AAQ-owned commercial product after the Deal ends, it is treated like any other AAQ product. If you later wish to buy it—or another buyer wishes to acquire it—the request is handled through Product Resale and the product is valued and negotiated based on its condition and value at that later time. The original AAQDeals price does not remain a permanent purchase right after the Deal has ended.

27. Records and Approvals

AAQ retains records of specifications, milestone approvals, feedback, notices, and material changes relating to the Deal. These records are used to establish what was agreed and when decisions and approvals occurred.

28. The Project-Specific Agreement

This guide explains how AAQDeals works, but it does not replace the project-specific AAQDeal agreement. Before development begins, AAQ may require a signed agreement covering the final price, scope, response periods, governing law, payment structure, warranty, liability limits, and project-specific rights. If this guide conflicts with a signed project agreement, the signed agreement controls.