A first version that real users can try in weeks

An MVP is not a cheap copy of the final product. It is an experiment with a question attached: will this user complete this task and come back? Everything that does not help answer that question waits. That usually means one user role, one primary workflow, a basic admin view for your team, and the minimum notifications needed to keep the loop closed.

The decisions that matter most are made before a line of code. Which customer segment do you test first? What does success look like in numbers you can measure within a pilot, such as completed orders or returning accounts? Which parts can be manual behind the scenes (a team member approving requests, for example) so you learn the process before automating it?

We write this down as a one-page scope with a not-now list. It is the document we return to whenever a new idea appears. Good scoping typically takes one to two weeks and is the cheapest insurance in the whole project.

Retrofitting Arabic later costs more than building it now. Right-to-left layout touches spacing, icons, tables, forms and charts, so we set the interface up bilingual from the first screen. Dates can show Gregorian and Hijri, numbers follow the format your users expect, and content is managed in both languages.

If the pilot collects personal data, the Personal Data Protection Law applies. We design consent, purpose and deletion handling into the first version, and we can host in the Kingdom when a customer or sector requires it. If your product issues invoices, ZATCA e-invoicing requirements shape the data model early, so it is far cheaper to plan for them now than to rework a live system.

Payments follow the same logic. We integrate the gateway your first customers actually use, including mada, and keep it behind a switch so you can run the pilot free and charge when the evidence supports it.

The most common failure is an MVP that works and then cannot grow. We avoid it with a few cheap early choices: a clean data model, separation between your business logic and the interface, automated tests on the core workflow, and a deployment pipeline from the first week. None of this slows version one noticeably, and all of it saves months later.

When the pilot shows traction, the next steps are usually a multi-tenant architecture, a billing model and an integration or two. Because the code and the architecture notes are yours from day one, you can continue with us, with your own team, or with another vendor.

A typical path is a discovery sprint of one to two weeks, a build of four to six weeks, and a two-week pilot window with analytics before the version-two decision. We give you ranges at the start and a fixed price for version one once scope is signed.