Enterprise systems
Meeting and approval workflows, HR and attendance, role-based access, digital signature, single sign-on through Azure AD.
Tawtheiq · HR Management System— Mobile app developmentMobile app development,
Mobile app development,
both stores from one build.
Production Flutter apps for enterprise systems, field operations, marketplaces and booking. Arabic and English, working offline, and roughly half the cost of building each platform natively.
Eight apps in production across six sectors, 2022–2026 — counted from the portfolio rather than claimed.
We will tell you on the call if a mobile web app would do the job instead.
2Platforms from one build — roughly half the cost of going native twice
OfflineWork is captured with no signal, so field staff never lose an entry
AR + ENBoth languages from day one, with the layout mirrored rather than translated
11–16 wksFrom start to live in both app stores
What the engagement gives you. The portfolio figures behind these — apps shipped, screens built, sectors covered — sit with the work below, where they evidence the capability rather than open with it.
— The work itself A hundred and forty of these, across eight apps.
Real captures from the shipped builds, not mockups. One client's branding is redacted pending permission.
— What gets builtFour kinds of app,
Four kinds of app,
one codebase.
Not templates. Every item below shipped inside an app that is in somebody's hands right now.
Field operations
Daily task calendars, site records, consumption and distance logging — captured offline and synced when the signal comes back.
SOA Fuel System · DynamicMarketplaces
Listings, categories, search and filtering, seller accounts, in-app messaging, media upload from the phone.
Cham SaleBooking & services
Availability, reservations, itineraries and payment flows for hotels, tourism and course enrolment.
Nilz · Leaders Institute— The differenceA field app that needs a signal
A field app that needs a signal
is a clipboard.
Most demo apps assume coverage. The crews these are built for spend the day where there isn't any — generator sites, depots, roads between them.
Capture offline
Site visits, fuel volumes and distances are written locally the moment they happen, whether or not the network agrees.
Sync on reconnect
Everything queued goes up when coverage returns, in order, without the technician thinking about it.
Say which state you are in
An explicit online/offline indicator and a manual sync button, because a technician needs to know a record is safe before leaving a site.
Offline-first is a decision made at the data layer on day one. It cannot be added to a finished app.
— Arabic and EnglishNot a translation layer.
Not a translation layer.
The layout turns around.
Every app here ships both languages. In Arabic the navigation, the icons, the swipe direction and the form flow all mirror — the same discipline this site holds itself to.
— The workEight apps,
Eight apps,
all in production.
Four are on Google Play and linked below. The other four have no public store listing — enterprise and internal deployments — so there is nothing to link, and saying so is better than a dead button.
8Apps delivered to production, all eight listed below
140+Screens designed and built across them
6Sectors, from enterprise governance to real estate
4Years of continuous delivery, 2022 to 2026
Counted from the shipped work on this page — scope rather than outcome. Where a client has given us their results, they appear in that project's case study.
Tawtheiq
2024 — 2026Enterprise meeting-minutes platform with an AI copilot
End-to-end platform for the meeting lifecycle: agendas, minutes, decision voting, actions and approvals — with an AI copilot that runs it by chat.
- Flutter
- Dart
- Bloc
- Azure AD
- REST API
- Firebase
- AI integration
- Biometrics
Read the case study No public store listing
SOA — Fuel System
2024 — 2026Field-operations app for fuel logistics
Field app that manages refuelling trips, generator sites and maintenance tasks, with sync built for low-coverage areas.
- Flutter
- Dart
- Bloc
- REST API
- Firebase
Read the case study No public store listing
HR Management System
2023 — 2024Face-recognition attendance & HR
Dual-role HR app for employees and managers: face-recognition attendance, leave requests, task tracking and surprise check-ins.
- Flutter
- Dart
- Bloc
- REST API
- Firebase
- Face recognition
Live on Google Play
Nilz
2022 — 2023Hotel booking & tourism services
Arabic-first travel app to search, compare and book hotels, with visitor services, offers, booking management and a rewards wallet.
- Flutter
- Dart
- Bloc
- REST API
- Firebase
Live on Google Play
Cham Sale
2022 — 2023Classifieds marketplace
Marketplace for buying and selling cars, property, phones and furniture, with seller profiles, ratings and direct contact.
- Flutter
- Bloc
- REST API
- Clean architecture
Live on Google Play
Leaders Institute
2023 — 2024Leadership-development institute app
Official app for a leadership institute: applicant registration, entity accreditation requests, document uploads, news and programmes.
- Flutter
- Bloc
- REST API
- Clean architecture
Live on Google Play
Dynamic
2023 — 2024Vehicle shipping & inventory
Logistics app for vehicle inventory and pre-shipment condition capture, with VIN and barcode scanning plus loading verification.
- Flutter
- Bloc
- REST API
- Clean architecture
No public store listing
New Rental
2022 — 2023Property & tenant management
App for managing property portfolios: occupancy, lease renewals, rent payments, overdue tracking and tenant management.
- Flutter
- Dart
- Bloc
- REST API
- Firebase
- SQLite
No public store listing
— The full portfolioAll one hundred and forty-nine screens,
All one hundred and forty-nine screens,
in your inbox.
Every screen from all eight apps, the store links for the four that are public, and what each build had to solve. We will email it to you now.
On its way.Check your inbox in the next minute. If it has not arrived, look in spam and then tell us.
— How it is builtOne codebase,
One codebase,
two app stores.
Flutter with a clean architecture and Bloc for state, talking to REST APIs. One team, one repository, both platforms — and a structure that survives being handed to someone else.
- Flutter · DartiOS and Android from one codebase
- BlocPredictable state, testable in isolation
- Clean architectureLayers that survive a handover
- REST APIsAgainst whatever the business already runs
- FirebaseNotifications, crash reporting, analytics
- Azure ADEnterprise sign-on where it is required
— Questions
The ones that decide it.
What does one codebase actually save us?
Roughly half the cost of building each platform natively, because one team writes one app and ships it to both stores on one release cycle. It is not a free lunch: anything touching the camera, background location, push permissions or a store review still gets platform-specific work, and we scope that separately rather than pretending Flutter removes it.
Do the apps work with no signal?
Where the job needs it, yes. On the field-operations build, visits, fuel volumes and distances are written to the device the moment they happen and sync when the network returns, so an agent in a dead zone never loses an entry. Offline-first is a design decision made at the start; it is expensive to retrofit and we will tell you at scoping whether you need it.
Do you have business results from these apps?
No, and we will not invent them. The portfolio documents what was built and shipped — eight apps in production, 140+ screens, six sectors between 2022 and 2026 — and it contains no adoption, revenue, hours-saved or time-reduced figures at all. Those are scope figures and we label them as scope everywhere they appear. We are asking those clients for outcome data and will publish it when we have it in writing.
Can we see them in the app stores?
Four of the eight carry a public Google Play listing. The rest are enterprise deployments distributed inside an organisation. We state only whether a public store listing exists, because that is the fact anyone can check — we do not describe distribution arrangements we cannot evidence.
Can you name the clients?
Partly. One is a national telecom operator, and we do not publish their name without their written permission even though our development partner's own portfolio names them. Another client is not named anywhere in our source material, so we will not guess. Where a name is cleared, we use it.
Who owns the code?
You do, outright. The repository is in your own accounts from the first commit, along with the signing keys and the store listings. There is no licence to renew and nothing stops working if you stop paying us.
Is Arabic a translation layer?
No. The layout mirrors — navigation, back gestures, list order, form alignment and number formatting — rather than the strings being swapped inside a left-to-right shell. Arabic is set up in the first week of the build, because retrofitting it means revisiting every screen.
How do we start?
Send the idea and who uses it. A thirty-minute call is usually enough to say whether this needs a native app at all — for a lot of internal tools, a mobile web app is the honest answer and we will say so.
— StartSend the idea.
Send the idea.
Get a scope back.
Tell us what the app has to do and who uses it. You get a written view of scope, duration and the right stack — no obligation.