An admin panel for your records.
The screen for the things that should never have been edited in a shared file: customers, jobs, rates, stock, whatever your operation actually turns on
one place the record lives, with a history of who touched it
Internal tools development · UAE
Nobody sets out to buy one. It starts as one person’s sheet, becomes the thing the operation runs on, and the day it breaks is the day everybody finds out.
Show us the sheetWhat an internal tool is
Three habits go into one screen: the shared sheet, the approval chased by message, and the record typed twice. What changes is not tidiness, it is that the work now leaves a trail.
The records, the approvals and the history in one place, on screens shaped around the job rather than around a database. The measure is not how it looks, it is whether somebody in the middle of the work opens it instead of the sheet.
Nobody marks the day a convenience turns into infrastructure. Four things say it already has: other people depend on it, there is no record of who changed what, exactly one person understands it, and something you have to file is built from its output.
Built in weeks rather than quarters, and yours afterwards. The cost does not climb every time the team grows, which is the arithmetic that decides this question once an ops team passes about a dozen people who all need a login.
What gets built
Six different artefacts, not six versions of a dashboard. Which one you need is decided by where the work sits today.
The screen for the things that should never have been edited in a shared file: customers, jobs, rates, stock, whatever your operation actually turns on
one place the record lives, with a history of who touched it
The three or four numbers your team checks every morning, read from the records rather than rebuilt by hand each week
a number nobody has to prepare, which is what stops it quietly going out of date
A list somebody clears in the morning, with the amount, the requester and the reason on the row, and the decision written down
a trail, which is the part a message thread never had
A form that knows what a UAE record contains: a TRN validated as fifteen digits, amounts in AED, the tax treatment on the line, the branch or emirate it belongs to
fewer corrections, because the form refused the wrong thing
Not a platform. One screen that does the thing four people do forty times a week, built in days because it is genuinely small
the least impressive item on this page and often the most used
The panel pulling what it needs from the systems already paid for and writing back where it should, scoped to that
one fewer window open. Wiring two systems to each other without a screen is a different job
Three ways this gets solved
All three are legitimate and two of them cost less than we do. What separates them is what happens as the team and the fields grow.
| Keep the sheetWhat the team already knows | Buy the seatRetool and its tier, priced per person | Have it builtA panel shaped around the work | |
|---|---|---|---|
| Fit to how you work | Perfect, because it grew there. That is also why nobody else can use it. | Close, within what the builder can express. Good enough surprisingly often. | Exact, including the parts of your process nobody would design on purpose. |
| Who can change it | Anyone, which is the problem. One cell and a formula is gone. | Someone technical on your side, if you keep one and they stay. | Us, or your own developer. The change is a release, not an edit. |
| As the team grows | Unchanged, until the file itself becomes the bottleneck. | Every new person is another seat, every year, for as long as you use it. | The same, whether eight people use it or eighty. |
| Your actual fields | Whatever you type. Nothing is validated and nothing is searchable. | Standard field types. A validated TRN or Arabic search is work either way. | Built to the record: the identifier, the currency, both scripts, the branch. |
| When it is right | Genuinely one person’s working file, that nobody else depends on. | A small team, data already in one place, and somebody technical in-house. | Once it is load-bearing: others depend on it and something filed comes out. |
Buy the seat, more often than a firm like ours is supposed to say. If your data already sits in one database and you have somebody technical who is staying, the low-code tier gets you a working panel this month for a fraction of a build, and we will tell you so. Two things change that: the seat count, because the arithmetic turns around a dozen logins and keeps turning, and the fields, because a validated identifier and both scripts are work wherever you do them. If the step should not need a screen at all, that is a different route.
The UAE context
Webzenia has worked with Gulf clients since 2018. Four things about the tool a team actually works in, and none of them is the interface.
It began as one person’s working file and became the thing everybody depends on, without a decision being taken. A Business Bay brokerage on a DET mainland licence often has one person who understands the commission sheet, knows it, and cannot take leave in the week it is run.
A supplier name entered in Arabic has to sort sensibly, be found by somebody searching in either script, and survive an export. Translating the buttons does none of that. An Al Quoz F&B producer on a mainland licence takes delivery notes and invoices in both scripts into the same tray.
A form with a generic tax field accepts anything and corrects nothing, which turns into a reconciliation later. A JLT trading group under DMCC running a free zone entity beside a mainland service company needs the branch on the record before anybody can report by it.
Wages here are paid through the Wage Protection System as a structured file on a fixed monthly deadline, so any tool touching people and pay is producing an input to a filed obligation rather than an internal transfer. A Dubai Marina clinic on a mainland licence discovers that the first month somebody is on leave.
What the engagement covers
Six stages, and the last one is the only test that counts. A tool nobody opens has failed, however well it was built.
An hour beside the person who runs the sheet, because what they actually do and what the process document says are two different things
the real sequence, including the workarounds nobody would admit to in a meeting
The three or four screens drawn and agreed with the people who will live in them, in both scripts where the work is bilingual
an argument had at the drawing stage, which is where it is worth having
The panel itself, with the identifier, the currency and the branch checked at entry rather than reconciled at the month end
something in use inside weeks rather than a phase-one of four
The accounting package, the CRM, the storage everybody already pays for, read from and written to where that is what the panel needs
one window rather than four, and no second copy of the truth
The team moved across with the data, and the spreadsheet made read-only on a named date rather than left open beside the new thing
one system in use, which is the only version of this that works
The first month is when the real requirements appear, because people only find the missing field by working in it
a queue of small changes handled, and the source in your own repository
Our stack
Five options in order of size, and the first two cost less than building. Select one to see when it is the right answer and where it stops.
For a lot of internal tools it is simply the right answer, and it is first on this list because a supplier who will not say that is not giving you an assessment.
We build in it when it fits and out of it when it does not, and the test is the seat count and the fields. Where you are already paying for seats we will often improve what you have rather than replace it.
How the build runs
The last phase is the one that decides whether any of it worked. A tool running beside the spreadsheet it replaced has not replaced it.
We sit with whoever actually maintains the sheet, because the process document and the process are rarely the same thing, and the workarounds are where the requirements live. Then three or four screens are drawn and signed off by the people who will work in them, in both scripts where the work is bilingual. Arguing about a drawing is far easier than arguing about a build.
The screens are built with the fields validated at entry rather than reconciled later, and the existing records are moved across rather than left behind, because a tool with no history is a tool people keep the old file open beside. Where the panel needs to read from or write to something you already pay for, that is wired here. Nothing goes live on a Thursday.
The spreadsheet is made read-only on a date everybody knows, because two systems running in parallel means the old one wins and the new one gets blamed. The first month afterwards is when the real requirements arrive, since people only find the missing field by working in it, so a queue of small changes is part of the engagement rather than a surprise. Then the source sits in your repository.
The old sheet closed on a named date, because running both is how a good tool quietly fails.
Our commitment
An internal tool does not fail at the code, it fails by not being opened. These four are written into the engagement for that reason.
The old sheet gets a closing date.
Not a launch, not a demo: the spreadsheet made read-only on a date everybody knows. Two systems running side by side means the familiar one wins, and the new one gets the blame for a problem it did not cause.
The source code is yours.
From the first commit rather than at the end, so your own developer or the next supplier can pick it up. An internal tool nobody outside one firm can open has recreated the problem it was built to solve.
Hiring more people costs nothing extra.
A built tool has no seat count, so hiring six people in operations does not change what the tool costs. That arithmetic is most of the reason this question comes up, and it should be checked against a real headcount rather than assumed.
Your data sits where you need it.
On infrastructure in your own accounts, in a region chosen rather than defaulted to, with the fields that feed a filing marked and their edit rights written down. Where a wider regime question applies, we raise it before the build.
Common questions
Keep exploring
What your licence and data regime allow, ranked and costed.
Built where your own data beats a hosted model.
Answers from your documents, in the Arabic customers write.
Agents that answer your published line, in Arabic and English.
Outbound calling built inside the telemarketing rules.
Threads that finish in writing, in Arabic and English.
Rewrite the process for this market, then automate it.
Wire the two systems either side of the hand-off.
A CRM that knows which of your companies is selling.
Next step
Tell us what the team runs the operation on today. We will name the one tool worth building first, and the one that is not worth touching yet.
Tell us what you need.