Decide what to build before you pay to build it

Discovery runs in four movements. First, alignment: a workshop with the people who will own the product, to turn scattered opinions into a single problem statement and a short list of success measures. Second, research: structured conversations with the people who would actually use it, in the language they work in, focused on what they do today and where it hurts.

Third, we map assumptions. Every product idea rests on beliefs about the user, the process, the price and the technology. We list them, rank them by how badly the project suffers if they are wrong, and design the cheapest test for the top ones. Often that test is a clickable prototype put in front of real users, which costs a fraction of building the feature.

Fourth, we turn findings into a decision: what to build first, what to defer, what to drop, and what it costs in time and money. The output is a document you can hand to a board, an investor or a different development team.

Research done only in English, or only with people who resemble the founding team, misses the market. We recruit and interview in Arabic and English, and we observe how work actually happens: approval chains, the role of WhatsApp, paper stamps that still matter, and the tools that are already trusted.

Regulation shapes scope early. If your product touches personal data, the Personal Data Protection Law affects what you may collect and where it can sit. If it issues invoices, ZATCA e-invoicing rules affect the data model. If it serves banks, insurers or payment flows, Saudi Central Bank requirements enter the picture, and if it serves government or critical sectors, National Cybersecurity Authority controls shape hosting and access decisions.

We do not give legal advice, but we surface these constraints in discovery, mark which ones need your legal or compliance team, and price their effect on the roadmap. Finding that a hosting requirement doubles an estimate in week two is much better than finding it in week twelve of a build.

The deliverables are practical: a problem and user definition, research findings with quotes, a ranked assumption map, a tested clickable prototype, technical notes, and a phased roadmap with time and cost ranges. We also give an honest recommendation, which is sometimes to narrow the scope, sometimes to run one more test, and occasionally not to build.

The decision belongs to you. Many clients take the roadmap straight into an MVP with us. Others use it to run a tender, brief an internal team, or support an investor conversation. Nothing in the pack is locked to us, and the prototype files and research are yours.

Timelines vary with how fast we can reach users. A standard sprint is two to four weeks. If users are hard to reach, such as hospital executives or procurement heads, we say so at the start and plan the extra recruitment time rather than hiding it inside the estimate.