Founders with an app idea usually start by asking which software company to call. That is the fifth decision, not the first.
Where do I start when I have an app idea?
Start by proving that the problem is real and that someone will pay to make it go away. The app is one possible solution; the problem is the asset.
An idea is a guess about other people's behavior; test it on people who live with the problem, not on friends being kind. Signals I take seriously:
- People describe the problem in their own words, without being led.
- They already pay for a workaround in money or time: WhatsApp groups, spreadsheets, a staff member who chases it.
- Someone commits: a deposit, a signed letter of intent, a pilot date.
Then write a one-page brief: the user and the problem, the one journey that must work on day one, the number that will show three months after launch whether it worked, what version one will not do, and your constraints, from Arabic and English to platforms, payments and the budget you will risk.
What should the first version include, and how do I write it down?
One core journey that delivers the value, built properly, and nothing else. Write it as a requirements document a vendor can price and you can test delivery against.
The minimum viable product (MVP) is the cheapest serious test of your riskiest assumption, not a smaller copy of the final product. A hypothetical: a founder in Jeddah plans an air-conditioning maintenance app with customer and technician apps, live tracking, a wallet and subscriptions. The first version I would sign off: customers book and pay by card, one operations person assigns technicians from a simple dashboard, and technicians get jobs by SMS. If customers book again, the rest has earned its place.
A product requirements document (PRD) says what the product must do, for whom and why. A software requirements specification (SRS) turns that into testable statements a vendor can price: roles, screens, rules, integrations, and needs such as right-to-left Arabic layouts, performance on mid-range phones and data protection (my SRS guide has an outline). Give every feature an acceptance criterion ("a customer can book a visit in under a minute" is testable; "easy booking" is not), and list what version one will not do: vendors price ambiguity as risk.
Who should build it: a software company, a freelancer, an in-house team or a technical partner?
It depends on how much product and technical judgment you can supply yourself. A company sells delivery capacity, a freelancer sells a skill, an in-house team buys continuity, and a technical partner trades commitment for equity.
| Option | Fits when | Main risk | Non-negotiable |
|---|---|---|---|
| Software company | Written scope, and you want design, build, testing and launch in one contract | Your project gets whoever is free; change requests become the business model | A named team, code in your repository, payment per accepted milestone |
| Freelancer | The scope is small and clear, or you need one specialist skill | A single point of failure | Weekly working builds and daily commits to your repository |
| In-house team | The product is the company and will evolve for years | Slow hiring; juniors drift without a senior lead | A senior lead before anyone else |
| Technical partner | You need long-term technical leadership and cannot pay cash for it | Equity given early is hard to take back | Vesting, written roles and code owned by the company |
For most first versions I would pick a capable company or strong freelancer working from a written scope, with someone senior on your side checking the work; a Saudi office helps with accountability but replaces none of these checks.
If the vendor will host the app or handle your users' data, Saudi Arabia's Personal Data Protection Law (PDPL) makes the choice your responsibility: Article 8 requires the controller, your company, to select only processors that provide the necessary guarantees and to monitor their compliance. Ask how a vendor protects data before you ask for its portfolio.
Can I build it myself with AI tools?
Yes, for a prototype you show to users and investors. Not for an app that holds real people's data or money, until someone who can read code has reviewed it.
AI app builders produce a working prototype quickly, which answers "would anyone use this?" faster than any document. The risk is what the demo hides: in Veracode's 2025 GenAI Code Security Report, more than 100 AI models completed 80 coding tasks chosen for their known potential for security flaws, and in 45% of cases the generated code introduced vulnerabilities from the OWASP Top 10, a list of the most critical web application security risks. Security did not improve as the models got better at writing working code.
The vulnerability record CVE-2025-48757, published in May 2025 against the app-building platform Lovable, describes an insufficient database row-level security policy, in versions through April 15, 2025, that let unauthenticated attackers read or write the database tables of generated sites. The record notes that Lovable disputes it, on the grounds that each customer accepts responsibility for protecting their own application's data. That is the lesson: your users' data is your problem. Before real users arrive, check:
- Access rules: a logged-out visitor or a second account cannot see or change other users' data.
- Secrets: no API keys, admin passwords or payment credentials in app or browser code.
- Backups: automatic, stored off the platform, and restored at least once.
- Separation: test data apart from production, and no AI agent with write access to it.
- Ownership: code in a repository your company owns, and a plan if the platform changes its pricing or shuts down.
- Privacy: a privacy policy, account deletion, and a known location for the data.
Why do quotes for the same app differ so much?
Because each vendor is pricing a different app: wherever your brief is silent, vendors fill the gap with their own assumptions, and the price follows.
I do not publish prices, and I distrust firm figures for ideas nobody has seen in writing. What moves the number:
| Cost driver | Why it moves the quote | Ask the vendor |
|---|---|---|
| Apps and user roles | A marketplace is usually three products: customer app, provider app, admin dashboard | Which apps and roles are included? |
| Platforms | iOS, Android and web; native or cross-platform | Which platforms and approach, and why? |
| Integrations | Payments such as mada and Apple Pay, maps, SMS verification, accounting | Whose accounts do they run on? |
| Real-time features | Live tracking and chat need different infrastructure | What happens when the connection drops? |
| Arabic and English | Right-to-left layouts and bilingual content need design and testing in both languages | Can we edit both languages from the dashboard? |
| Operations tooling | Refunds, reports and permissions are invisible in demos, yet they run the business | What can operations do without a developer? |
| Security, testing and support | Real work that cheap quotes tend to leave out | Which devices are tested, and what does the warranty cover? |
Send every vendor the same requirements document, ask for a breakdown by module and milestone with assumptions and exclusions written out, and compare the exclusions; the gap usually lives there. A quote that arrives without questions has probably priced something the vendor already has. Worked example: what it really takes to build an app like HungerStation or Mrsool.
How do I protect my idea and make sure I own what I pay for?
Sign an NDA, but do not rely on it. Copyright protects how an idea is expressed, such as code, not the idea itself; your real protection is speed of execution and a contract that secures the code, accounts and data.
Saudi Arabia has been a WTO member since December 2005, and the WTO's TRIPS Agreement sets the baseline: copyright protection extends "to expressions and not to ideas" (Article 9), while computer programs, in source or object code, are protected as literary works (Article 10). A vendor who hears your idea can copy little that you cannot out-execute; one who keeps your code, store listing or server passwords can hold the business hostage. So, before the first payment:
- Intellectual property (IP) assignment: code, designs and documents transfer to your company as each milestone is paid.
- Your repository: code lives in a repository your company owns from day one; the vendor gets access, not ownership.
- Your store accounts: Apple requires an organization to be a legal entity with a D-U-N-S number and shows its name as the seller on the App Store, so a vendor's account puts the vendor's name on your app.
- Your infrastructure: domain, hosting, payment gateway, SMS and maps accounts in your company's name.
- Scope and handover: the requirements document as a contract annex, payments against acceptance criteria, and documentation, credentials and licenses handed over.
I cover the clauses in before you sign with a software company. This is engineering guidance, not legal advice: have a lawyer review the contract.
What do the App Store and Google Play expect at launch?
A complete, working app with a privacy policy, in-app account deletion if users can create accounts, and a demo login for the reviewer. A new personal Google Play account also needs a closed test first.
Apple's App Review Guidelines, last updated June 8, 2026, ask for a final, device-tested build with demo account details if it has a login (2.1), and include rules that are cheaper to know before design:
- Minimum functionality (4.2): more than "a repackaged website"; a website in an app shell with nothing added is what this rule describes.
- Privacy (5.1.1): a privacy policy in the listing and inside the app, and in-app account deletion wherever users can create accounts.
- Payments (3.1.1 and 3.1.3(e)): digital features or content sold in the app, such as subscriptions, require Apple's in-app purchase; physical goods and services consumed outside the app must use other methods, such as Apple Pay or card entry.
- Originality (4.1 and 4.2.6): no lightly altered copies of popular apps; apps made from a commercial template or app-generation service are rejected unless the provider of the app's content submits them directly.
On Google Play, personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in continuously for at least 14 days before applying for production access, which Google says it usually reviews in seven days or less. Recruit testers while you build. On either store, budget time for a rejection and a resubmission; the fix is faster when the code and accounts are yours.
If your users live in Saudi Arabia, the PDPL applies to processing their personal data even from outside the Kingdom (Article 2), so offshore vendors and foreign hosting do not take you out of scope; my PDPL engineering checklist maps the obligations to product work.
When does an independent senior opinion pay for itself?
At the three moments when money becomes hard to get back: before you sign, before each milestone payment, and before you accept delivery.
- Before you sign: does the quote match the requirements line by line, with assumptions and exclusions written down, a sensible architecture for your scale and running costs, and ownership clauses in the contract?
- Before a milestone payment: does the milestone work in a real build on real phones, with the code in your repository and the acceptance criteria passing?
- Before you accept delivery: have access rules, secrets and backups been checked, does the app hold up on mid-range phones, and could another team take over tomorrow?
The reviewer must have no stake in the build; someone who wants to sell you the next phase is not giving a second opinion. That independence is the point of my advisory work. Whoever you use, get the review in writing, each finding tied to the requirement or clause it breaks. A verbal "looks fine" protects nobody.