Terms of Work

When it is genuinely unclear which one a request is, we go back to the approved specification and the earlier approvals and work out the cause together — before anybody starts building.

1. 01

   Scope is whatever we wrote down

   Before anything is built we agree the scope in writing — through the quote, a requirements document, technical specs, design mockups, or an approved exchange of messages. It names the screens, the business rules, the user types, the admin panel, the integrations, the languages and platforms, and how the project gets deployed.

   Anything outside that is not in the price or the timeline until we both agree it is. That is not a way of saying no; it is how you stay in control of what a change costs, before it happens rather than after.

2. 02

   Approvals, and who gives them

   We work in stages — analysis, design, build, testing, delivery. At the end of a stage you review it and approve it, and the next stage is built on what you approved. A signed document, an email, a message or a project board all count.

   If more than one person on your side is involved, name the one who can approve designs, scope, money and dates. When instructions conflict we stop and ask that person rather than guess. If they move on, what was already approved still stands until we agree otherwise in writing.

3. 03

   Changing something already approved

   You can always give feedback, and feedback inside the agreed scope is simply part of the work. What changes the picture is a request that adds a feature, reworks a requirement you already approved, or rebuilds something already finished.

   For those we come back with the effect on price, timeline, architecture and testing before we touch anything. If a change alters the core idea of the project, we re-estimate the whole of it rather than quietly absorbing the difference.

4. 04

   Dates, and what moves them

   The duration we give is based on what we know when we agree it. It assumes designs get approved, content arrives, access is granted and questions get answered at a reasonable pace.

   When those slip the schedule moves with them, and we reschedule around the team's other commitments. Work you need outside the agreed schedule, or in an unusually short time, may carry a fee — quoted and accepted before we start, never after.

5. 05

   What we need from you

   Text, images, logos, product data and prices, store policies, legal copy, contact details, and the accounts or credentials any third-party service needs. A project only moves as fast as the slowest of these.

   What you send has to be yours to send: you confirm you own it or are licensed to use it, that it infringes nobody's rights, and that the prices, product data and commercial claims in it are accurate.

6. 06

   Paying for it

   Price and payment schedule are set in the quote or the contract, usually as a deposit, one or more milestone payments, and a final payment. A deposit reserves your slot and the team's time; it counts toward the project price and is not a separate fee.

   If a due payment is late we may pause unfinished work, and we will tell you plainly that we have. If you cancel after we have started, we settle against what was actually built, the resources committed, and anything non-refundable we bought for the project — neither side pays for work that did not happen.

7. 07

   Delivery, review and acceptance

   We deliver in stages so problems surface early instead of all at once at the end. Each delivery comes with a seven-day review window, in which you send one clear list of anything that does not match the agreed requirements.

   We fix what belongs to the agreed scope. If the week passes with no substantive feedback, or the stage goes into live use without a written reservation, that stage is treated as accepted — which does not touch the warranty on genuine defects.

8. 08

   Warranty, and what it is not

   For 30 days after final delivery we fix, free of charge, anything that fails to work the way the approved specification says it should.

   It does not cover new requirements, changes you decide you want after delivery, code or database edits made by you or anyone else, unapproved add-ons, server or API changes at a third party, hosting and connectivity faults, incorrect data entered into the system, or attacks. Ongoing maintenance and development are a separate arrangement — monthly, or on demand.

9. 09

   Hosting, accounts and third parties

   Wherever possible, hosting, domain, app-store, payment and messaging accounts are registered in your name, so the thing you are paying for stays yours. Keep the credentials and recovery details current; if you ask us to manage an account we do it within the access you grant.

   Services we do not own run on their own terms, prices and uptime. We will help trace a fault to its source, but we cannot guarantee a third party stays available, holds its prices, or leaves its API alone — and a change one of them forces on the project is assessed as new work.

10. 10

    Who owns the result

    Once the agreed payments are complete, the deliverables built specifically for you are handed over — project files, source code, access, the database, design files and operating notes, as the contract sets out.

    What does not transfer by default is the internal tooling and the general components we reuse across projects: you get a licence to use them inside your product, not ownership of them. Open-source libraries keep their own licences. Whether you receive full source or a usage licence is settled before the build starts, not after.

    Unless you ask us not to, we may name the project and show it in our portfolio once it has launched, without revealing anything confidential. Say the word and we keep it private.

11. 11

    Confidentiality, data and security

    Non-public information runs both ways: we keep yours, you keep ours — technical detail, internal tooling, access data and pricing included.

    We build to practices appropriate to the project, but no internet-connected system can be declared risk-free. Penetration testing, specialist security audits and compliance certification are real work and have to be named in the scope. The same goes for backups: how many, kept how long, stored where, restored how — if it is not agreed, do not assume it exists.

12. 12

    Limits, results and disagreements

    We do the work with the skill and care the project deserves. We do not guarantee commercial outcomes — sales, downloads, traffic, conversion rate — because those turn on far more than the software. If specific performance targets matter to you, we write them down together with how they will be measured.

    To the extent the law allows, we are not liable for indirect or consequential loss, and our total liability for a project is capped at what you paid for it. If something goes wrong we talk first, and review the documents, approvals and deliverables together. Unless a contract says otherwise, Iraqi law applies.

13. 13

    Work we will decline

    We do not build content that conflicts with Islamic principles — music, or indecent imagery and video, placed inside a product. Declining that is not a breach of our obligations to you.

    We will say so as soon as we see it in a brief, and propose an alternative wherever one exists. The rest of the scope carries on unaffected.