Discovery & Scoping
We pressure-test the idea before a line of code exists — domain model, feasibility, the smallest version worth shipping, and what comes after it.
- Domain modelling
- Feasibility review
- MVP definition
- Roadmapping
SAAS PLATFORMS — APPS — BACKEND SYSTEMS
A software product studio established in 2026. We build SaaS platforms, mobile apps and backend systems — and we run two of our own in production: AOMS for enterprises, AccountHouse for households.
00 / POSITION
Plenty of studios show you a portfolio. We show you products we operate. AOMS closes the books for real companies. AccountHouse tracks real households’ money. Every lesson those platforms teach us — about uptime, migrations and offline sync — goes straight into what we build for you.
01 / WHAT WE BUILD
02 / CAPABILITIES
We pressure-test the idea before a line of code exists — domain model, feasibility, the smallest version worth shipping, and what comes after it.
Interfaces engineered like the systems beneath them. Dense operator dashboards, glanceable mobile screens, one design system holding both together.
One team from the database to the phone. The same people own the data model, the interface and the release that ships it — nothing is handed over a wall.
The part most teams get wrong. Relational models that survive change, and ledgers that still balance three years and four migrations later.
Deployment as an engineering discipline. Containers, managed services, pipelines and the telemetry that tells you before your users do.
Tenant isolation, role tiers and per-module permissions enforced server-side. Two-factor, session control and audit trails as defaults, not add-ons.
03 / HOW WE WORK
We start where the value is: your domain. Sessions with the people who do the work, an entity map on the wall, and an honest read on what is actually buildable.
Before code, structure. Schema, service boundaries, roles and permissions, and the failure modes we refuse to ship with — written down before anyone opens an editor.
Shippable increments on a staging environment you can log into from week one. You watch the product grow in a browser, not in a slide deck.
Deployment is engineered, not improvised. Containers on managed cloud, reversible migrations, secrets in a vault, errors reported the moment they happen.
The product meets reality — and we stay. We run our own platforms on this same loop: fix, measure, extend, and answer the phone when something breaks.
04 / ENGINEERING
We don't pick technology by fashion — we pick what we are willing to run ourselves at 2am. Every layer of an IA Systems build is the one already carrying AOMS and AccountHouse in production: chosen for how it behaves in year five, not how it demos in week one.
05 / OUR PRODUCTS
Two platforms and three apps, built and operated by IA Systems. The previews below are the real applications, embedded live from production.
IN PRODUCTION — BETA WITH EARLY CUSTOMERS
A multi-tenant operations platform for small and mid-sized enterprises. Customers, receivables, payables, receipts, cash register, expenses, employees and payroll — all sitting on a real double-entry ledger with journals, chart of accounts, AR aging, reconciliation and VAT. Every tenant gets isolated data, users and books.
It ships in two product profiles from one codebase. AOMS is general business administration, with a public form builder. TOMS is for transport and fleet operators — vehicles, drivers, tolls, parking, fines and per-vehicle income, for route-level profit and loss.
FIG.A — AOMS, EMBEDDED LIVE FROM PRODUCTION
PUBLIC BETA — LIVE IN PRODUCTION
A client-oriented finance platform built for the person tracking their own money, not for an accounting department. Expenses with search, filters and receipt attachments; a parent–child category tree; income sources; per-category budgets with warning thresholds; recurring items; and multi-currency with live exchange rates.
On top of that sits the analytics layer — monthly trends, category breakdown, payment-method splits and top spend — with filterable reports exporting to CSV, Excel and PDF. The web app is one client of the platform; the apps below run on the same backend and the same accounts.
FIG.B — ACCOUNTHOUSE, EMBEDDED LIVE FROM PRODUCTION
05.B / APPS
Real native builds that keep working without a signal — capture now, sync when the connection comes back, with push and biometric security throughout. AH Lite is a product in its own right: its own design language and its own release train.
SEPARATE PRODUCT — ANDROID
A standalone, design-forward companion to AccountHouse — same accounts, a fraction of the weight. Expense capture on a custom amount keypad with tip & tax and receipt photos, glanceable budget rings, categories and wallet cards. An expense entered underground still lands: nothing is lost while the phone is offline. PIN and biometric app lock, and sign-in approvals that work in both directions with the main app on the same phone.
FULL COMPANION APP — v4.2.1
The whole platform on a phone, and then some: AI expense chat, household voice and video calls, receipt scanning, transaction import, expense splits, savings goals, a document vault, shopping lists, cards and banking. Everything keeps working offline and syncs when it can; messages and vault documents are encrypted, with biometric lock and a home-screen widget.
FIELD & ADMIN APPS — ANDROID + iOS
Two apps against the same platform. The admin app puts insights, customers, leads, payments, expenses, salaries, employees and fines on a phone, for managers who are never at a desk. The driver app strips it to what field staff actually need: record a payment, log an expense, attach a receipt — and let the books update themselves back at the office.
06 / PLATFORM SYSTEMS
A product is the part you can see. Underneath AOMS and AccountHouse sit eight distinct services — conversational analytics, receipt capture, an insight engine, learned categorisation, realtime chat and calling, a double-entry posting engine, and the background tier that keeps them all running. Each of these is something we can build for you on its own.
Ask your books a question in plain language.
Ask a question about the money in plain language — “what did we spend on the car this quarter?” — and get an answer assembled from your own records, with the charts that support it. It answers from your data rather than from memory, and it can only ever read what the person asking is entitled to see.
Built for financial data, where a confident wrong answer is worse than no answer: it checks its own work before replying, and when it cannot answer properly it says so instead of inventing something. There is always an answer — never a spinner and an apology.
Photograph a receipt, get a structured expense.
Point a camera at a receipt and get a complete expense back — merchant, date, amounts, tax and category — resolved against the categories, places and payment methods you already use rather than generic guesses. A blurred or half-lit photo is caught while the receipt is still in your hand, and a long receipt is handled in one go.
What comes back is a draft. A person confirms every field before anything is written to the books. That last step is not a UX preference; it is what keeps a scanning mistake from becoming an accounting one.
Findings that survive a second opinion.
Not a model asked what it thinks of your spending. Candidates are proposed — spending spikes, budget pressure, cashflow pressure, category drift, subscription creep — and then every one of them has to earn its place before anybody sees it.
A subscription that charges every month is one finding, not twelve. Near-duplicates that differ only in wording collapse into each other. What survives is ordered by what actually matters and written in plain language — and all of it is computed away from the request, so the product never waits on it.
A model per household, retrained as they type.
"Al Maya", "Nol topup", "DEWA" — these mean something specific to one household and nothing to a general model. So each household gets its own, learned from the way they file things. Familiar descriptions are categorised instantly; only genuinely new ones take the slower, more expensive path, which is why the cost of running it falls the longer an account is used.
It improves as people correct it, and it absorbs renamed or merged categories cleanly instead of quietly keeping the old ones. It will never learn from its own unreviewed guesses — a system trained on its own output only gets more confidently wrong.
Messaging that holds up on a bad connection.
The hard part of chat is not the chat. It is staying live as the platform grows — conversations must not break because the product got busier, and nobody should ever lose a thread because they were served by a different machine.
A message typed on the metro with no signal sends itself when the connection comes back — exactly once, never twice. Message content is encrypted where it is stored, so a stolen database reveals nothing. Where a feature genuinely needs end-to-end secrecy, like the document vault, it is built that way rather than merely claimed.
Calls that can't take the product down with them.
Voice and video built the way it should be: call traffic and the rest of the product never share a path, so a group call cannot slow down or take out the features everyone else is using at the same time.
An incoming call wakes a closed app. Small group calls with per-person mute and camera control, quality that adapts to the connection, and automatic recovery when the network drops — on mobile data, on hotel wifi, in a lift.
The books balance at every instant, not eventually.
This is the part of AOMS that cannot be approximate. An operational action and its accounting entry are recorded together or not at all — take a customer payment and the receipt, the register and the books all move in the same instant. There is no nightly export into a separate accounting package, and no window in which the ledger disagrees with operations.
Posted entries are never edited: a correction is a reversal, so the history stays auditable. Closed periods stay closed. And the books are checked against their own integrity rules continuously — not discovered to be wrong at year end.
The tier that runs when nobody is looking.
Work nobody is waiting for runs on its own tier, separate from the one answering people. Reminders, daily health passes, exchange rates, recurring items and the month-end sweeps all happen on time whether or not anybody is using the product — and they cannot slow down the screens that are in use.
Every scheduled job is safe to attempt twice, so a deploy or a restart delays work rather than skipping it or doing it again. Nobody receives the same notification twice because two machines woke up at once. It is the least visible tier in any platform, and the one that quietly decides whether the product is trustworthy.
END OF SERVICES Every one of these was built for a product of ours before it was ever offered as work. If you need one of them — or something that rhymes with it — that is the conversation to have. START ONE
07 / WHY IA SYSTEMS
Our own platforms are live. Bugs reach us before they reach a client, and migrations are our problem at 2am too. That is a very different incentive to a billed hour.
Double-entry ledgers, VAT, AR aging, reconciliation, multi-tenant isolation, offline sync, push at scale. We have already solved the hard parts once, on our own money.
Backend, web, mobile, cloud and CI in the same room. No handoff tax between the API and the app that consumes it — the same people write both.
Reversible migrations, audit trails, module flags and layered permissions from the start — because switching a module off should never delete a customer's data.
Established 2026. You talk to the engineers writing the code, not an account manager relaying it a week later.
08 / NEW PROJECTS — TAKING BRIEFS FOR Q4 2026
A SaaS product, a mobile app, a backend rebuild, or something that doesn't have a name yet. Tell us what it has to do — we'll come back with the architecture, the team shape, the timeline and the cost.
START A CONVERSATION
It is already in a real inbox. You will hear back within two working days — from the person who would build it, not an autoresponder.