Updated 17 October 20269 min read
Riyadh alone has hundreds of outfits offering "web design and app development", from a freelancer working from home to a global agency whose office is in another city. The websites look alike, the proposals are close, and the real difference only shows after signing: who owns the code? What happens when requirements change? Who answers when something breaks at night during Ramadan?
This guide orders the criteria that actually decide the outcome, gives you the questions to ask in the first meeting, and the signals that mean you should walk away. We wrote it as a software company in Riyadh, so call us an interested party, but we set the bar so you can hold us to it too.
1. Who owns the code and the data after delivery?
This comes first because it is the most expensive thing to neglect. Many disputes begin when a client discovers the site runs on a hosting account in the developer's name, that the app is built on a subscription platform it cannot be moved from, or that the source is "delivered after full payment" with no word on when or how.
Ask for it in writing: source code, databases, designs and accounts (domain, hosting, app stores) belong to the client; the repository is in your name from day one; the company keeps only the right to reuse its own generic components.
2. Is Saudi compliance built in, or "added later"?
Any system that issues invoices in the Kingdom falls under ZATCA's e-invoicing rules (Phase 2: integration). Any system that handles personal data falls under the Personal Data Protection Law. Any app that needs identity verification benefits from Nafath.
A company that treats these as details for the end will cost you a rebuild. Ask specifically: how do you generate the invoice XML in the approved format? Where is data stored, and can it stay inside the Kingdom? What is your experience integrating with government services? Specific answers reveal real experience.
- E-invoicing (ZATCA) for stores, accounting systems and ERPs.
- The Personal Data Protection Law (PDPL) for anything that collects customer data.
- National digital identity (Nafath) for services that need trusted verification.
- National Cybersecurity Authority requirements for entities subject to them.
3. Who actually writes the code?
Some polished Riyadh storefronts are sales offices; delivery goes to a third party in another country that may change from project to project. Having part of the team abroad is not a flaw, but you have the right to know: who is the project manager you will speak to? Who are the engineers? Employees or contractors? In which time zone?
Ask to meet the technical team that will work on your project before signing, not the sales team. And ask what happens if a key engineer leaves mid-project.
4. The pricing model, and how change is handled
Three common models: a fixed price for a defined scope, time and materials by the hour or week, or a monthly retainer for a standing team. None is best in the absolute; fixed suits a clear scope, time and materials suits an evolving product, a retainer suits someone who needs a permanent team.
What matters is not the number but the clarity: what is in the price and what is not? How is a change request priced? What is the payment schedule and what does each payment tie to? A quote that arrives before the scope is understood is a sign the number will move later.
5. The contract: clauses to read yourself
- Intellectual property: full transfer to the client on payment, with exclusions defined.
- Confidentiality and data protection: a written commitment, and who gets access to production data.
- Defect warranty after delivery: how long, and what it covers.
- Acceptance criteria: how do we know a phase is "done"?
- Exit terms: what you receive if the project stops halfway, and in what form.
- Service level after launch: response times and support channels.
6. Past work that actually works, not pictures
Open the links to past work on your phone. Is the site fast? Is the app in the stores with real reviews? Then ask to speak with at least one client, and ask two questions only: was it delivered on time, and how did they behave when a problem appeared?
Be wary of portfolios full of big-brand logos without links, and of "testimonials" with no names and no projects.
7. Technology and architecture
You do not need to know React from Vue, but you should ask: is the stack modern with a community wide enough that another team could take over the code later? Can the system be hosted where you want, including inside the Kingdom? Is documentation part of delivery?
A closed platform or ready-made templates may be fine for a brochure site, but they are a risk for an operational system your business will run on for years.
8. Staged delivery and quality measures
Ask how the project runs week by week: is there a staging environment where you see progress? Are automated tests written? How are changes reviewed before release? What is the deployment and rollback plan?
A company that delivers "everything at the end" moves all the risk onto you. Short stages with tangible output surface problems early, when fixing them is cheap.
9. After launch
Launch is the beginning of the real cost, not the end: security updates, changing regulatory requirements, user growth, training new staff. Ask about support options, response times, whether training and documentation are part of delivery, and what continuing costs monthly, separately from the build.
An honest comparison of the three options
None of them is bad in itself; each suits a kind of project. The table puts the criteria above against the common options in the Saudi market.
| Criterion | Freelancer | Agency outside the Kingdom | Specialised local company |
|---|---|---|---|
| Upfront cost | Lowest | Medium to high, by country | Medium |
| Communication and hours | Direct but limited to one person | Time-zone gap, language and culture | Same hours and language; in-person possible |
| Saudi compliance (ZATCA, PDPL, Nafath) | Depends on personal experience | Usually unfamiliar; built from scratch | Part of daily work |
| Continuity and risk | Stops if they get busy or ill | Good, but exit is costly | A team whose members can be replaced |
| Code ownership | Often forgotten in the agreement | Varies; may be tied to a licence | Must be explicit in the contract |
| Best for | Brochure site or small prototype | Global-facing product with a large budget | Operational system, store or app for the local market |
Questions to ask in the first meeting
- Who will work on my project, by name, and where do they sit?
- In whose name are the repository, hosting and domain?
- How do you generate an invoice compliant with e-invoicing Phase 2?
- What happens if I request a change after the design is approved?
- Show me a staging environment for a project in progress right now.
- How long is the defect warranty after launch, and what does it cover?
- If we stop the project after two months, what do I receive?
Signals that mean walk away
- A final quote before any discussion of scope.
- Refusal to name the technical team or arrange a meeting with them.
- A one-page contract that mentions neither IP nor acceptance criteria.
- Big client logos without links or references you can call.
- "You don't need XML, the QR code is enough" when e-invoicing comes up.
- Requiring the system to be hosted on the company's accounts, not yours.
Where Tecorva stands on these criteria
We are a software company in Riyadh, working since 2023, building websites, stores, mobile apps and ERP systems with e-invoicing for the Saudi market. Code, repository and accounts are in the client's name from day one, and the contract states acceptance criteria, warranty and exit terms. We do not claim certifications we do not hold: e-invoicing clearance is granted by ZATCA to your system after integration, and we are the ones who build that integration and pass its tests. If you want to test the criteria above on us, the first consultation is free and we reply within a business hour.