Start a project
Start a project Book a call
International

From idea to first release: building a software product in the Middle East

A six-stage path from idea to first release, with the decision to take at each stage. It adds Middle East checks for Arabic and right-to-left, personal data, working weeks, Ramadan and launch order, and ends with a stage-gate checklist.

ESTASOFT
11 min read
Orange cover with four rising blocks like steps, with the title Your first software product
On this page
    On this page

      You have an idea for a software product. It could be an app for customers, a platform that connects buyers and sellers, or a tool for your industry. The risk is rarely that you cannot build it. The risk is spending months on the wrong thing, or building for one market and finding it does not fit the next.

      This guide gives you six stages from idea to first release, and the decision to take at the end of each. It adds what changes in the Middle East: Arabic from the first screen, working weeks that differ by country, Ramadan, data rules and the order of your launch markets. It ends with a checklist you can print. Sources were read on 4 November 2026. Confirm rules and dates before you act.

      Why stages help

      The UK government's Service Manual is written for public services, but its logic carries over. It splits delivery into phases, starting with discovery, alpha and beta. Discovery decides whether a problem is worth taking further, and the manual says stopping there is not a failure. Alpha means rough, disposable prototypes that test your riskiest assumptions. Beta builds the real service, first for a limited group and then for everyone. The six stages below follow the same idea.

      1. Problem and user. Decide: is this problem real enough to study?
      2. Discovery. Decide: go, change or stop.
      3. Smallest useful release. Decide: what is in and what is out.
      4. Build. Decide: what to buy, what to build and who owns what.
      5. Launch. Decide: which market, which day and who supports it.
      6. Learn. Decide: fix, grow, change direction or stop.

      Stages 1 and 2: problem, user and discovery

      Write one sentence: who has which problem, and what do they do about it today? Name one first user group, not everyone. Then test it with real people.

      The Service Manual says discovery is about learning users, their wider journey and the constraints around them, such as laws, contracts and old systems. It also says to look for non-digital fixes and to plan what data you will collect to judge success. It says around four to eight weeks is typical, but it sets no fixed period and it is written for public services. A private product may differ, so treat that as a reference point, not an estimate.

      When you have a clickable prototype, show it to people. A Nielsen Norman Group article from 2000 argues that about five users per round are enough, because each extra user adds less new information, and that several small rounds beat one big one. For two distinct groups, such as buyers and sellers, it suggests three or four people from each. The page itself points to a newer analysis, so use five as a starting rule of thumb, not a guarantee.

      Add these regional questions now, while they are cheap:

      • Which country comes first, and which language do those users work in?
      • Which phones and browsers do they use?
      • Does the product handle money, identity documents, or health, finance or government data? If yes, name who will ask the regulator or an adviser.

      The decision at the end of discovery is go, change or stop. Stopping is a good result if it saves a build.

      Stage 3: the smallest useful release

      The smallest useful release is one user journey that works from start to finish for your first group. List what the product must do, what can wait and what it will never do. Each item must serve the sentence you wrote in stage 1.

      Now decide on language. Treat text direction as a build decision, not a translation task. The W3C recommends marking direction in the page structure and using start and end style properties instead of left and right, because that makes later localization easier. Android's guide gives the same advice for apps, and Apple says its system frameworks support right-to-left by default. So you have three real options:

      • Launch in Arabic and English together.
      • Launch in one language, but build the layout so that direction can flip later.
      • Launch in one language and fix the layout later. Expect rework.

      Decide numbers too. Apple's Human Interface Guidelines say Western and Eastern Arabic numerals both occur, and that their use varies between countries and even between areas of one country. Ask your first group which digits they expect.

      Finally, ask which sign-in and payment methods your first group trusts. Does each target country have a national digital identity or local payment scheme that users expect? What does it take to connect to it, and does it need a registered local company? This guide names none, because it could not confirm them on official pages. Put the questions to a local adviser and to the official developer page of each scheme.

      Stage 4: build

      • Buy or build. Use ready-made parts for what every product needs and custom work for what makes yours different. Custom software or off the shelf explains how to decide.
      • Ownership. The company should own the code, the cloud accounts and the store accounts. Who owns the code in a software project lists the clauses to check.
      • Rhythm. Ask for working software every few weeks. Test on real phones in both languages.
      • Accounts with long lead times. If the product includes an app, start the store accounts now. Apple's D-U-N-S page says to allow up to 5 business days to receive the number and up to 2 more for Apple to receive it. Google says applying for a number can take up to 30 days, and payment checks up to 5 days. Mobile app or mobile website covers the account rules.

      A product engineering team should agree these four points in writing before the first sprint.

      Data location and personal data

      Your product will hold personal data, even if only names and phone numbers. The UAE government portal names Federal Decree Law No. 45 of 2021 on the protection of personal data, in force since 2 January 2022 (page updated 4 December 2025). The page says the law covers processing of personal data and sets requirements for sending data across borders. It gives no more detail on transfers. For Saudi Arabia, Qatar, Kuwait, Bahrain, Oman and Iraq, no official text was opened for this article, so ask for the current text in each market.

      Questions for an adviser:

      • Which country's law applies to a user in each market, wherever your servers sit?
      • May personal data leave the country, and on what conditions?
      • Do health, finance or government customers add data location rules?
      • What must you tell users, and how do they ask you to delete their data?
      • Who do you notify, and when, if data is lost or stolen?

      Hosting follows from the answers. Where to host a website for Gulf customers explains regions and speed.

      Stage 5: launch

      Market order. Pick one country first. Choose it by language, payments, identity, rules and support, not by market size alone. For an iPhone app, Apple's App Store Connect help says you can choose the countries or regions where it is available and change that at any time, so a one-country start is possible.

      Working weeks. The UAE federal government moved to a Saturday and Sunday weekend on 1 January 2022, with a half day on Friday from 7:30 am to 12:00 pm. The governments of Abu Dhabi, Dubai, Ajman, Umm Al Quwain, Ras Al Khaimah and Fujairah use a similar system, while the Sharjah government works Monday to Thursday and rests Friday to Sunday (u.ae, updated 12 August 2026). In Saudi Arabia, a copy of the Labor Law on the ministry website (Royal Decree dated 2005) says Friday is the weekly rest day for workers, and an employer may move it for some workers after notifying the labor office. The copy is for viewing only, so get the current text from the authorities. These pages describe government entities, so ask each partner, bank and courier which days they work. For Qatar, Kuwait, Bahrain, Oman and Iraq, ask the relevant authority or a local adviser.

      The result is practical. A late-week release lands differently in each country, because Friday is a half day for some and a rest day for others. Choose the release day per market, and publish a support calendar of who answers on which day, in which language.

      Ramadan and Eid. The UAE portal says the Islamic holidays, including Eid al-Fitr, follow moon sighting (page updated 29 October 2026). It also says private sector working hours fall by 2 hours a day in Ramadan. A Saudi ministry page says actual working hours for Muslim workers must not exceed 6 a day or 36 a week during Ramadan. So partners and your own team may run shorter days. Avoid a major release in the days before Eid, agree a freeze window, and name who can approve an emergency fix. Ramadan and Eid 2027 store checklist covers the dates to watch.

      Stage 6: learn

      Choose three measures before launch and write down what result would make you change course. The Service Manual's beta guidance says teams keep tracking the success measures set earlier, keep enough capacity to keep improving, and make sure support staff can help users who struggle. Start with a private group, as private beta does, and widen when the numbers and support load allow.

      Each month, make one of four decisions: fix what is broken, grow what works, change direction, or stop. Write down the reason.

      A stage-gate checklist

      Do not move to the next stage until you can tick every line.

      1. Gate 1, problem and user. One sentence on who has which problem. One named first group. One first country.
      2. Gate 2, discovery. You have talked to real users and tested a prototype with a few people from each group, in small rounds. You know the constraints. Decision recorded: go, change or stop.
      3. Gate 3, smallest release. One journey, start to finish. A list of what waits. Language, direction and numerals decided. Sign-in and payment questions sent to advisers.
      4. Gate 4, build. Code and accounts owned by the company. Store and D-U-N-S applications started. Data and hosting questions answered in writing. Tests on real phones in both languages.
      5. Gate 5, launch. Release day chosen per country. Support calendar published. Ramadan and Eid freeze window agreed. Rollback plan written.
      6. Gate 6, learn. Three measures and their review date set. A named person owns support. The monthly decision (fix, grow, change or stop) is in the diary.

      This is general information, not legal or tax advice. Check the current rules or ask a qualified adviser before you decide.

      ESTASOFT can help with product engineering. To start, send a short brief on the contact page. If the first release will be an app, read mobile app or mobile website first.

      Sources

      Written by
      ESTASOFT

      Need help with a project?

      Share a short brief. We reply with next steps.

      Start a project Book a call

      Book a call

      30 minutes. Free.

      Tell us about your project and we will suggest a time.

      Send a request

      Or email us at info@estasoft.com

      Cookie preferences

      Necessary

      Needed for the site to work. Always on.

      Always on

      Preferences

      Remember choices such as language and region.

      Analytics

      Help us understand which pages are useful.

      Marketing

      Used to measure and improve campaigns.