Before you sign with a software company: the questions, contract clauses and code ownership that protect you

Many expensive vendor problems start before the contract is signed: a scope nobody wrote down, payments that run ahead of delivery, and code and accounts in the vendor's name. This guide takes the buyer's side, for founders and business owners in Saudi Arabia, the UAE and the wider Gulf about to choose and sign with a software or mobile app development company.

Why do quotes for the same app differ so much?

Because each company is pricing a different product. A short idea document leaves many product decisions open, and each vendor fills the gaps with its own assumptions, from the leanest reading of your idea to the safest.

A hypothetical: three software companies in Riyadh quote the same booking app. The lowest quote assumes the "lean reading" column below; the highest assumes the "safe reading" column. The gap between the totals is the gap between those assumptions.

That is also why online "app development cost" tables rarely answer your question: they price an app whose assumptions you cannot see.

"Is the price reasonable?" Judging a quote without a price list

You don't need a price list; you need a quote you can take apart. Ask every shortlisted company to price the same written scope, ideally a software requirements specification (SRS), and to break its quote down by module, with the team, the weeks, and explicit assumptions and exclusions. Here is how to write an SRS a vendor can price. Then check three things:

• The arithmetic holds. The named team can plausibly deliver the listed modules in the proposed weeks. A large scope from a tiny team on a short timeline is a warning, not a bargain.
• The exclusions are visible. The cheapest quote often leaves out testing, the admin panel, hosting or handover. Price those gaps before you compare totals.
• Changes have a rule. A low quote with an expensive change-request process is not a low quote.

A company that refuses to break its quote down is showing you how it will run your project.

What should I ask a software company before signing?

Ask questions you can hold the company to later: who exactly will build it, how quality is checked, where the data will live, and who owns what at the end.

• Scope: Will you price our written requirements as they are and list every assumption?
• Team and subcontracting: Who exactly works on my project, in which roles and for how much of their time? Will any part be subcontracted, and will you tell me in writing first?
• Quality: Who tests, against which test plan, on which devices, and will I see the results at every milestone?
• Security and hosting: In which country and cloud region will the system and its data be hosted? Who gets production access, from where, and how is it revoked at the end?
• Ownership: Will the code sit in my company's repository from the first commit, and will the app-store, cloud and payment accounts be in my company's name?
• References: Can I call two clients whose apps are live, and install those apps myself?

Then score the answers. The weights are my own judgment, not an industry standard; adjust them to your project.

Three answers end the conversation for me: no code in your repository, no named team, and pressure to sign this week for a discount.

How do I check that the company is real and registered?

Use the official registers, and confirm that the legal name you find matches the contract and the invoices. Both Saudi checks below are free.

• Commercial registration (Saudi Arabia): the Ministry of Commerce's Query about commercial registration data e-service searches by company name or unified national number and shows the registration data. Consumers are among its listed users, so you don't need to be a merchant.
• VAT registration (Saudi Arabia): ZATCA's VAT Registration Verification service is open to the public and confirms whether a business is registered for VAT, using its VAT number, commercial registration number or VAT certificate number. Check the number printed on the quote.
• Licenses (UAE): the National Economic Register lets you look up economic licenses and business activities in the UAE. Its page lists the licensing authorities (the Ministry of Economy and Tourism and each emirate's economic department or municipality) and no free zone, so ask a free-zone vendor for its free-zone license too.

Registration proves the company exists, not that it can deliver. For that, install apps it has shipped and call its references yourself.

Which clauses must the software development contract include?

Good clauses make scope, acceptance and ownership explicit; a downloaded contract template was written for someone else's project. These are the engineering terms I would not sign without. This is engineering guidance, not legal advice: have a lawyer qualified in your jurisdiction review the contract.

1. The requirements as an annex. The agreed SRS is part of the contract, with a change-request procedure for anything new.
2. Milestones with acceptance criteria. Each milestone lists deliverables, testable criteria and a review window in which you accept or reject in writing.
3. Code in your repository from day one. The repository lives in your company's GitHub, GitLab or Bitbucket organization, and the vendor's developers are members you can remove. "We hand over the code at the end" is the clause that makes a hostage situation possible.
4. Developer accounts in your company's name. Apple shows the enrolled organization as the App Store seller; whoever enrolls it becomes the Account Holder and must have legal authority to bind the organization, so that person should be from your company, not the vendor. If the app sits under the vendor's account instead, moving it later is an app transfer that the vendor's Account Holder has to initiate. Apple and Google both ask organizations for a D-U-N-S number, and Google warns that getting one can take up to 30 days, so start in week one.
5. Payment gateway, domain and cloud in your name. Your company opens the merchant account so settlements reach your bank; the vendor gets API keys, not the account. The same applies to the domain, the cloud account, email delivery and analytics.
6. IP assignment. Rights in the code, designs and documents made for you pass to your company, with a list of any pre-existing components the vendor reuses and the license under which you may use them.
7. Warranty. A defined period after acceptance in which defects against the SRS are fixed at no cost, with response times by severity.
8. Handover and exit. What you receive at the end, or at once if either side terminates: source code, build and deployment instructions, environment configuration, credentials, database schema and documentation, with payment due only for accepted work.
9. Confidentiality and personal data. A vendor that hosts the system, touches production data or supports users with access to their records processes personal data on your behalf. Article 8 of Saudi Arabia's Personal Data Protection Law requires you, as the controller, to choose only processors that provide the necessary guarantees and to monitor their compliance. Article 17 of the Implementing Regulation lists what the agreement must include, among them the purpose, duration and categories of data, breach notification without undue delay, whether the vendor is subject to other countries' regulations, and its subcontractors. It also lets you appoint an independent third party to assess the vendor's compliance for you. Offshore servers or staff also bring in Article 29 on transfers and disclosures outside the Kingdom; my PDPL engineering checklist goes deeper.

How should I structure the payments?

Pay for accepted work, not for time or promises. Keep any upfront payment small, tie each later payment to a milestone that passed its acceptance criteria, and hold the last one until the handover is complete.

Be wary of large deposits "to reserve the team": once most of the money is paid, your leverage is gone.

What should I check before the final payment?

Release the final payment only when you could hand the project to another team tomorrow. Until then, it is your last real leverage.

• Every SRS requirement is marked accepted, deferred by written agreement, or open.
• The latest code is in your repository, and someone other than the vendor has built and deployed it from the written instructions.
• The apps are published under your company's developer accounts, and the vendor's access is cut to what the warranty needs.
• Production runs in your cloud account, and you hold the admin credentials.
• The payment gateway, SMS, email and maps services are in your name, and settlements reach your bank.
• A basic security pass is done: no secrets in the code, admin panels protected, and a backup actually restored, not just scheduled.
• Documentation is delivered: architecture, environment variables, database schema and a list of third-party services.
• The warranty start date and the defect-reporting channel are confirmed in writing.

An independent review is worth most before you sign and before this payment; those two moments are where my advisory work concentrates.

What if the project is stuck at 75%?

Stop paying ahead, secure your access, and get an independent assessment of what is actually finished before deciding whether to continue with the same company. "75% done" often describes the screens, not the backend, integrations and testing still missing.

1. Pay only for accepted work. Nothing in advance until there is a re-agreed plan.
2. Secure access now. Get admin access, in your company's name, to the repository, cloud, developer accounts, domain and payment gateway while the relationship is still cordial.
3. Get an independent assessment. Someone other than the vendor builds and runs the code and maps each requirement to done, partly done or missing. A vendor's percentage is not evidence.
4. Turn the remainder into acceptance criteria. A written list of what is left, with dates and a payment per item.
5. Decide: fix or move. If the code is sound and the team engaged, a re-planned contract can work. If nobody else can build the code, or dates keep slipping after re-planning, plan a handover.
6. Put it in writing. Formal notices and any termination go through your lawyer, under the exit terms in your contract.

The best protection is the one set up before signing. When the code, the accounts and the acceptance criteria are already yours, a stalled vendor is an inconvenience, not a crisis.