Mobile Development

Geexar is an app development company in Saudi Arabia that builds custom iOS and Android applications for businesses that need software, not a template. We were founded in 2018, our head office is in Riyadh, and our production team works from El Mansoura in Egypt — which is why we can staff a full product team (design, mobile, backend, QA) on a single project without subcontracting it out.

We build three kinds of mobile product. Consumer apps that need to survive real traffic: marketplaces, ride-hailing, wallets, booking and delivery. Business apps that replace a manual process — field reporting, inspections, sales force tools, internal approvals. And companion apps for an existing website or ERP, where most of the work is the API layer and the data model rather than the screens. Every project includes the backend, the admin dashboard and the store submissions, because an app without those three things is not a finished product.

If you want a number for your own project, request a quote — we scope before we price rather than publishing a figure that will not match your requirements.

We use the same six-phase process on every mobile project so you always know what is being produced and what you have to approve.

1. Discovery and requirements. Workshops with your team to agree the goal of the app, the audience, the competing apps and the success metrics. Output: a signed requirements document, a feature list split into launch scope and later phases, and the integration list (payment gateway, SMS, maps, ERP, identity).
2. Architecture and data model. Before any screen is designed we agree the entities, the API contract and the hosting plan. Output: a data model, an API specification and a security plan covering authentication, roles and data storage.
3. UI/UX design in Figma. Wireframes first, then a full clickable prototype in Arabic and English with RTL layouts designed rather than mirrored. Output: an approved prototype and a component library your app is actually built from.
4. Development in sprints. Mobile client and backend built in parallel, with a working build available to you throughout so feedback lands while it is still cheap to act on. Output: builds delivered to TestFlight and an internal Android track at the end of each sprint.
5. Testing and UAT. Functional, performance, security and device-compatibility testing, then a user acceptance round with your own team on real devices. Output: a test report, a fixed defect log and your sign-off.
6. Launch and post-launch. Store listings, screenshots, privacy declarations and the Google Play and App Store submissions, then monitoring of crashes, performance and user behaviour. Output: live apps on both stores, analytics configured, and a maintenance plan.

Timelines are set in the proposal once the launch scope is agreed, because a two-screen internal tool and a marketplace with payments are not the same project.

We deliberately keep to a small, well-understood stack so that any developer on our team can pick up any project — and so that you can hire against it later if you take the code in-house.

• Flutter (Dart) for cross-platform iOS and Android from one codebase. This is our default for consumer apps: one team, one release cycle, native-feeling performance.
• React and Next.js for admin dashboards and any web app that pairs with the mobile client.
• Laravel and PHP for the API layer, business rules, roles and permissions, and the admin backend.
• MySQL as the primary database, with a documented schema and migrations kept in version control.
• Figma for design systems, prototypes and developer handoff.
• GitHub for source control and code review — your repository, your ownership, from the first commit.

Integrations we build routinely include local and international payment gateways, SMS and OTP providers, maps and live tracking, push notifications, and REST connections into existing ERP or accounting systems.

A ride-hailing app in the same category as Uber and Careem: passengers book a ride in seconds, track the driver in real time and see the fare before they confirm, with online or cash payment, driver ratings and instant reporting. The hard parts were live tracking, dispatch and staying stable as the number of concurrent users grows. See the Doroop case study.

A digital wallet app for everyday transactions: user-to-user transfers, an account dashboard with full transaction history, and instant operations kept to as few steps as possible. Security followed current standards for data and transaction protection because the app handles money. Zidcash is published on Google Play. See the Zidcash case study.

An app for pilgrims travelling for Hajj and Umrah that helps them find and book suitable hotels quickly, built around the specific needs of that trip rather than a generic hotel-booking flow. A Saudi-market product where the constraints were seasonality, Arabic-first content and a booking journey that had to be usable by first-time travellers. See the Azdah Saudia case study.

More work is on our projects page.

Geexar works with clients across the Kingdom from its Riyadh head office at 4171 Al Mashtal St, Al Hazm. Riyadh clients are usually enterprise, fintech and government-adjacent teams that need an app tied into an existing back office, so most of that work is API-first. In Jeddah the demand skews to retail, logistics and hospitality apps where the app has to sit on top of a store or a delivery operation. In Dammam and the wider Eastern Province the projects are more often industrial and B2B: field-service apps, inspection and reporting tools, and internal apps for contracting and energy suppliers. We run these projects remotely with scheduled on-site workshops rather than opening a branch in every city, which keeps the same senior team on your project wherever you are. Discovery workshops, UAT sessions and handover training can all be held in Riyadh, Jeddah or Dammam.

We do not publish app prices, because the honest answer depends on the launch scope, the integrations and whether you need iOS, Android or both. What we do publish is how we charge. Fixed-scope projects are quoted as a single figure against a signed requirements document, invoiced against phase milestones. Retained product teams are a monthly fee for an agreed team shape, used by clients who ship continuously after launch. Maintenance and support is a separate monthly agreement covering OS updates, store compliance, monitoring and a fixed number of change hours.

Send us your requirements — even a rough list — and you will get a written scope and a price. Request a quote or book a free consultation.

It depends almost entirely on scope. A single-purpose internal app with one user role and no payments is a fraction of the cost of a marketplace with wallets, live tracking and multi-role dashboards. We scope first and then quote a fixed figure against a signed requirements document, so the number you receive is the number you pay. Send us your requirement list and we will price it.

Our default is Flutter, which produces one codebase that ships to both iOS and Android. For the great majority of business and consumer apps this is the right trade-off: one team, one release cycle, lower maintenance cost, and performance that users cannot distinguish from native. If a project genuinely needs platform-specific capability we will say so during discovery rather than after you have signed.

You do. Work is committed to a repository you own from the first commit, and the handover package includes the code, the database schema, the API documentation and the store accounts. There is no lock-in that stops you moving the project to another team or in-house.

Yes. Store submission is part of the launch phase: listings, screenshots, descriptions in Arabic and English, privacy and data declarations, and managing the review process until the app is live. We publish under your developer accounts so the apps remain your assets.

Yes, and we design them rather than mirror them. Arabic screens are laid out in Figma as Arabic screens, with typography, number formats, date formats and iconography checked by native Arabic speakers on our team. Bilingual Arabic/English apps are our normal case, not a special request.

Apps break for reasons that have nothing to do with your code: iOS and Android release new versions, store policies change, third-party SDKs deprecate. Our maintenance agreements cover OS and store compliance, crash and performance monitoring, and a fixed allowance of change hours each month, with anything larger quoted as a phase.