How to build an approval workflow app for a small Gulf company: purchase requests, in Arabic and English

In most small companies in Dubai, Riyadh or Doha, a purchase request travels like this: someone sends a photo of a quotation on WhatsApp, the manager replies "ok" two days later, finance asks "who approved this?" at month end, and nobody can find the message.

None of that is a software problem at first. It's a missing record. There is no single place that says what was requested, who approved it, when, and for how much. An approval workflow app is just that record, plus a few rules about who has to say yes.

This article walks through building one for a typical 20–80 person Gulf company: a trading firm, a clinic group, a real estate office, a training centre. It covers what to decide on paper first, then a step-by-step build in Mythex with the prompts you'd actually type, and the honest limits.

Decide the rules before you build anything

Most approval apps fail because the rules were never agreed, not because the tool was wrong. Spend 30 minutes with the person who signs the cheques and write down:

1. What needs approval. Purchases over a threshold, travel, petty cash top-ups, new suppliers. Start with one type. Purchase requests are the usual winner because they touch money.
2. The thresholds. For example: under AED 2,000 the line manager approves; AED 2,000–20,000 needs the line manager and finance; over AED 20,000 also needs the general manager.
3. Who covers when someone is away. Summer travel and Ramadan schedules are when approvals stall. Name a delegate for each approver.
4. What a request must include. Supplier name, amount, currency (AED, SAR, QAR, USD), cost centre or branch, reason, and at least one quotation attached.
5. What happens after approval. A purchase order number, a note to the supplier, a line for finance to pay. Decide whether the app does that or just records the decision.

Write the thresholds as a short table. You will paste it straight into the build prompt.

Step 1: Describe the app

In Mythex you describe the app in a chat and it builds the screens, the database and the logic, with a live preview next to the chat. A first prompt that works well:

Build a purchase request approval app for a company with three branches (Dubai, Abu Dhabi, Sharjah). Employees submit a request with: supplier name, amount, currency (AED, SAR, USD), branch, cost centre, reason, needed-by date, and one or more quotation files (PDF or photo). Approval rules: under 2,000 AED the line manager approves; 2,000 to 20,000 needs the line manager then finance; over 20,000 also needs the general manager. Each step can approve, reject with a reason, or send back for changes. Keep a full history of every decision with who and when. Give each role its own home screen: employees see their requests and status, approvers see what's waiting for them, finance sees approved requests ready to pay.

What you get back is a working app: a request form, a database table for requests and one for decisions, file storage for the quotations, and three role-specific screens. Check the preview by submitting a fake AED 5,000 request and walking it through both approvers.

Step 2: Add Arabic, properly

Many Gulf teams have staff who prefer Arabic and managers who work in English. Ask for both from the start:

Make the whole app bilingual, Arabic and English, with a language switch in the header. In Arabic the layout must be right-to-left. Keep numbers and amounts in Western digits in both languages, and show amounts with the currency code, e.g. "AED 12,500". Dates in Gregorian format DD/MM/YYYY.

Things to check in the preview, because these are where bilingual apps break:

• Mixed lines like "Supplier: Al Futtaim Trading LLC" inside Arabic text keep their order.
• The amount field still accepts input correctly when the page is right-to-left.
• Status labels are translated ("بانتظار الموافقة" for pending, not left in English).
• The PDF quotation preview isn't mirrored.

If something is off, describe it in the chat ("in Arabic the amount column is cut off on mobile") and it gets fixed in the same project.

Step 3: Delegates and reminders

Approvals that sit for a week are the real cost. Two prompts:

Each approver can set a delegate and a date range (for example annual leave). During that range, requests that need them go to the delegate instead, and the history records "approved by X on behalf of Y".

If a request waits more than 48 hours at one step, show it in red on the approver's screen and send the approver an email reminder. Send the requester an email whenever their request is approved, rejected or sent back.

Email reminders are the dependable channel here. WhatsApp is where Gulf teams actually talk, but sending WhatsApp messages automatically needs a WhatsApp Business API provider and an approved message template. You can ask Mythex to wire one in, but plan for that set-up time and the provider's per-message cost; don't assume it's a checkbox.

Step 4: A purchase order number and a finance view

When the final approval is given, generate a purchase order number in the format PO-2026-0001, incrementing per year. Finance sees a table of approved requests with PO number, supplier, amount, branch, and a "paid" checkbox with a payment date. Add a monthly total per branch and per cost centre, and an export to Excel.

This is the screen the finance team will actually live in. The monthly totals per branch answer the question every Gulf owner asks at month end: "why did Sharjah spend so much?"

Step 5: Lock it down to your team

An approval app holds supplier prices and spending, so it shouldn't be on the open internet.

• Sign-in: ask Mythex to add sign-in with roles (employee, line manager, finance, general manager). It builds that on your app's own database, or with a provider like Google if you prefer.
• Members-only apps: on the Business plan, you can publish the app so only signed-in members of your Mythex team workspace can open it.
• Google Workspace SSO: also on Business. If your company runs on Google Workspace with a verified domain, colleagues at your domain sign in with their work account and join the workspace automatically.
• Your own domain: publish it at something like approvals.yourcompany.ae.

Step 6: Test with real requests for two weeks

Run the old way and the new app side by side for two weeks with one branch. Track three things:

1. Average time from request to final approval.
2. Requests that got stuck (more than 3 days at one step).
3. Requests finance had to chase because something was missing.

If the first number drops and the third goes to almost zero, roll it out to the other branches. If people keep sending WhatsApp photos instead, the form is too long; cut fields until it takes under a minute on a phone.

What it costs and what you get

You can build and try this on the Free plan. For a team you'll want either Pro ($25/month) for one builder, or Business (from $50/month) if several people will build and you want the shared workspace, roles, members-only apps and Google Workspace SSO. Current prices are on the pricing page. The app itself comes with a Postgres database and file storage for the quotations, and the code is yours: you can edit it, export it, or sync it to GitHub on Pro.

If you want a head start, there's an approval tracker template you can open and adapt instead of starting from a blank prompt.

Honest limits

• It's not an ERP. If you already run Odoo, SAP Business One, Zoho Books or Microsoft Dynamics, check their built-in purchase approvals first. A custom app makes sense when your rules don't fit theirs, or when you don't have an ERP at all and the spreadsheet is the system.
• Accounting integration is extra work. Pushing approved POs into your accounting system needs that system's API and some testing. It can be done, but it's a second project, not part of the first afternoon.
• WhatsApp notifications need a provider (see Step 3).
• You still need someone who owns it. Somebody has to add new staff, change thresholds when the GM changes their mind, and look at the stuck-requests list. Budget an hour a week.
• Mobile apps are web screens. On Pro, Mythex can wrap the app for Android and iPhone, but those are your web screens in an app shell, not a fully native interface. For an approval app that is usually fine.

For teams

The pattern here, one record, clear rules and one screen per role, is the same for leave requests, travel approvals, new-supplier onboarding, discount approvals in sales, and maintenance requests in property management. Once the first one works, the second one takes an hour, because the roles, sign-in and workspace are already there.

Start with the request type that causes the most month-end arguments. In most Gulf SMEs, that's purchases.