Internal tools development · UAE

Internal tools that replace your team's spreadsheet.

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 sheet

What an internal tool is

What internal tools development replaces.

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.

Ops consoleOps ManagerOrdersInventoryApprovalsUsersAudit84orders today6pendingsyncedORDERAMOUNTSTATUS#1284AED 1,499Paid#1283AED 890PendingApprove#1282AED 2,400FlaggedSynced · Network International · Xero · WhatsAppReplaces the spreadsheet and the WhatsApp ops thread

Three habits become one screen.

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.

When it becomes load-bearing.

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.

Owned, with no fee per person.

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 tools, and the sheet each retires.

Six different artefacts, not six versions of a dashboard. Which one you need is decided by where the work sits today.

Admin panelsadminsearch users+ NewnamerolestatusLayla HaddadAdminActiveEditOmar FaroukEditorActiveEditSara MansourViewerInvitedEditYusuf KEditorActiveEditthe admin screen your team logs into daily

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

Output

one place the record lives, with a history of who touched it

One sourceHistory kept
Ops dashboardsliveAPIokPaymentsokQueueokJobswarnRequests / min1 job retryingyou see it going wrong before customers do

An ops dashboard from your records.

The three or four numbers your team checks every morning, read from the records rather than rebuilt by hand each week

Output

a number nobody has to prepare, which is what stops it quietly going out of date

From the recordNot prepared
Approval workflows3 pendingWaiting on youLeave requestLayla, 3 daysApproveRejectExpense AED 840Omar, Al Quoz siteApproveRejectDiscount 12%Sara, deal #482ApproveRejectapprovals in one place, cleared in seconds

An approval queue somebody clears.

A list somebody clears in the morning, with the amount, the requester and the reason on the row, and the decision written down

Output

a trail, which is the part a message thread never had

Worked, not chasedTrail
Data-entry & back-officevalidatedStructured entry, validated on the way inVendorSunrise Trading LLCTRN100 4567 8901 2345AmountAED 4,200Save entryclean data in, no more messy spreadsheets

Data entry with UAE fields.

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

Output

fewer corrections, because the form refused the wrong thing

TRN validatedAEDBy branch
Internal CRUD toolsCRUD+ NewEditDelete128 recordsSKU-1042 · Steel boltin stockSKU-1043 · Hex nuteditingSKU-1044 · Washerin stockSKU-1045 · Bracketin stockcreate, edit and manage records without engineering

A small tool for one team.

Not a platform. One screen that does the thing four people do forty times a week, built in days because it is genuinely small

Output

the least impressive item on this page and often the most used

Small on purposeDays
Integrations hubconnectedThe tools you already use, switched onSSlackconnectedGGoogle SheetsconnectedNNetwork InternationalconnectedZZapieroffflip on the tools you already run on

Reading and writing your systems.

The panel pulling what it needs from the systems already paid for and writing back where it should, scoped to that

Output

one fewer window open. Wiring two systems to each other without a screen is a different job

ScopedBoth ways

Three ways this gets solved

Keep it, buy it, or build it.

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 knowsBuy the seatRetool and its tier, priced per personHave it builtA panel shaped around the work
Fit to how you workPerfect, 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 itAnyone, 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 growsUnchanged, 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 fieldsWhatever 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 rightGenuinely 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.
Which one we would do.

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

What an ops panel here must get right.

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.

  1. 01of 04
    Nobody bought itIt arrived, and then it mattered

    The software your operation runs on was never bought.

    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.

    Our methodThe load-bearing sheet named and its dependencies listed before anything is built.
  2. 02of 04
    Arabic goes in the fieldNot on the label

    Staff type Arabic in, so it has to be searchable.

    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.

    Our methodCapture, sort, search and export tested in both scripts, not the labels alone.
  3. 03of 04
    The fields are localAnd a generic form will not hold them

    UAE records carry a fifteen-digit TRN and a branch.

    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.

    Our methodThe identifier validated at entry rather than checked at the month end.
  4. 04of 04
    Something gets filedOn a date nobody here chose

    Once it feeds a filing, the fields are fixed.

    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.

    Our methodEvery field feeding a filing marked, with who may change it and when it locks.

What the engagement covers

Inside the work, ending with an empty spreadsheet.

Six stages, and the last one is the only test that counts. A tool nobody opens has failed, however well it was built.

DiscoveryscopedThe sprawl today, mapped5 spreadsheetsDouble data entryNo audit trailOne tool, one source of truthwe map the mess before we build the fix

Watching the work being done.

An hour beside the person who runs the sheet, because what they actually do and what the process document says are two different things

Output

the real sequence, including the workarounds nobody would admit to in a meeting

ObservedWorkarounds included
DesignwireframeWireframed before a line of codewe agree the layout on paper, cheap to change

Screens signed off first.

The three or four screens drawn and agreed with the people who will live in them, in both scripts where the work is bilingual

Output

an argument had at the drawing stage, which is where it is worth having

Signed offBoth scripts
BuildshippingBuilt in short, usable slicesRecords CRUDdoneFilters & searchdoneBulk actions60%Exports20%shipped in slices, usable from week one

The build, with fields validated.

The panel itself, with the identifier, the currency and the branch checked at entry rather than reconciled at the month end

Output

something in use inside weeks rather than a phase-one of four

Validated at entryWeeks
IntegrateconnectedPlugged into the data you already haveGoogle Sheetsread + writePostgres DBprimary storeSlacknotificationsEmailalertsreads and writes the systems you already use

Wired to your existing systems.

The accounting package, the CRM, the storage everybody already pays for, read from and written to where that is what the panel needs

Output

one window rather than four, and no second copy of the truth

Existing systemsNo second copy
Roll-outadoptedRolled out, actually usedDaily active84%Onboarded48/57Rollout progressthe team switched over, and stayed

Roll-out, and closing the old sheet.

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

Output

one system in use, which is the only version of this that works

Named dateSheet closed
SupportmaintainedKept working, kept improvingOpen2Resolved46Avg reply3hNew fields on requestWeekly improvement shipBug fixes within a daysmall fixes and new fields, every week

Support, and the changes that follow.

The first month is when the real requirements appear, because people only find the missing field by working in it

Output

a queue of small changes handled, and the source in your own repository

Month oneYours

Our stack

Built with Retool and Next.js.

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.

Retool
Why Retool

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.

How we excel

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.

Fastest to a working panelHolds an unusual fieldBest when
Chosen on the fields and seatsAssessed
A low-code panelSmall teams
Built from scratchLoad-bearing
Whatever we sellNot advice

How the build runs

From the sheet to one screen.

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.

01Weeks 1 to 2Agreed

Watching the person who runs 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.

  • Observednot just described
  • Screenssigned off first
  • Scriptsboth, where the work is
02Weeks 3 to 6Built

Building the panel and moving the history.

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.

  • Fieldsvalidated at entry
  • Historymoved, not abandoned
  • Wiredto what already holds it
03Month 2 onwardIn use

Closing the old sheet.

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.

  • Old sheetread-only, on a date
  • Month onechanges expected
  • Sourcein your repository

The old sheet closed on a named date, because running both is how a good tool quietly fails.

Adoption, not delivery
Signed-off screensHistory movedOne system

Our commitment

Four promises about adoption.

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

Internal tools, answered.

Next step

Find out which tool to build first.

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.

+971
Chat on WhatsApp