DEV Community: Mythex

How to Choose AMC Maintenance Software in the UAE (and When to Build Your Own)

Mythex — Wed, 04 Nov 2026 10:03:57 +0000

Most maintenance companies in Dubai, Abu Dhabi and Riyadh sell the same thing: an annual maintenance contract (AMC). AC servicing every quarter, a plumber and electrician on call, a fixed number of emergency visits, maybe a Silver, Gold and Platinum tier. Selling the contract is the easy part. Keeping 300 of them straight is where it falls apart. A villa in Arabian Ranches is three weeks overdue for its AC service, a client is on their sixth "free" emergency call when the contract covers four, and nobody can find the photo that proves the filter was changed.

This guide covers what AMC software has to handle, the main ways to get it, how to choose between them, and how to build a simple version yourself by describing it in plain language. I work at Mythex, the AI app builder in the build section, so weigh that part accordingly.

What AMC software actually has to do

Before you look at any product, write down how your contracts work. Six things matter more than the feature list.

1. Contracts with real limits

A contract is not just a customer name and an expiry date. It has:

The property (villa, apartment, office, warehouse) and the units in it: how many AC units, which brand, where
The tier and what it includes: number of preventive (PPM) visits, emergency call-outs, spare parts covered or charged
Start and end dates, payment terms, and renewal status

The software should count what has been used. "4 of 4 emergency visits used" on screen saves an argument with the client and a free visit you didn't price in.

2. A PPM calendar that generates itself

Quarterly AC servicing for 300 contracts is 1,200 visits a year. Nobody should create those by hand. When a contract is signed, the visits for the year should appear on the calendar, spread so they don't all land in the first week of the quarter. In the Gulf, plan the AC visits before May: a service done in July while every technician is out on breakdowns is a service done badly.

3. Breakdown requests that jump the queue

"AC not cooling" in August, an active water leak, or no power is not the same as "a light is flickering." Write your priority rules down (what counts as an emergency, what your response time promise is) and make the request form ask the questions that sort them. A WhatsApp message saying "AC problem" with no address is the most expensive way to receive a job.

4. A technician view on a phone

Technicians need today's visits in order, the address and location pin, the access notes (gate, building security, the client's preferred time), the checklist for that visit type, and a way to add photos and close the job. If the job can't be closed on site, it gets closed from memory at 9 pm, which is how photo reports go missing.

5. Photo reports the client can see

Facilities managers and villa owners increasingly expect a report after every visit: what was checked, what was cleaned or replaced, before and after photos, and anything that needs a quote. A client portal where they can see their contract, visit history and reports cuts a lot of "did you come yesterday?" calls.

6. Arabic and English

Your office may work in English, but many clients, building managers and some technicians are more comfortable in Arabic. A portal that only works left-to-right in English will feel foreign to a share of your clients.

The three ways to get it

Option 1: An established field service platform

Field service management (FSM) suites cover scheduling, dispatch, mobile apps for technicians, invoicing and often contract management. Some international products are used widely in the region, and several local software houses sell maintenance systems built for Gulf companies.

Good fit if: you have 30+ technicians, need deep accounting integration (and VAT invoicing tied to every job), or run hard FM for large buildings with asset registers and compliance reporting.

Watch for: per-technician monthly pricing that adds up fast, setup projects measured in months, limited Arabic in the client-facing parts, and contract logic that doesn't quite match how your tiers work.

Option 2: A custom build from a software house

Dubai and Riyadh have many agencies that will build exactly what you describe.

Good fit if: your process is unusual, you have a real budget, and you want to own the code and the roadmap.

Watch for: the cost of every change after launch, and a project that depends on one developer staying with the agency.

Option 3: Build a simple version yourself

AI app builders now let a non-developer describe an app and get a working one with a database. This is not a replacement for a full FSM suite. It is a good fit for a company with 5 to 25 technicians whose real problem is "contracts, visits and photo reports live in Excel and WhatsApp."

How to choose: five questions

How many technicians and contracts do you have? Under 25 technicians, a simple tool you control is usually enough. Above 50, the planning and dispatch features of a full suite start to pay for themselves.
Does your accounting need to sync every job? If every visit has to become an invoice line in your accounting system, check the integration first, before anything else.
What do clients see? If clients are asking for photo reports and visit history, the client portal matters more than anything else on the list.
Who changes it? If your contract tiers change every year, ask how a change is made and what it costs. "Send a request to support" and "we change it ourselves in an afternoon" are very different answers.
Can you leave? Ask for a full export of contracts, visits and photos. If you can't get your data out, you're renting your own history.

Building a simple AMC app in Mythex

Here's how the third option looks in practice. You type what you want in plain language, and Mythex writes the code, runs it with a live preview, gives it a Postgres database and file storage, and publishes it to a link or your own domain.

Step 1: Describe the core

Build a maintenance contract app for an AC and MEP maintenance company in Dubai. Clients have annual contracts on Silver, Gold or Platinum plans. Each contract has a property, a list of AC units, a number of PPM visits and emergency call-outs per year, and start and end dates. Show how many visits and call-outs are used and left. Arabic and English with a language switch, right-to-left in Arabic. Seed it with sample contracts.

Step 2: Generate the visit calendar

When a contract is created, schedule its PPM visits for the year, spread evenly, and show them on a calendar by technician. Let the office drag a visit to another day or technician. Flag contracts with an overdue visit.

Step 3: The technician view

Add a technician view for phones: today's visits in order with the address, map link, access notes and a checklist for the visit type. Technicians can add photos and notes and close the visit. Closed visits count against the contract.

Step 4: The client portal and breakdown requests

Add a client portal. A client sees their contract, what is used and left, upcoming visits, and the photo report of every past visit. They can raise a breakdown request with the problem type, a photo and a preferred time. Requests marked as emergencies (no cooling, water leak, no power) go to the top of the office list.

Step 5: Sign-in and roles

Add sign-in with three roles: office staff see everything, technicians see only their own visits, clients see only their own contracts.

Ask for sign-in explicitly. Mythex builds it with your database or a provider you choose; there isn't a ready-made login product, so test each role with a real account before launch.

Step 6: Test it like August

Create a contract, check the visits appeared, close a visit as a technician with photos, then log in as the client and find the report. Raise an emergency and a routine request and check the order. Then publish, on a link or a domain like service.yourcompany.ae.

What you get

A Postgres database holding contracts, units, visits and requests
File storage for visit photos and reports
Your own domain for the client portal
Arabic and English, right-to-left included
Android and iPhone apps of the same project on Pro (an Android download or Google Play internal testing, and TestFlight for iPhone). They wrap the web screens rather than being fully native, which is fine for a technician checklist.

Honest limits

No route planning or vehicle tracking. The calendar shows who goes where; it doesn't optimise the drive across Dubai traffic.
Payments and VAT invoices: Mythex doesn't process payments. Connect a provider such as Stripe with your own account, and keep invoicing in your accounting system unless you build and check that part carefully.
You own the testing. AI-written code can have bugs. Test real scenarios before launch and after every change.
Not hard FM. Large buildings with asset registers, compliance certificates and 100 technicians belong on a full FM platform.

For teams

If several people in the office build and change the app, the Business plan (from $50/month) adds a shared workspace, roles (Admin, Editor, Viewer), per-member credit limits, members-only apps that only signed-in colleagues can open, Google Workspace SSO with your verified company domain, required two-factor sign-in, and publish approvals so nobody changes the live client portal by accident. There's a free plan to try the first prompt; Pro is $25/month. Details are on the pricing page. For a client-facing starting point, see the client portal builder for property and maintenance companies.

Whichever option you pick, start by writing down your tiers, what each includes, your emergency rules and what a visit report must show. That page is most of the work, and it'll make every vendor conversation and every build faster.

How to Build an HVAC Booking System Without a Dev Team

Mythex — Tue, 03 Nov 2026 05:46:43 +0000

If you run a small HVAC or plumbing company, you already have a booking system: a phone, a whiteboard, a shared calendar, and whatever the office manager remembers. That holds up until the first heat wave or cold snap, when two techs end up at the same address and Tuesday's promised quote is still in a notebook on Friday.

This article covers what a 5 to 50 person HVAC shop actually needs, what the established tools do, when to just buy one, and how to build a simpler version by describing it in plain English. I work at Mythex, the AI app builder used in the build section, so weigh that part accordingly.

What a small HVAC shop actually needs

Request intake that saves a callback

A good form saves the callback where you ask what they forgot to say:

Name, phone, email, and whether they're the homeowner, tenant, or property manager
Service address with zip code
Service type: heating, cooling, plumbing, new install, maintenance visit
Equipment (furnace, heat pump, AC, water heater), rough age and brand
What's wrong, and whether the system is completely down
Preferred time windows and access notes (gate code, pets)
A photo of the model plate

A service area by zip code

Driving 50 minutes for a 30-minute call loses money. Keep a list of zip codes you cover, maybe a second list with a trip fee, and tell anyone outside both before they fill in the whole form.

Emergency vs routine

"No heat" in January and "AC is noisy" in April are different jobs. Write down your emergency rules: no heat in freezing weather, no cooling with an elderly person or infant at home, an active leak. A gas smell is never a booking: the form should tell them to leave and call their gas utility or 911.

Quote, then approval

Installs and larger repairs need a written quote, ideally with options (repair vs replace). The customer approves online, you keep a record of who approved what and when, approved quotes become jobs, and unapproved ones get a follow-up date.

Crew capacity per day

A replacement takes a two-person crew most of a day; a tune-up takes an hour or two. Think in capacity per crew per day, not open calendar slots, so overbooking shows before it happens.

Seasonal peaks

Demand follows the weather. Shops that fill quiet spring and fall weeks with maintenance visits keep crews busy and see fewer surprise breakdowns at peak.

Maintenance-plan reminders

A maintenance agreement (usually a spring and a fall check) only pays off if the visits get booked. You need a list of members and who is due this month.

What the off-the-shelf tools do

Mature field-service management (FSM) products exist for this trade:

ServiceTitan targets larger and fast-growing contractors: dispatch board, pricebooks, memberships, marketing attribution, accounting integrations. Expect a real onboarding project.
Housecall Pro and Jobber target small and mid-sized home service businesses: online booking, quotes, scheduling, invoicing, payments, reminders, and a tech mobile app.

Pricing is by plan and often by user; check their pricing pages.

Buy one if you need field payments and financing, accounting sync, truck GPS, a drag-and-drop dispatch board, a parts pricebook, or you have 50+ techs. They've solved problems a home-built app will take a long time to match, and they maintain it for you.

Building makes sense if you want something narrow that matches how your shop works, the big tools feel heavier than you need, or you want the booking page on your own domain with data in a database you control.

Building it step by step in Mythex

Mythex is an AI app builder. You describe the app in chat, it writes the code, runs it in a cloud sandbox with a live preview, attaches a Postgres database and file storage, and publishes it to a public URL or your own domain. There's a starting page for this use case at the HVAC booking system builder.

Step 1: Describe the whole flow

Start with one prompt that covers the full path from request to finished job:

A job board for a family-owned HVAC and plumbing company: customers request a service (heating, cooling, plumbing, new install) with their address and preferred time; office staff see new requests, send a quote the customer approves online, and assign approved jobs to an install crew on a weekly schedule; crews see their jobs for the day and mark them done.

You get a first version with a request form, an office inbox, a quote page the customer opens from a link, a weekly schedule, and a crew day view, backed by database tables. Click through the preview and note what's missing. It's a draft, not a finished product.

Step 2: Add the service area check

Add a service area check. Office staff can manage a list of zip codes we serve and a second list where we add a $45 trip fee. When a customer enters their zip on the request form, check it first: if it's in neither list, show "Sorry, we don't currently serve your area" and don't save the request. If it's in the trip-fee list, show the fee before they submit.

Test it with a zip inside, one in the fee zone, and one outside.

Step 3: Emergency flag and notices

Add a "This is an emergency" checkbox to the request form with the options: no heat, no cooling, active water leak. Emergency requests go to the top of the office list in red with the time they came in. If the customer mentions a gas smell, show a warning telling them to leave the home and call their gas utility or 911, and don't create a booking. When the office confirms a job, send the customer an email and a text that says: "Hi {first name}, your {service type} visit is confirmed for {date}, {time window}. Our tech will call when they're on the way. Reply to this message or call {office phone} to change it."

Email and SMS need a provider (for example Twilio for texts), connected with keys from your own account. Read every test message, because customers will.

Step 4: Maintenance-plan reminder list

Add maintenance plans. A customer can be marked as a plan member with a start date. Each member gets a spring cooling check and a fall heating check. Give the office a "Due this month" list showing members who haven't had their seasonal visit yet, with a button to send them a booking link by email, and let the office filter by zip code so we can group visits by neighborhood.

Step 5: A crew phone view

Make the crew day view work well on a phone: big buttons, the customer's address opens in Maps, a call button for the customer, job notes and the model-plate photo at the top, and "On my way", "Started", and "Done" buttons that update the office view. Add a field for the tech to write what they did and attach photos when they mark a job done.

On Pro you can also build Android (download or Google Play internal testing) and iPhone (TestFlight) apps of the same project. They wrap the web screens rather than being fully native, which is usually fine for a crew checklist.

Step 6: Test it like your busiest week

Walk through it as a customer with a no-heat emergency, as the office quoting and scheduling an install, and as a tech closing a job on a phone. Double-book a crew and see what happens. Then publish to a public link or your own domain, such as book.yourcompany.com.

What the team gets

A Postgres database with your customers, quotes, and jobs; on Pro, GitHub sync and export of the code.
File storage for model-plate photos and job photos.
Your own domain for the booking page.
Staff sign-in, built by the agent when you ask. There's no ready-made login product, so ask for sign-in and roles (office vs crew) and test them.
On Business: members-only apps only signed-in colleagues can open, Google Workspace SSO, and required 2FA. Members-only covers a whole app, so it fits the internal side; one setup keeps the request form as a separate public app that sends requests to the internal one. Ask the agent, then test it.

Honest limits

Payments: Mythex doesn't process payments. To take deposits or card payments, you connect a provider like Stripe with your own account.
No route optimization or truck GPS. The schedule shows who goes where; it doesn't plan the drive.
You own the testing. AI-written code can have bugs; test real scenarios before launch and after each change.
Not a full FSM suite. With 50+ techs, a live dispatch board, and accounting sync on every job, one of the tools above fits better.

For teams

If several people build and change the app, Business (from $50/month) gives you a shared team workspace, roles (Admin, Editor, Viewer), per-member credit limits, members-only apps, Google Workspace SSO with a verified company domain, required 2FA, and publish approvals so nobody changes the live booking page without a second look. Enterprise adds an audit log. A free plan lets you try the first prompt; Pro is $25/month. Details are on the pricing page.

Whichever route you take, write down your intake fields, zip codes, emergency rules, and crew capacity first. That list is most of the work.

How to build your own salon booking app in Dubai (Arabic and English, no per-booking commission)

Mythex — Sun, 01 Nov 2026 05:16:14 +0000

Spend ten minutes in any UAE salon owners' group and you'll see the same question every few weeks: "Which booking software do you use?" The replies split three ways. Some owners love a big marketplace app. Some complain about setup fees, per-booking commissions, or a booking page that doesn't look like their brand. And a surprising number admit they still take most bookings on WhatsApp and write them in a diary at reception.

This guide is for the third and second groups. It walks through what a salon booking app actually needs, then builds one step by step with an AI app builder, using the exact prompts you'd type. At the end there's an honest section on what you give up compared with a ready-made salon platform, so you can decide which route fits your salon.

What a salon in the Gulf actually needs from a booking app

Before choosing any tool, write down how a booking moves through your salon today. For most small and mid-size salons in Dubai, Abu Dhabi, Riyadh or Doha it looks like this:

The client finds you on Instagram, Google Maps or by word of mouth.
They message to book, usually on WhatsApp, often in Arabic, sometimes in English, Russian or Tagalog.
Reception checks who is free: which stylist, which chair or room, how long the service takes.
The booking goes into a diary, a spreadsheet, or a shared calendar.
Someone reminds the client the day before, if they remember.
The client arrives, pays at the counter, and maybe books the next visit.

The pain points are always in steps 2, 3 and 5: messages answered late, double bookings when two receptionists use different diaries, and no-shows because no reminder went out.

So the minimum app is smaller than most software makes it look:

A public booking page showing services, prices and durations, in Arabic and English.
A slot picker that only shows times when the chosen stylist (or any stylist) is free.
An admin screen for reception: today's bookings by stylist, with buttons to confirm, move or cancel.
A client list with visit history and notes ("allergic to this product", "prefers Sara").
Reminders, at least a list of tomorrow's bookings that reception can message, or automatic messages if you connect a provider.

Everything else (gift cards, packages, loyalty points, inventory) can come later.

Step 1: describe your salon in one prompt

In an AI app builder like Mythex you start by describing the app in plain language. Be specific about your services and how your salon works. The more real your description, the less you'll need to fix later. Here's the first prompt:

A booking app for a ladies' beauty salon in Dubai. Arabic and English with a language switch, Arabic right-to-left.
Public booking page: services with category, price in AED and duration (haircut 45 min AED 150, blow-dry 30 min AED 90, colour 120 min AED 450, manicure 45 min AED 100, pedicure 60 min AED 130). Client picks a service, then a stylist or "any available", then a free time slot, and enters name and phone number.
Opening hours Saturday to Thursday 10:00–22:00, Friday 14:00–22:00.
Admin page for reception: today's bookings grouped by stylist, confirm / reschedule / cancel, and a client list with visit history and notes.

Mythex writes the code, creates a Postgres database for services, stylists, clients and bookings, and shows a live preview within a few minutes. Open the booking page in the preview and try to book something, as a client would.

Step 2: fix what doesn't match how your salon works

The first version is never exactly right, and that's fine. You keep refining by chat. Typical follow-ups for a salon:

Each stylist only does some services. Nour does colour and blow-dry, Sara does haircut and blow-dry, Maria does nails only. Only show a stylist for services they do.

Add a 15-minute cleaning buffer after every colour appointment.

When a client books with "any available", assign the stylist with the fewest bookings that day.

Add a "home service" option for manicure and pedicure with an area field (Dubai Marina, JLT, Downtown, Jumeirah) and AED 50 extra.

After each change, book a test appointment again. Try the awkward cases on purpose: two people booking the same slot, a booking that runs past closing time, a Friday morning.

Step 3: make the admin side useful for reception

Reception is the person who will live in this app all day, so ask them what they need. Usually it's something like:

On the admin page add a day view with one column per stylist and bookings as blocks, like a calendar. Let reception drag a booking to another time or stylist.

Add a "walk-in" button that creates a booking for now with the first free stylist.

Add a "Tomorrow" tab listing every booking with the client's phone number and a WhatsApp button that opens a pre-filled reminder message in Arabic or English, depending on the client's language.

That last one is a practical trick. Fully automatic WhatsApp or SMS messages need a messaging provider account (and each message has a cost), but a one-click pre-filled WhatsApp link costs nothing and still cuts no-shows, because reception actually sends the reminders.

If you later want automatic messages, you can ask the builder to connect a provider such as Twilio or the WhatsApp Business API using your own account keys.

Step 4: protect the admin pages

The booking page is public; the admin pages must not be. Ask for it explicitly:

Only signed-in staff can open the admin pages. Add a staff login with email and password, and two roles: Owner (sees everything including revenue) and Reception (bookings and clients only).

Mythex builds the sign-in with your app's own database. It isn't a separate login product, so test it: open the admin URL in a private window and check that it asks you to sign in.

Step 5: publish it on your own domain

When it works, publish. You get a public URL straight away, and you can connect your own domain (for example book.yoursalon.ae) from the project's domain settings. Put the link in your Instagram bio, your Google Maps profile and your WhatsApp Business auto-reply. That's where most Gulf salon clients will find it.

If you want the app on clients' phones, the Pro plan can also turn the same app into an Android app (a download, or Google Play internal testing) and an iPhone app through TestFlight. These are your web screens wrapped as an app, not a fully native app, so for most salons the web booking link is enough to start.

What you get, and the honest limits

What you get: a booking app that's yours. Your branding, your services, Arabic and English, your domain, and your client data in your own database. No per-booking commission: you pay for the builder plan, not per appointment. When something changes (a new stylist, Ramadan hours, a new service), you describe the change and it's done.

What you give up compared with a ready-made salon platform:

No marketplace. Platforms like Fresha or Booksy also list you in their consumer app, which can bring new clients. Your own app only gets the clients you send to it. If most of your new clients come from a marketplace, keep it and use your own app for repeat clients.
Payments need your own provider. Taking deposits online means connecting a payment provider account (Stripe, or a Gulf provider such as Tap or Telr) and asking the builder to add it. Not hard, but it's your account and their fees.
Point-of-sale hardware and inventory aren't included out of the box. If you need a card terminal integration, a dedicated salon POS is still the easier choice.
You are the one who maintains it. Changes are by chat, not code, but someone at the salon has to own the app.

A sensible path for many salons is to build the booking page and reception screen first, run it next to your current system for two weeks, and only switch fully once reception prefers it.

For salon groups and teams

If you run more than one branch, or you have a manager, a marketing person and reception all touching the app, the Business plan adds a shared team workspace. Each person signs in with their own account and role (Admin, Editor, Viewer), you can keep internal apps members-only so only your staff can open them, and Google Workspace sign-in works if your salon uses Google for email. That's useful when the same workspace also holds a staff rota app or a stock list for each branch.

Try it with your own services

The fastest way to know if this route fits your salon is to paste your real service list into the first prompt and see what comes back. There's a salon booking system page with example prompts, and Mythex works fully in Arabic, so you can write the prompts in Arabic too. The Free plan is enough to build and test a first version; the plans and current prices are on the pricing page.

Whatever you choose, write down your booking flow first. A salon that knows exactly how its bookings move will pick the right tool, whether it buys one or builds one.

Retool vs an AI app builder for a small team with no developer: an honest comparison

Mythex — Sat, 31 Oct 2026 05:47:07 +0000

Picture a 25-person company. Operations runs on four spreadsheets, a shared inbox and a lot of Slack messages. Someone in ops says, "We should just build a proper tool for this," and the first name that comes up is Retool, because it's the best-known internal tool platform.

Then the questions start. Who on the team will actually build it? What will it cost when all 25 people use it? Where does the data live, since there's no Postgres database, only the spreadsheets?

This article compares two ways to get that tool: Retool, a low-code platform where you assemble screens on top of your existing data, and an AI app builder like Mythex (disclosure: I work on Mythex), where you describe the tool and it builds a complete app with its own database. Both are good products. They are built for different teams, and the most useful thing I can do here is help you tell which team you are.

All Retool facts below come from retool.com/pricing as of October 2026.

The one question that decides most of it

Do you have someone who can write a SQL query and a bit of JavaScript, and who has time to own the tool?

If yes, Retool is very strong. If no, you will spend most of your time stuck on the parts Retool expects a developer to handle, and an AI app builder will usually get you further, faster.

That is not a knock on Retool. It is how it was designed: you connect a database or API, drag components onto a canvas, and write queries and small bits of logic to wire them together. The finished tools can be used by anyone. Building them is a technical job.

How each one works

Retool. You start from your data sources: Postgres, MySQL, a data warehouse, REST or GraphQL APIs, Google Sheets and many more. You place tables, forms, buttons and charts on a canvas, and each component reads from or writes to a query. Retool also has AI features that generate apps and queries, workflows for scheduled jobs, and mobile apps.

An AI app builder (Mythex). You start from a sentence. You describe the tool, the people who use it and the steps, and the builder writes the code, creates a Postgres database for it, runs it with a live preview and publishes it to a URL. You change it by asking ("add a status column", "managers approve anything over $2,000"), or by editing the code yourself on Pro.

The difference in practice: in Retool, you build the screens on data you already have. In an AI builder, the app and its data are created together.

Cost for a real small team

Pricing models are where small teams get surprised, so here are numbers for one realistic setup: 2 people building, 25 people using the tools.

Retool (annual billing, October 2026):

Free: up to 5 users in total, so it doesn't fit 27 people.
Team: $10 per builder + $5 per internal user per month. 2 × $10 + 25 × $5 = $145/month.
Business: $50 per builder + $15 per internal user. 2 × $50 + 25 × $15 = $475/month. This is the plan that adds audit logs and unlimited environments.
SSO, Git source control and self-hosting are listed on Enterprise (custom pricing).

Monthly billing is higher: $12/$7 on Team and $65/$18 on Business.

Mythex:

Pricing is by credits (the AI work of building and changing apps), not by seats.
Business starts at $50/month for 100 credits with unlimited members. It adds a shared team workspace, roles (Admin, Editor, Viewer), per-member credit limits, members-only apps that only signed-in colleagues can open, and Google Workspace SSO.
Enterprise starts at $680/month and adds an audit log and controls over who can publish, invite and share.

So for 25 users, a per-seat platform and a credit-based one can differ a lot. The honest caveat runs the other way: if your team builds and rebuilds constantly, you'll use more credits, and you should estimate that rather than assume the floor price. The point is to price your real numbers, not the headline.

Building the same tool in both

Take a common small-company tool: an equipment checkout and repair tracker for a field team. Staff check out laptops, tablets and test kits; broken items go to a repair queue; a manager sees what's out and what's overdue.

In Retool, the steps look like this:

Create the tables somewhere (Retool has a built-in database, or you use your own Postgres).
Write queries: list items, check out, check in, mark broken, overdue items.
Drag a table, a form and a few buttons onto a canvas; bind each to a query.
Add logic for "can't check out an item that's already out."
Set up permissions for staff vs managers.

A developer can do this in a day or two. A non-developer can do it too, but steps 2 and 4 are where people get stuck.

In Mythex, the first prompt does most of it:

Build an equipment checkout tracker for a 25-person field team. Items have a name, type (laptop, tablet, test kit), serial number, status (available, checked out, in repair) and current holder. Staff can check an item out and back in. Anyone can report an item as broken with a note and a photo, which moves it to a repair queue. Managers see a dashboard: what's out, who has it, what's overdue (out more than 14 days) and what's in repair. Staff only see their own checkouts.

Then you refine:

Add a due date to each checkout, default 14 days. Email the holder the day before it's due.

Managers can mark a repair as done, which makes the item available again. Keep a history of every checkout and repair per item.

Import our current list from this CSV.

You test in the live preview, fix what's off by describing it, and publish. On Business you make it members-only so only people in your workspace can open it.

Where Retool is the better choice

I'd pick Retool over an AI builder when:

The data already lives in a real database or API and the tool is mostly screens on top of it. Retool's connectors and components are built exactly for this.
You have a developer who wants every query and rule explicit and inspectable.
You need many dense admin screens across several systems (support, billing, ops) for one company.
You must self-host or need SAML SSO with Okta or Active Directory. Retool lists both on Enterprise; Mythex is hosted and offers Google Workspace SSO, not SAML.

Where an AI app builder is the better choice

Nobody on the team writes SQL, and the tool is something your ops person can describe in a paragraph.
The data is in spreadsheets today. The builder creates the database as part of the app, so there's nothing to connect first.
Many people will use it and you'd rather not pay per user.
You want to own the code. On Mythex Pro you can export it or sync it to GitHub and run it anywhere.
The tool faces people outside the team too, like a client portal or a booking page on its own domain.

Honest limits of the AI route

You steer by describing. There's no drag-and-drop component canvas. If you think in layouts, that can feel indirect at first.
It doesn't sit on top of your existing database the way Retool does. It builds an app around its own Postgres database; connecting to an external system is possible, but it's a build step, not a dropdown.
Sign-in for people outside your workspace is something you ask it to build, with your own database or an auth provider. It isn't a separate managed product.
Review what it builds. Test the permission rules ("staff only see their own checkouts") with a real staff account before you roll it out. That's true of any tool, but especially one you didn't wire by hand.

For teams

If you're the person who will build the first tool, you can start on the Free plan and see whether the prompt-and-refine approach fits how you think. When more people need to build and use apps, the Business plan gives you the shared workspace, roles, members-only apps and Google Workspace SSO. If you're weighing more options than these two, there's a longer comparison of Retool alternatives, and current Mythex prices are on the pricing page.

Whichever you choose, do this first: write the paragraph. Who uses the tool, what they record, which steps happen in which order, and who is allowed to see what. That paragraph is the spec for a Retool build and the first prompt for an AI build, and writing it will tell you more about which one you need than any comparison.

How to choose a CRM for a small real estate brokerage in Dubai: the questions that matter before the demo

Mythex — Fri, 30 Oct 2026 05:20:14 +0000

Ask a broker in a 5–30 agent office in Dubai where their leads live, and the honest answer is usually "everywhere". Portal enquiries arrive by email and in the portal's own dashboard. Most of the real conversation happens on WhatsApp, on the agent's personal phone. Viewings are in the agent's calendar, or in their head. The owner sees a spreadsheet at the end of the month, and only if someone remembers to fill it in.

So the office decides it needs a CRM. Then it sits through three demos, each one with a long feature list, and picks the one with the nicest dashboard. Six months later the agents are back on WhatsApp and the CRM has stale data.

The problem is usually not the software. It's that nobody wrote down what the office actually needs before the first demo. This guide gives you the questions to answer first, how the main types of tools compare, and when building your own small CRM makes more sense than buying a big one.

First, write down how a lead actually moves in your office

Before you look at any product, spend an hour with two of your best agents and one admin, and map a single lead from first contact to commission:

Where does it arrive? Property portals, your website form, Instagram, walk-ins, referrals, a developer's launch event. Count roughly how many per week come from each. Most offices find that one or two sources bring most of the volume.
Who gets it, and how fast? Round-robin, by area, by language, by listing owner? Is there a rule that someone must reply within 15 minutes? Who checks?
What happens next? Qualification call, WhatsApp follow-up, viewing, offer, contracts and paperwork, transfer, handover.
Where does it get lost? It's almost always one of three places: no reply on the first day, no follow-up after a viewing, or the agent leaving the company and taking the WhatsApp history with them.

That last point is the one that should drive the decision. In a market with high agent turnover, the real job of a brokerage CRM is to make the client relationship belong to the company, not to the phone in one agent's pocket.

The questions to ask any CRM (including one you build)

Take these into every demo. If the answer is "we can customise that", ask to see it done.

1. Does it handle WhatsApp the way your agents actually use it?

If the CRM can't log WhatsApp conversations, your agents won't use the CRM. There are three levels:

Click-to-chat only. The CRM opens WhatsApp with the number filled in. Easy, but nothing is recorded.
Manual logging. The agent adds a note after each chat. Works only if notes take seconds.
WhatsApp Business API integration through a provider. Messages are sent and stored inside the CRM, and conversations stay with the company if the agent leaves. This costs extra (the provider's fee plus Meta's per-conversation pricing) and needs a verified business number.

Decide which level you need. For a 10-agent office, the third level is usually worth it.

2. Can it take leads from the portals you pay for?

Ask exactly which portals it pulls leads from, whether that happens automatically or by email parsing, and how fast. Also ask whether listings flow the other way: can you manage a listing once and publish it to several portals? If your office lives on one or two portals, that integration matters more than any dashboard.

3. Does it keep the paperwork and permits in one place?

Dubai brokerage has paperwork that a generic sales CRM doesn't know about: the agreements with sellers and buyers, the advertising permit number that must appear on a listing, Emirates ID and passport copies, title deed copies, and the documents for each transaction stage. Check the current requirements with the Dubai Land Department and RERA rather than relying on any vendor's description, then ask whether the CRM has a place for each document and a reminder when one is missing or expiring.

4. Arabic, English, and the client's language

Your clients and some of your agents may prefer Arabic, and others Russian, Hindi or English. Check that the CRM can store names in Arabic correctly, that templates can be written in more than one language, and, if clients will ever see a page (a viewing confirmation, a listing page, a document upload), that it displays right-to-left properly.

5. Who owns the data, and can you get it out?

Ask how you export all contacts, deals and notes, in what format, and whether there's a fee. Ask what happens to your data if you stop paying. A CRM you can't leave is a risk for a small office.

6. What will it cost per agent in year two?

Per-seat pricing looks small in the demo and large when you have 25 agents, an admin and a manager. Add the WhatsApp provider, the portal integration fees and any onboarding fee. Ask for a written quote for your actual team size.

7. Will agents use it on their phones, in a car, between viewings?

Give the mobile app to your most impatient agent for a day. If logging a viewing takes more than 30 seconds, it won't get logged.

The three kinds of tools, compared honestly

Generic CRMs (HubSpot, Zoho CRM, Salesforce, Pipedrive). Mature, good mobile apps, big integration catalogs, and Zoho in particular has a strong presence and partners in the Gulf. The trade-off: they don't know what a listing, a viewing or a portal lead is until someone configures them, and the configuration is where small offices get stuck. Best if you have an admin who enjoys setting things up, or budget for a local implementation partner.

Real-estate CRMs built for the region. They come with listings, portal syndication, viewings and brokerage paperwork already modelled, which saves the most setup time. The trade-offs are usually price per seat, how much you can change, and data export. Best if your process is close to the standard one and you want to be running in a week.

Building your own small CRM. Until recently this meant hiring a developer. Now AI app builders can produce a working CRM from a description, with a real database behind it. Best if your process is unusual (off-plan only, commercial leasing, holiday homes, a mix of brokerage and property management), if you want exactly the screens your agents need and nothing else, or if per-seat pricing doesn't fit your team. The trade-off: you own it, so someone in the office has to look after it, and integrations (portals, WhatsApp API) are extra work you set up yourself.

There's no shame in the first two. If one of them fits your process after the questions above, buy it.

What building your own looks like in Mythex

If you decide to try the third route, here's what a first version looks like in Mythex, an AI app builder: you describe the app in plain language, and it builds it, gives it a Postgres database and file storage, and publishes it. It works fully in Arabic, including right-to-left layouts.

Start with the smallest thing that fixes the leak you found in the mapping exercise. A first prompt might be:

Build a CRM for a 12-agent real estate brokerage in Dubai. Leads have a name, phone, WhatsApp number, source (portal, website, Instagram, referral, walk-in), budget in AED, area, property type, buy or rent, and assigned agent. Stages: New, Contacted, Viewing booked, Viewing done, Offer, Paperwork, Closed won, Lost. Agents see only their own leads; the manager sees all of them. Show leads with no contact in 24 hours in red at the top.

Then add one thing at a time:

Add viewings: each viewing links to a lead and a listing, with date, time and outcome. After a viewing is marked done, create a follow-up task for the next day.

Add a documents section to each deal for the seller and buyer agreements, ID copies and title deed, with a checklist showing what's missing.

Add an Arabic version of every screen with a language switch, right-to-left in Arabic.

Add a WhatsApp button on each lead that opens a chat with a template message in the client's language, and logs the time it was clicked.

That last step is click-to-chat, the first level from question 1. If you later want full WhatsApp Business API logging, that's a separate integration with a provider of your choice, built on top.

Before you show it to the whole office, give it to two agents for a week and watch one number: leads with no contact after 24 hours. If that drops, roll it out. If the agents keep going back to WhatsApp alone, the logging is too slow; cut fields until it isn't.

There's more on this use case on the real estate CRM builder page.

Honest limits of building your own

Portal integrations aren't automatic. Pulling portal leads in means using whatever the portal offers (an API, a lead email, a webhook) and testing it. Many offices start by forwarding portal lead emails into the CRM and automate later.
WhatsApp API needs a provider and Meta's approval for your business number, and costs per conversation.
Someone has to own it. Adding agents, changing stages, fixing a field. Budget an hour a week.
Compliance is your responsibility. A CRM stores what you put in it; it doesn't check that your paperwork meets current DLD and RERA rules.
Phone apps are web screens. On Pro, Mythex can wrap the app as an Android app or an iPhone app (through TestFlight), but it's your web screens in an app shell, not a fully native app. For logging viewings that's usually fine.

For teams

A brokerage CRM is a team tool: several agents, a manager, an admin, and leads that must stay with the company. On Mythex's Business plan (from $50/month), the office gets a shared workspace, roles, members-only apps that only signed-in colleagues can open, and Google Workspace sign-in with your company domain, so a departing agent loses access the day their account is removed. You can build and test the first version on the Free plan; current prices are on the pricing page.

Whatever you choose, buy or build: map the lead first, find where it gets lost, and pick the tool that fixes that one place. The dashboard can wait.

Why a new hire's first week falls apart, and the small onboarding app that fixes it

Mythex — Thu, 29 Oct 2026 05:25:16 +0000

At a 20 to 150 person company, onboarding usually works like this. Someone in HR or ops has a checklist in a Google Doc. A week before the start date they send a few emails: IT for a laptop, the manager for a first-week plan, payroll for the paperwork. Then the new person shows up on Monday and at least one of those things didn't happen.

The laptop is there but has no accounts. The manager is at an offsite. The I-9 is half done. The new hire spends the first morning reading the employee handbook PDF and wondering if they made a mistake.

None of this is because people don't care. It's because onboarding is a process with five or six owners, and the checklist only lives in one person's head and one person's doc. This article explains where it breaks, what a small onboarding app needs to fix it (much less than an HR suite), and how to build one in an afternoon with an AI app builder, including the actual prompts.

Where onboarding actually breaks

If you look at the last five hires and ask "what went wrong in week one?", the answers fall into a few buckets.

Tasks with no owner and no date. "Set up Slack" is on the checklist, but nobody is assigned and nobody knows it has to happen before Monday. Everyone assumes someone else did it.

Tasks that depend on other tasks. IT can't create accounts until HR confirms the legal name and start date. The manager can't book the welcome lunch until the start date is final. When the first task slips, everything after it slips silently.

No single view of "who starts when." With two or three hires a month, HR knows the dates. With eight a month across three teams, nobody can see at a glance who is starting next week and what's still open for each of them.

The new hire is left out of their own onboarding. They get a stream of emails from different people with different links: sign this, read that, upload your ID. They can't see what's done and what's left.

Nothing is learned from the last hire. Every onboarding is rebuilt from the doc. Nobody tracks that the laptop is late every time, or that new salespeople always wait three days for CRM access.

A shared spreadsheet helps a little. An onboarding app with owners, due dates relative to the start date, and a view per role fixes most of it.

What a small onboarding app needs (and what it doesn't)

You don't need a full HRIS to fix week one. You need five things.

A template of tasks per role. "Every hire" tasks (paperwork, accounts, handbook), plus extra tasks for "sales" or "engineering" or "warehouse." Each task has an owner role (HR, IT, manager, payroll, new hire) and a due date expressed relative to the start date, like "5 days before" or "day 1."
A new-hire record. Name, role, team, manager, start date, work location. Creating it copies the template tasks and calculates the real dates.
A view per owner. IT sees only IT tasks across all upcoming hires, sorted by due date. Managers see only their own hires. HR sees everything.
A new-hire page. The person starting sees their own checklist: what to sign, what to read, who their buddy is, and where to be on Monday.
A "what's late" list and a weekly summary. Overdue tasks, grouped by owner, so the Monday HR check-in takes two minutes.

What you can leave out at first: performance reviews, payroll, benefits enrollment, e-signature workflows. Your payroll provider (Gusto, Rippling, ADP, Justworks) already handles the legal forms. Link to it from the checklist instead of rebuilding it.

Building it, step by step

Here's how this looks in Mythex, an AI app builder where you describe the app in plain language and it writes the code, gives it a Postgres database, and publishes it. The same plan works with any builder or with a developer; the prompts below just make the steps concrete.

Step 1: describe the data and the roles

Start with one prompt that sets up the structure. Being specific about owners and relative dates saves a lot of back-and-forth later.

Build an employee onboarding app for a 60-person company. Data: onboarding templates (name, e.g. "Every hire", "Sales", "Engineering"), template tasks (title, description, owner role: HR / IT / Manager / Payroll / New hire, due offset in days relative to start date, link), new hires (name, personal email, role, team, manager, start date, location), and onboarding tasks copied from the templates when a new hire is created, with a real due date, status (to do / done / blocked), owner, and a note. Roles for staff: Admin (HR), IT, Manager, Payroll. HR can see and edit everything.

The first version usually gives you the tables, a list of new hires, and a form to add one. Check that creating a new hire really copies the tasks and calculates dates. Ask for a fix if it doesn't:

When I add a new hire with template "Every hire" + "Sales", copy every task from both templates and set the due date to start date plus the offset. Show the count of tasks created.

Step 2: give each owner their own view

Add a "My tasks" page. IT users see only tasks with owner IT for hires starting in the next 30 days, sorted by due date, with overdue ones in red at the top. Managers see only tasks for their own direct reports. Each task has a one-click "Done" and a "Blocked" button that asks for a reason.

This is the screen that changes behaviour. IT doesn't need to read the onboarding doc any more; they open one page on Monday and work down the list.

Step 3: the new-hire page

Add a page for the new hire that shows only their own tasks with owner "New hire", plus a welcome block: start time, address, who to ask for, their manager and buddy, and a short first-week schedule. It should work well on a phone.

A practical question here is how the new hire gets in before they have a company account. Two common options: send them a private link that only shows their own checklist, or create their company email a week early and let them sign in with it. Decide which before you build, and tell the builder which one you want. Mythex doesn't come with a ready-made login product: the agent builds sign-in into your app using your database or a provider you choose, so say exactly how you want people to get in.

Step 4: the late list and the weekly summary

Add an HR dashboard: hires starting in the next 14 days, each with a progress bar, and a list of overdue tasks grouped by owner. Add an "Export summary" button that produces a short text I can paste into Slack every Monday.

If you want this sent automatically, ask for an email or Slack message every Monday at 9am. That needs an email provider or a Slack webhook, which you'll connect once.

Step 5: improve the template from real data

After two or three hires, look at which tasks were late or blocked most often. Then move them earlier in the template. "Order laptop" at minus 5 days was late three times? Make it minus 10. This is the part spreadsheets never do, because nobody looks back at old tabs.

Add a report: for each template task, how often it was completed late in the last 90 days, and the average days late.

What the team gets

When the app is published, it has its own URL (or your domain, like onboarding.yourcompany.com), its data lives in a real Postgres database instead of a doc, and you can keep changing it by describing what you want.

For HR and ops teams the bigger point is ownership. The app reflects how your company onboards people, with your roles and your order of steps, instead of the generic flow of a large HR suite.

Honest limits

It's not your HRIS or payroll. I-9, W-4, state forms, benefits enrollment and direct deposit belong in your payroll provider. Link to them from the checklist; don't rebuild them.
Account creation isn't automatic. The app tells IT what to create and when. Actually creating Google Workspace or Microsoft 365 accounts from the app needs their admin APIs and careful permissions. Possible later, not in the first afternoon.
Personal data needs care. Keep only what onboarding needs. Don't store Social Security numbers or ID scans in a side app if your payroll provider already holds them.
Someone has to own the template. Budget 30 minutes a month to update tasks when tools or policies change.
If you already pay for Rippling, BambooHR or Workday, check their onboarding modules first. A custom app makes sense when you don't have one, or when your process (shift workers, multiple locations, client-site starts) doesn't fit theirs.

For teams

On the Free plan you can build and try the whole thing. For one person building, Pro is $25/month. If several people in HR and ops will build and edit apps, the Business plan (from $50/month) adds a shared team workspace, roles, members-only apps that only signed-in colleagues can open, and Google Workspace SSO, so the IT and manager views stay inside the company. There's a page on HR and people-ops tools with more examples, and current prices are on the pricing page.

Whatever you use, start with the last hire who had a bad first week. Write down what went wrong, turn each item into a task with an owner and a date, and you have the first version of your template before you build anything.

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

Mythex — Wed, 28 Oct 2026 06:33:24 +0000

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:

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.
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.
Who covers when someone is away. Summer travel and Ramadan schedules are when approvals stall. Name a delegate for each approver.
What a request must include. Supplier name, amount, currency (AED, SAR, QAR, USD), cost centre or branch, reason, and at least one quotation attached.
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:

Average time from request to final approval.
Requests that got stuck (more than 3 days at one step).
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.

Can ChatGPT or Claude build an app your team can actually use? What the chat gives you, and the five pieces it leaves out

Mythex — Tue, 27 Oct 2026 05:21:58 +0000

Ask ChatGPT or Claude to "build a time-off request app for my team" and within a minute you'll have something that looks finished. A form with a date picker, a list of requests, maybe an Approve button. Claude shows it as an interactive artifact in a side panel; ChatGPT can preview it in its canvas. It's a genuinely impressive first draft.

Then you try to use it with your team, and it falls apart in quiet ways. The requests your colleague submitted aren't there when you open it. Anyone with the link can approve anything. Nobody gets told when a request comes in. And when someone asks "where does this live?", the honest answer is "in my chat history".

This isn't a flaw in either model. Chat assistants are built to produce code and previews, not to run software for a company. This article explains the gap, what closing it takes, and a step-by-step way to get from a chat prompt to a tool a 20-person team can rely on.

ChatGPT vs Claude for the first draft

For the first draft, the difference between the two is smaller than the internet suggests:

Claude is the quickest from a prompt to a small interactive app you can click around in and share by link. For forms, calculators and simple trackers, it's very good at producing a tidy single-screen app.
ChatGPT is just as capable at writing the code, and its strength is the conversation around it: asking it to explain a function, change a rule, or write the policy text that goes on the page.
Both have coding agents (Claude Code and Codex) that can work on a real codebase, run commands and edit files. Those are tools for people comfortable with a terminal, a repository and a hosting account.

If you want a side-by-side of the plans, in-chat previews, coding agents and prices, we keep one here: ChatGPT vs Claude vs Gemini for building apps. The short version: pick the one you already pay for. The model is rarely what stops a team tool from working.

The five pieces a team app needs that the chat leaves out

Take the time-off example. For it to work for a real team, it needs five things that a chat preview doesn't give you.

1. A database that everyone shares

A chat preview typically keeps data in the browser, or in a storage area tied to the person viewing it. That's why your colleague's request "disappears": it was saved on their screen, not in a shared place. A team app needs one database on a server, with tables like requests, employees and approvals, that every user reads from and writes to.

2. Sign-in, and rules about who can do what

"Anyone with the link" is fine for a calculator. For time off, you need to know who submitted a request, and only managers (or HR) should be able to approve it. That means accounts, roles and checks on the server, not a hidden button.

3. A real address that stays up

A shared chat link isn't a URL you put in the employee handbook. You want something like timeoff.yourcompany.com, running whether or not you have the chat open, with HTTPS and a plan for what happens when it breaks.

4. Notifications and the rest of the workflow

The app is only useful if the right person hears about a request. That's an email to the manager when something is submitted, an email back when it's approved, and maybe a weekly summary for payroll. None of this happens inside a preview.

5. Someone who can change it in three months

Policies change. Next spring you'll want half-days, or a different approver for one department. If the app is a block of code in a chat from October, changing it means finding the chat, pasting the code somewhere, and redeploying it yourself. The tool needs a home where it can be edited and republished without starting over.

You can close every one of these gaps with ChatGPT or Claude plus a coding agent, a hosting provider, a database service and an email service. Plenty of developers do exactly that. If your team doesn't have a developer, that's five accounts and a lot of copy-pasting, which is where most of these projects stall.

Step by step: the same app, built to be used

Here's how the time-off app looks when you build it in an AI app builder that handles the hosting, database and publishing for you. I'll use Mythex, the builder I work on, but the prompts and the order of steps carry over to any similar tool.

Step 1: Describe the workflow, not the screen

Start with who does what, because that's what the chat preview skipped:

Build a time-off request app for a 20-person company. Employees sign in and submit a request with start date, end date, type (vacation, sick, personal) and a note. Each employee has a manager. Managers see their team's pending requests and can approve or decline with a comment. HR can see everything and export a CSV. Store everything in a database.

Being explicit about roles in the first prompt saves a lot of rework. The builder creates the tables and the screens together, so "managers see their team's requests" becomes a real rule on the server, not a filter on the page.

Step 2: Check the data, not just the look

Before polishing anything, open the database and look at the tables it made.

You should see something like employees (with a manager field), requests and a status on each request. Submit two test requests as different people and confirm they both show up in the same table. This is the test the chat preview fails, and it takes thirty seconds.

Step 3: Add the rules your policy actually has

Now add the details that make it yours:

Show each employee their remaining vacation days, starting at 15 per year. Don't allow a request that overlaps an approved one. Weekends don't count toward days used. When a request is submitted, email the employee's manager; when it's decided, email the employee.

Sending email needs an email service behind it (Resend, Postmark, your Google Workspace SMTP); expect to paste in an API key for whichever one you use. Then test the edge cases by hand: a request across a weekend, an overlapping request, a manager trying to approve their own time off. If something's off, describe the bug in plain words and let the builder fix it.

Step 4: Publish it somewhere permanent

Publishing gives the app a public URL straight away, and you can connect your own domain (for example timeoff.yourcompany.com). From then on, changes are made in the same project and republished; nobody has to dig up an old chat.

Step 5: Decide who can open it

For a tool like this, the people who should be able to open it are your colleagues, nobody else. Two ways to handle that:

Keep the sign-in the app already has (employees and managers as users in its own database). That's enough for many small teams.
On a team plan, make the app members-only, so only signed-in members of your company workspace can open it at all, and turn on SSO with your company domain so people use their work Google or Microsoft account and lose access when IT removes them.

Honest limits

It's still software. An AI builder takes away the setup work, not the thinking. If your policy has unusual rules (accrual by tenure, different rules per state), write them down before you prompt, and test them.
It isn't payroll or an HRIS. For a small team, a request-and-approve app is plenty. If you need accruals that feed payroll, compliance reporting or benefits, a dedicated HR system is the right tool, and the custom app can sit next to it for the parts it doesn't cover.
Someone should own it. One person on the team should be the one who changes it and checks it after each change. That's an hour a month, not a job.
You can leave. In Mythex you can edit the code, export it or sync it to GitHub, so a developer can take it over later. Whatever tool you use, check that this is possible before you build something the company depends on.

For teams

If more than one person will build or manage these tools (operations, HR and a team lead, say), a few things matter as much as the app itself:

A shared workspace with roles, so an editor can change the app and everyone else can only use it.
Members-only apps, so internal tools never sit on the open internet.
SSO on your company domain and required two-factor sign-in for the people who build.
Usage by person and per-member limits, so one experiment doesn't eat the team's budget.

On Mythex these are on the Business plan; the details and current prices are on the pricing page.

The takeaway

ChatGPT and Claude are both good at the first ten minutes of a team app: the screen, the form, the idea. The other ninety percent is a shared database, sign-in and roles, a permanent address, notifications, and a place where the app can keep changing. Before you share a chat-built app with your team, run one test: have two colleagues submit something, then check whether you can both see it. If you can't, it's still a draft, and the five pieces above are what turn it into a tool.

Give Claude or Cursor a cloud sandbox, a database and a publish button over MCP

Mythex — Mon, 26 Oct 2026 18:31:13 +0000

Coding agents in Claude, Cursor and Codex are good at writing code. They're weaker at everything around it: a machine to run the app on, a live preview, a database, file storage, secrets and a public URL at the end. Usually you wire that up yourself.

This post shows how to hand all of that to the agent through one remote MCP server. I build Mythex, an AI app builder from Dubai, and this is how its MCP server works. The pattern applies to any MCP server that exposes a sandbox.

What the agent gets

Once connected, the client can:

create or open a project and wake a cloud sandbox
read, write, edit and search files, and run bash
start a preview and read its logs (set_run_config, start_preview, get_preview)
set secrets you provide (keys are listed back, values never are)
add a Postgres database and file storage, make checkpoints, and publish
run a Playwright browser script and get screenshots back in chat
export or import code, sync with GitHub and connect a domain

Every tool result includes a workspace_url, so you can watch the live preview in the browser while the agent works in your editor.

Connect from Claude

Copy the MCP URL: https://mcp.mythex.ai/mcp
Claude → Settings → Connectors → Add custom connector → paste the URL → Connect
A browser tab opens the consent page. Sign in and click Allow access.

Connect from Cursor

Add the server with only the URL (.cursor/mcp.json):

{
  "mcpServers": {
    "mythex": {
      "url": "https://mcp.mythex.ai/mcp"
    }
  }
}

Toggle it on, click Connect when Cursor prompts, and approve in the browser. There are no API keys to paste: it's OAuth with refresh tokens.

A first prompt

Create a new Mythex project called "booking-demo": a React + TypeScript app where clients book 30-minute slots. Store bookings in Postgres, start the preview, check it in the browser and send me a screenshot. When it works, publish it.

The agent creates the project, writes the code in the sandbox, adds the database, starts the preview, checks it with a browser run, and publishes. You get back a preview URL, screenshots and a public URL.

Costs, honestly

Connecting is free. Tool calls need a Mythex Pro account ($25/month), and sandbox time uses Mythex credits.
Your model usage is billed by Claude or Cursor, not by Mythex.
If the account isn't Pro or has no credits, the tool returns an upgrade_url instead of running.

Why do it this way

No local setup. The app runs in a cloud sandbox, not on your laptop.
One place for the boring parts. Database, storage, secrets, checkpoints and hosting stay in one project.
You keep the code. It's ordinary React/TypeScript you can export or push to GitHub.

If you'd rather build in a chat UI, the same projects open in the Mythex web app. It also works in Arabic and 68 other languages.

Docs: https://docs.mythex.ai/features/mcp

ChatGPT vs Claude vs Gemini for building an Arabic app: a test plan for Gulf businesses

Mythex — Mon, 26 Oct 2026 06:11:24 +0000

Most comparisons of ChatGPT, Claude and Gemini for building apps are written in English, about English apps. That misses the part that decides whether a tool works for a clinic in Riyadh, a training centre in Abu Dhabi or a real estate office in Doha: can it build something that works properly in Arabic, for customers who switch between Arabic and English in the same sentence?

I'm not going to hand you a scorecard. The models change every few months, and a ranking from September is stale by December. What doesn't change is what an Arabic business app needs. Below is the test I'd run on each tool before trusting it with a real project, the Gulf-specific details that usually break, and where each of the three fits.

The short version

Claude is the quickest way to get a small interactive tool you can share from a chat. Claude Code is its coding agent for real codebases.
ChatGPT pairs the general assistant with Codex, a coding agent that runs on the web, in a CLI and in your editor.
Gemini has the most "app builder" of the three: Google AI Studio's Build mode can add a Firestore database, Firebase sign-in and hosting on Cloud Run.

All three can write Arabic text and right-to-left layouts. None of them, on its own, gives a non-developer a hosted app with a database, staff logins and a custom domain, except AI Studio on Google Cloud. For the full feature and pricing table, see our ChatGPT vs Claude vs Gemini guide.

Why Arabic apps fail in ways English apps don't

When an AI tool builds an English app badly, you usually see it. When it builds an Arabic app badly, the screenshot often looks fine and the problems show up a week later with real data. These are the ones I check first.

1. Right-to-left is more than dir="rtl". Setting the page direction flips the text. A proper RTL layout also mirrors the navigation, puts the back arrow on the right, flips icons that imply direction (arrows, progress, "next"), and keeps things that shouldn't flip, like phone numbers, prices and logos, the right way round. Ask the tool to switch the page to Arabic and look at the sidebar, the breadcrumbs and every arrow.

2. Mixed text. Gulf data is bilingual inside single fields: an Arabic customer name with an English company name, an address with a building number and a Latin street name, a WhatsApp message that mixes both. Bidirectional text breaks punctuation and number order in ways that are easy to miss. Paste in a real line like "شركة الريم - Al Reem Trading LLC, Office 1204" and see where the dash and the number end up.

3. Search that ignores how people type Arabic. People type أ, إ and آ interchangeably, ة and ه at the end of words, ى and ي, with or without diacritics and tatweel. A search for "احمد" should find "أحمد". If the app does a plain text match, half your customers can't be found. Ask for normalised search and test it.

4. Numbers and dates. Some users expect Eastern Arabic numerals (١٢٣), most Gulf business software shows Western ones (123), and either way they must sort and calculate correctly. In Saudi Arabia many forms still need the Hijri date next to the Gregorian one. Decide which you want and tell the tool, or you'll get whatever the model guessed.

5. Fonts. The default system font for Arabic on many devices is fine for reading and poor for a branded app. Good open fonts exist (IBM Plex Sans Arabic, Noto Kufi Arabic, Tajawal, Cairo); ask for one and check that bold weights and numbers render well.

6. Local business rules. VAT is 5% in the UAE and 15% in Saudi Arabia, invoices in Saudi Arabia have to meet ZATCA's e-invoicing rules, phone numbers come as +971 and +966 with different lengths, and customers expect a WhatsApp button, not just a contact form. A general model knows these facts when asked. It won't apply them unless you tell it to.

7. Where the data lives. The UAE and Saudi Arabia both have personal data protection laws. If you're storing patient or customer records, know which region your database runs in and who can see it. This is a question for your hosting choice more than for the chatbot.

The test: one prompt, three tools

Give each tool the same small, realistic app. Here's the prompt I use. It's short enough for a free tier and covers most of the list above:

Build a bilingual (Arabic and English) appointment booking page for a dental clinic in Riyadh. Default language Arabic, full right-to-left layout with a language switch. Patients choose a service, a dentist and a time slot, and enter their name and a Saudi mobile number (+966). Show prices in SAR including 15% VAT. Show the appointment date in both Gregorian and Hijri. Staff see a list of today's bookings, searchable by patient name in Arabic or English, where a search for احمد also finds أحمد.

Then check, in this order:

Does it run? Can you click through a booking in the preview?
Is the RTL real? Mirrored layout, correct arrows, numbers and prices not reversed.
Mixed input. Enter a name like "محمد Al-Harbi" and a phone number with spaces. Does it save and display correctly?
Search. Try the أ/ا case, and a name with ة.
VAT and dates. Is the VAT maths right, and is the Hijri date there and plausible?
Where did the booking go? Close the preview and come back. If the booking is gone, the "app" kept data in the browser. That's a demo, not an app.
Can staff log in? A booking list anyone with the link can read is a privacy problem for a clinic.

Steps 1 to 5 test the model. Steps 6 and 7 test the tool around it, and that's where the three differ most.

What to expect from each

Claude. Artifacts open next to the chat and can be shared by link, so you'll see the booking page quickly and can send it to a colleague in Arabic. Artifacts can keep some persistent data on paid plans, which helps for a small internal tool. For a clinic's real booking system with patient data and staff logins you'd move to Claude Code and choose your own hosting and database.

ChatGPT. The chat can preview supported code such as HTML and React components, which is enough to judge the layout and the Arabic. To get a real app, Codex can build it in a project, and then you decide where it's hosted and where the database lives.

Gemini (AI Studio Build mode). This is the closest of the three to a full app out of the box: it can provision Firestore, add Firebase sign-in and deploy to Cloud Run. Check which Google Cloud region it deploys to if data location matters to you, and expect Cloud Run and paid model usage to add costs.

The honest summary: for the Arabic itself, the gap between the three is smaller than the gap between "a preview" and "an app with a database, logins and a domain". Pick the model whose output you like, then decide how you'll get it online.

Building it as a real app with Mythex

Disclosure: I work on Mythex, an AI app builder, so take this section as one option rather than a verdict.

Mythex is aimed at the step-6-and-7 problem. You describe the app in chat, in Arabic or English, and its agent writes the code, runs it in a cloud sandbox with a live preview, attaches a Postgres database and file storage, and publishes it to a public address or your own domain. It builds fully in Arabic, including right-to-left layouts.

The same dental clinic prompt works as a first message. Then I'd follow up with the parts that usually need a second pass:

Make Arabic the default for patients and English the default for staff, each with a switch. Store every patient name in two fields, Arabic and English, and search both with Arabic normalisation (أ إ آ → ا, ة → ه, ى → ي, ignore diacritics).

Add a staff login. Only signed-in staff can see bookings. Add a daily view per dentist and a button to send the patient a WhatsApp reminder with the appointment time.

You can click on any element in the preview to change it, which is quicker than describing a misaligned Arabic label in words.

When it's ready, publishing gives it a live address, and on Pro you can put it on the clinic's own domain.

Honest limits. Mythex builds web apps, which work on phones in the browser but aren't App Store apps. Login providers, email and payments use your own accounts and keys, which the agent wires in for you but which you still have to set up. And like any AI-built app, you should test the VAT maths, the date handling and the search yourself before patients rely on it.

If you'd rather stay in Claude or Codex, Mythex also runs a remote MCP server, so those tools can build and publish in a Mythex sandbox.

For teams

If more than one person will build or use these apps (a clinic group with several branches, an agency building for Gulf clients), the team setup matters as much as the model:

A shared workspace with roles, so the operations manager can edit and the front desk can only use the app.
Members-only apps, so the bookings list opens only for colleagues who are signed in.
SSO on your company domain, so staff sign in with their work accounts and leavers lose access when IT removes them.

On Mythex these are on the Business plan; see pricing for the current plans.

A checklist to keep

Same prompt in each tool, with real Arabic and mixed data.
RTL mirrored properly; numbers, prices and phone numbers not reversed.
Arabic search normalised (أ/ا, ة/ه, ى/ي, diacritics).
Dates and numerals decided on purpose; Hijri where Saudi forms need it.
VAT, currency and phone formats for your country.
Data kept on a server, not in the browser, and you know which region.
Staff logins and members-only access before any real customer data goes in.

Run that list on all three this week. It takes an afternoon, and you'll learn more from it than from any benchmark.

Scaffold inventory management: why tube and fittings go missing, and how to track them job by job

Mythex — Sun, 25 Oct 2026 05:20:58 +0000

Ask the owner of a small scaffolding company how much tube they own and you'll usually get a confident number. Ask how much of it is in the yard today, how much is on which site, and how much has quietly disappeared since spring, and the answer turns into "we'd have to count."

That gap is the whole problem. Scaffolding is a rental business disguised as a construction trade. You buy tube, fittings, boards and frames once, and they earn money every week they're standing on someone's building. Every piece that doesn't come back from a strike, sits forgotten on a finished job, or gets bent and stays in the "good" pile is money leaking out, slowly enough that nobody notices until a big job needs more material than you actually have.

This article covers how that leak happens and what a scaffold inventory system needs to stop it. Near the end I'll build one with Mythex, the AI app builder I work on, but most of it applies to any tool, including a well-built spreadsheet.

Why scaffold stock is harder to track than normal inventory

Most inventory software assumes stock comes in, sits on a shelf, and goes out once to a customer. Scaffold material doesn't behave like that.

It leaves and comes back. The same 21-foot tube might go out to three jobs in a month. You don't care that you "sold" it; you care where it is right now and whether it came back.

It's counted in different units. Tube by length, fittings by type (right-angle couplers, swivels, sleeves, base plates), boards by length, frames and braces by size for system scaffold. "200 fittings" is meaningless if the job needs 80 swivels and you have 15.

Some of it isn't yours. When a job outgrows your stock, you hire material in from another firm. That material has to be tracked separately and returned on time, or you pay for weeks you didn't need.

It gets damaged. Bent tube, cracked boards and worn couplers must come out of use. If damaged items stay counted as available stock, your numbers are wrong and your crews end up sorting through bad material in the yard.

The records are made in the worst conditions. Loading a truck at 6am, in the rain, with a gang waiting. The system has to be faster than the delivery note, or it won't get used.

Where the material actually goes

When small firms finally do a full count, the missing stock usually comes from a few predictable places:

Strikes that aren't counted. The erect gets a delivery note. The strike gets loaded onto the truck in a hurry, and nobody counts what came back. Short returns are invisible.
Leftovers on finished sites. A few boards and a bag of fittings stay behind "for the roofer," and nobody goes back for them.
Transfers between sites. A gang moves material straight from one job to the next without it going through the yard. Both sites' records are now wrong.
Damaged items that stay in circulation. Nobody logs the bent tube, so the system thinks it's available.
Hired-in material that gets mixed with yours. It looks the same. Either you return your own by mistake or you keep theirs and pay the hire.

What a scaffold inventory system has to do

If you're choosing software or building your own, these are the requirements that matter. Everything else is nice to have.

1. Stock by item and by location. Every item type has a quantity in the yard and a quantity on each active site. The total is the sum, not a separate number someone types in.

2. Movements, not just balances. Every delivery, return, transfer and write-off is a row: date, item, quantity, from, to, who recorded it. The balances are calculated from those rows. This is the single most important design decision. If people edit balances directly, you lose the history and can't find where things went.

3. Out versus back, per job. For each site you should see what went out on the erect (and any extra deliveries), what came back on the strike, and the difference. That difference report is where the leak shows up, and it's the report most owners have never seen.

4. Damaged and condemned stock. A simple "write off" or "quarantine" movement that takes items out of available stock, with a reason. Over time this tells you which items and which sites wear material fastest.

5. Hired-in material kept separate. Its own items or a flag on each movement, with the supplier and the due-back date, and a list of everything currently hired in.

6. Phone-first counting. A delivery or return screen a gang leader can complete standing next to the truck: pick the site, tap the items, enter the quantities. If it takes longer than two minutes, it'll be done "later," which means never.

7. Hire periods (if you invoice by time). Many firms charge a base period and then weekly hire after that. If the system knows when each scaffold went up and came down, it can list overruns that haven't been invoiced. That list often pays for the whole system.

8. Inspections alongside the stock. In the US, OSHA requires scaffolds to be inspected by a competent person before each work shift and after anything that could affect their integrity. Canada's provinces have similar rules. Inspections are a separate record from inventory, but they live naturally on the same site records, and a firm that already uses an app for deliveries can log inspections in the same place.

Off the shelf, spreadsheet, or custom

There are three realistic routes for a company with 5 to 50 people.

Rental or construction inventory software. Equipment rental platforms handle out-and-back tracking. Check that they cope with scaffold units and site-to-site transfers without workarounds by running one real job through a trial, erect to strike.

A spreadsheet done properly. One sheet of movements, balances calculated by formula, never typed. It breaks down when several people record from phones at once and when you want per-job reports without building them by hand.

A small custom app. This used to mean months of a developer. Now an AI app builder can make a working version from a written description, with a database, logins and a phone screen, shaped around how your yard already works.

Building it with Mythex

Here's how I'd build it in Mythex. You describe the app in chat, and Mythex writes the code, runs it with a live preview, and attaches a Postgres database. These are the prompts I'd type, in order.

First, the core:

Build an inventory app for a scaffolding company. Items have a name, category (tube, fittings, boards, system frames, other), unit, size or length, and a reorder level. Locations are the yard plus job sites; each site has an address, client, status (planned, erected, struck) and the erect and strike dates. Record every stock movement as a row with date, item, quantity, from location, to location, type (delivery, return, transfer, write-off) and the user who recorded it. Calculate the stock at each location from the movements; never store balances directly. Add user login.

Then the per-job leak report:

On each site's page, show a table per item: total sent to the site, total returned, written off on site, and the difference still on site. Add a "struck sites with material missing" report that lists every struck site where the difference isn't zero, with the quantities.

Then damaged and hired-in stock:

Add a write-off movement with a reason (bent, cracked, worn, lost) that takes items out of available stock. Add hired-in material: a supplier, a due-back date, and a flag on movements so hired items are tracked separately from our own. Show a list of hired-in items still out, sorted by due-back date.

Then the screen your gangs will use:

Add a phone screen for the truck: choose the site, choose delivery or return, then a list of items with big plus and minus buttons for quantities, and one Save button. Show the last five movements for that site underneath so the gang leader can check what they just entered.

Open the database tables while you build to check that movements are stored as rows. Then enter a real job from last month, erect to strike, and see whether the leak report matches what you suspect went missing.

Before handing it to the yard, try the phone screen on an actual phone: can a gang leader record a return in under two minutes without help?

What you end up with

One list of every item, with quantities in the yard and on each site, calculated from movements.
A per-site out-versus-back table, and a report of struck sites with material still missing.
Write-offs with reasons, so damaged material leaves available stock and you can see where it's being damaged.
Hired-in material tracked separately with due-back dates.
A phone screen for deliveries and returns, with logins so every movement has a name on it.
A public link straight away, and your own domain (for example yard.yourcompany.com) on a paid plan.

Honest limits

It only knows what people record. No app finds tube that was never logged. The phone screen has to be faster than the paper habit, and someone has to own the rule that every strike gets counted.
Barcodes and RFID are a bigger project. Tagging individual tubes is possible but rarely worth it for a small firm; counting by item type and quantity per movement gets you most of the value.
Accounting stays in your accounting tool. The app lists overruns to invoice; the invoice still goes through QuickBooks or Xero unless you build that link.
Clean the item list first. Five names for the same coupler means messy reports.
Test before you trust it. Run a real month in parallel with your current method before relying on it for a big job.

For teams

Once more than one person records movements, build the app in a shared team workspace rather than one person's account, so it doesn't depend on a single login when someone leaves. On Mythex's Business plan (from $50/month), the workspace has Admin, Editor and Viewer roles, per-member credit limits, and members-only apps that only signed-in colleagues can open, which suits an internal yard app. Sign-in through your company's Google Workspace or another identity provider is available once your domain is verified, and people with your company email can join automatically. Current plans and prices are on the pricing page.

If you run a scaffolding company and your yard works differently (system scaffold only, a second depot, material cross-hired between your own branches), describe it in the comments and I'll say how I'd model it.

How to build a meal plan subscription website for a Gulf meal prep kitchen, step by step

Mythex — Sat, 24 Oct 2026 06:15:09 +0000

Meal plan kitchens in Dubai, Abu Dhabi, Riyadh and Jeddah tend to run the same way in their first year. Customers find you on Instagram, message you on WhatsApp, pick a plan from a PDF, pay by bank transfer or a payment link, and then the real work starts: someone types every order into a spreadsheet, tracks who paused which days, works out tomorrow's counts for the kitchen, and splits deliveries by area for the drivers.

It works at 30 subscribers. At 150 it starts to break. People pause by voice note, a customer's allergy gets lost in a long chat, the kitchen prepares meals for someone who cancelled, and nobody can say how many active subscribers you have without an afternoon in the spreadsheet.

This article walks through building a proper meal plan website for that kind of business: plans, a customer account where subscribers pause and swap meals, a kitchen view, and delivery lists by area. I'll show it with Mythex, the AI app builder I work on, using the actual prompts, but the structure applies whatever tool you use.

What the website actually has to do

Before building anything, it helps to separate the four jobs, because most off-the-shelf "restaurant website" tools only do the first one.

1. Sell plans. A public site in Arabic and English with your plans (for example weight loss, muscle gain, balanced, keto), what's in each, meals per day, days per week, and price per week or month. Customers choose, enter their address and delivery slot, and start a subscription.

2. Let subscribers manage themselves. This is the part that removes most of the WhatsApp traffic. A logged-in customer should be able to pause specific days (travel, Eid, a weekend away), swap a meal for another one on the menu, update an allergy, change their address, and see their remaining days.

3. Tell the kitchen what to cook. Every evening the kitchen needs one number per dish for tomorrow, adjusted for pauses, swaps and allergies, plus labels with the customer's name and any exclusions.

4. Tell drivers where to go. A delivery list for tomorrow grouped by area (Dubai Marina, JLT, Al Barsha; or Al Malqa, Al Yasmin, Hittin in Riyadh) and by slot, with phone numbers and building notes.

If a tool can't do 2, 3 and 4, you'll still be in the spreadsheet every night, whatever the website looks like.

Step 1: describe the data first

Start with the records, not the pages. In Mythex you describe the app in chat, and it creates the database tables, the pages and the logic together. My first prompt for a kitchen like this:

Build a meal plan subscription website for a healthy meal prep kitchen in Dubai. Tables: plans (name in English and Arabic, description, meals per day, days per week, price per week in AED), dishes (name EN/AR, calories, protein, carbs, fat, allergens), weekly menus (which dishes are offered on which date), customers (name, phone, email, area, building, delivery slot, allergies, notes), subscriptions (customer, plan, start date, end date, status), pauses (subscription, date), and meal choices (subscription, date, dish). Areas are a fixed list I can edit. The site must work fully in Arabic and English with a language switch.

That one message gives you a working app with a real database behind it, not a mock-up. You can open the tables and check the columns before going further.

Two things worth getting right at this stage. First, store pauses as individual dates rather than "paused from X to Y". It makes the kitchen counts and the "remaining days" calculation much simpler. Second, keep allergies as a list of fixed allergens (nuts, dairy, gluten, shellfish, egg, sesame) plus a free-text note. A dropdown list can be checked against dishes automatically; a sentence in a chat can't.

Step 2: the public site and sign-up

Create the public homepage: a hero with our tagline, the plans as cards with price per week and meals per day, a "how it works" section (choose a plan, choose your start date, we deliver daily between 6 and 9 am), this week's menu with calories and macros for each dish, delivery areas, and FAQs. Arabic and English, right-to-left layout in Arabic. A "Start my plan" button opens a sign-up form: name, phone with country code, email, area, building and flat, delivery slot, allergies, and start date (not earlier than two days from today).

The two-day rule matters more than it looks. Most kitchens buy ingredients a day or two ahead, so a subscription that starts tomorrow morning is a problem. Put your real cut-off in the rule.

On payment: the build above records the subscription and its status. Charging a card is a separate step, where you connect a payment provider with your own merchant account (Stripe, or a regional gateway that supports your country). Many kitchens start by keeping their existing payment link and marking subscriptions as paid by hand, then add online payment once the rest works.

Step 3: the subscriber account

This is the page that saves your team the most time.

Add a customer account. Customers sign in with their email. They see their plan, start and end date, and a calendar of their delivery days. They can pause any day up to 8 pm the evening before, and paused days extend the end date. For each upcoming day they can swap any dish for another dish on that day's menu, but the app hides dishes that contain one of their allergens. They can update their address and delivery slot, effective from the day after tomorrow.

The rules in that prompt (8 pm cut-off, paused days extend the plan, swaps hidden by allergen) are the ones you'd otherwise enforce by hand in WhatsApp. Write your own rules; the point is that the app applies them the same way every time.

Test it on a phone. Almost all of your customers will use it from one, and most of them in Arabic.

Step 4: the kitchen and delivery views

Add a staff area that only signed-in staff can open. Kitchen page: pick a date (default tomorrow) and show the count of each dish, after pauses and swaps, plus a list of portions with allergy exclusions. Add a "print labels" view with one label per meal: customer name, dish, calories, allergens to exclude, and delivery date. Delivery page: tomorrow's deliveries grouped by area and then by slot, with customer name, phone, building, flat and notes, and a button to export the list for each driver.

Run it against a real day. Take yesterday's spreadsheet, enter the same customers, pauses and swaps, and compare the counts the app gives with what your kitchen actually cooked. If they don't match, the difference is usually a rule nobody had written down (a customer who always gets an extra portion, an area you don't deliver to on Fridays). Add it to the app now.

Step 5: Ramadan, holidays and the other Gulf specifics

Gulf meal plan businesses have a calendar that generic tools don't know about.

During Ramadan dates I set, replace the morning delivery slot with two options: before iftar (4 to 6 pm) and suhoor (10 pm to midnight). Customers choose once for the whole month and can change it with one day's notice. Let me mark public holidays as "no delivery" days, which automatically extend everyone's plan by one day.

Also check VAT on your prices (5% in the UAE, 15% in Saudi Arabia) and whether your plan prices are shown inclusive of it, which is what customers expect. And keep the Arabic copy written by someone who speaks it natively. The builder lays out right-to-left pages correctly, but your menu descriptions should still read like your brand, not like a translation.

Step 6: publish on your own domain

When it works, publish it. You get a public address straight away, and on a paid plan you can connect your own domain, such as order.yourkitchen.ae or yourkitchen.sa, with the staff area staying behind sign-in.

Honest limits

Payments and refunds are yours to set up. The app tracks subscriptions; card payments, failed payments and refunds go through a payment provider account you open and connect.
Delivery routing is basic. Grouping by area and slot is enough for a few drivers. Optimised routes across dozens of drivers is a job for a dedicated delivery platform, which you can feed with the exported list.
Nutrition numbers are as good as your recipes. The app adds up whatever calories and macros you enter per dish. It doesn't calculate them from ingredients unless you build that too.
Someone has to own the rules. Cut-off times, pause limits and refund policy are business decisions. The app enforces them consistently, but it can't decide them for you.

For teams

Once there's an operations person, a kitchen lead and a customer service agent, build it in a shared team workspace rather than the founder's personal account, so the app doesn't depend on one login. On Mythex's Business plan (from $50/month), the workspace has Admin, Editor and Viewer roles, per-member credit limits and usage by person, and members-only apps that only signed-in colleagues can open, which suits the kitchen and delivery pages. Sign-in through your company's Google Workspace or another identity provider is available once your domain is verified. Current prices are on the pricing page.

If you run a meal plan kitchen and your setup has a rule I didn't cover (corporate plans billed to a company, family plans with different meals per person, gym partnerships), describe it in the comments and I'll suggest how I'd model it. And if you want to start from a first version for a meal prep business, this page shows what Mythex builds from a single description.