MVP execution plan
Every slice below is something a person can do when it's finished — not a file, a layer, or a ticket. Each one gets a test written first, gets built until the test passes, and gets committed. That's the whole method.
The build mirrors osool, which already runs on your server: same stack, same bilingual machinery, same deploy shape. Qattah inherits its Arabic date handling and its locale switching rather than reinventing either.
Week 1 is four things happening at once, because none of them need each other. After that it narrows into a single line of work.
1,200 riyal across seven people doesn't divide evenly. The leftover halalas have to land somewhere predictable, and the shares must add back up to exactly 1,200 — every time, in the same way.
Eight people and fourteen expenses become three transfers instead of twenty-two. Pure calculation, no database, no screens.
An empty app, deployed properly, on day one. Deploying at the end is how projects get stuck at the end.
Language switching, Hijri dates, riyal formatting — lifted from osool and standing before the first screen exists.
Name it, pick the occasion, get a link to paste into the group chat.
Tap the link, type your first name, you're in. No password, no download, no email. This is the single feature most likely to decide whether Qattah works.
Esteraha, group gift, family trip, kashta, group order, family fund — each opens with the split rule already set the way that occasion is normally handled.
The first moment the whole thing does something useful end to end.
A couple counts as two. Kids count as zero. One guy covers an extra five hundred. Nearly every real split is uneven.
The most important screen in the product. Your share, who you pay, how much, and how to send it. Nothing else on the page.
Bank number, STC Pay, or phone — encrypted, and shown masked to everyone except the people in that tab.
Saying you sent it doesn't clear the debt. Only the person who was owed can close it. The tab archives itself when the last balance hits zero.
Three levels of politeness, never twice within two days, and never naming the person who's owed. The reminders are tested like code, because the wording is the product.
Automated checks that no English leaks into Arabic mode and no Arabic leaks into English — the same tests osool already runs.
Live app on the domain, nightly backups registered, Arabic privacy policy published, security and accessibility passes run before anyone is invited.
The splitting maths was the one part worth doing before anything else, so it's done and run against nine cases — uneven splits, weighted members, excluded children, fixed contributions, and two failure cases that must be rejected. All nine pass. Money is stored in whole halalas rather than decimals, which removes the most common source of rounding errors in apps like this.
Most plans draw arrows between things that merely happen in order. An arrow here means one piece genuinely needs another's output. Everything else runs side by side.
Slice 1 split maths ──┐
├──▶ Slice 5 ──▶ Slice 6 ──┐
Slice 2 settle maths ──┘ ├──▶ Slice 7 ──▶ Slice 9 ──▶ Slice 10
│
Slice 0 deploy the stub ──▶ Slice 3 ──▶ Slice 4 ───────┘ Slice 8 ─────────────┘
Slice 11a Arabic machinery ─── runs alongside everything from week 1 ───▶ Slice 11b
Slice 12 occasions ─── needs only Slice 3
These are the choices that are expensive to reverse later, so they're settled now.
| Decision | Why | |
|---|---|---|
| D1 | Money is stored in whole halalasNever as a decimal number. | Decimal arithmetic on money is the most common bug in split apps — amounts that don't quite add up destroy trust instantly. |
| D2 | Leftover halalas go to the same people every timeIn a fixed, predictable order. | Shares must sum to the exact total, and re-opening the tab must never quietly show different numbers. |
| D3 | Participants are not accountsThey're recognised by their device, from the link. | Requiring signups is the reason group tools die at the invitation stage. |
| D4 | Anyone with the link can join and claim a nameSame trust model as the group chat it was pasted into. | Locking this down properly costs the frictionlessness that makes the product work. The link is the password. |
| D5 | Bank details are encrypted, masked, and never shown before joiningThe preview page shows names only. | Because of D4, a leaked link must expose nothing worse than a tab name and some amounts. |
| D6 | Amounts always use Western digitsEven in Arabic mode. | Learned from osool — Arabic-Indic numerals tested badly for currency there. Not repeating it. |
| D7 | A reminder never names who is owedIt's from Qattah, always. | The moment a nudge says "Faisal is waiting", it recreates the exact tension the product exists to remove. |
Each guard is a specific thing built into a specific slice, not a good intention.
One person maintains the tab, the other seven ignore it, and the balances quietly become fiction.
Guard — joining takes one tap and no account (Slice 4), and there's one screen answering one question.
A rounding error leaves a few halalas unaccounted for and someone notices. Trust doesn't come back.
Guard — already handled. Whole-halala storage and an exactness check in the tests that ship with Slice 1.
The link travels further than intended, and personal financial data is sitting behind it.
Guard — encrypted at rest, masked on screen, invisible before joining, and every reveal is logged (Slice 8).
Right-to-left gets bolted on in week six and half the screens need rebuilding.
Guard — the Arabic machinery is standing in week 1, and every page is checked in both languages as it's built.
Great for eleven days, dead on day twelve. The classic failure mode for this category.
Guard — accepted for the MVP. Weekly circles and the family fund are the fix, and they're first in line after launch.
The exciting features get built before the boring ones work, and nothing ships.
Guard — the cut list below is explicit. Nothing on it gets revisited until fifty real tabs exist.
Both block week 2. Everything in week 1 can start without them.
Email and password is simpler to build. Phone number with a texted code fits Saudi habits better, and Twilio is already set up on this server from an earlier project. My recommendation: phone with a code — it matches how people expect to sign into anything here, and the plumbing already exists.
Building on the subdomain costs nothing and keeps the real domain clean while it's rough. My recommendation: build on qattah.basem.ai, point qattah.com at it when there's something worth showing — switching later is a five-minute change.
All of these are good ideas. None of them is the reason someone opens Qattah the first time, and every one of them makes the first version later.