One platform. Every team ships on it.
Tamz is bought once and shared. The owner runs the platform and sets the rules; everyone else authors services on top — and nothing they author can put the platform at risk.
Government & public platforms
Stand up services on one governed platform, admit other entities to author their own, and push a policy or content change the same day. Every service is reviewable as data before it goes live — so there is no third-party code on anyone’s phone.
Product & enterprise teams
Move onboarding, pricing, campaigns and whole product areas server-side. One source of truth, every device identical, and a fix in production in minutes instead of a release train.
Author, understand, publish — in one place.
Three workspaces over one set of documents: a map of what exists, a builder to change it, and the running app beside them.
See the whole app at once
The Flow Atlas reads your live documents and draws the app back to you — every service, every journey, every screen, the events each one fires, and the order a screen reader will read it in. Nothing is hand-maintained; it is derived from what is actually being served.
- Every service and journey on one board
- Events, parameters and encryption per screen
- Screen-reader reading order, derived not annotated
Edit it, see it, publish it
The builder renders every screen through the real engine — not a preview that drifts — with a drag-and-drop tree, an inspector and full undo. A save is validated before it is written, and the change is live on the next request.
- Rendered by the same engine your users run
- Drag, drop, inspect, undo
- Validated on save — a broken screen never ships
And the app itself, in a browser tab
The third workspace is the product: the same code the iOS and Android apps mount, fetching the same screens from the same server. It is not a mock — there is exactly one renderer in Tamz, and this is it.
- Same engine, same server, same screens
- Demo it without a device in the room
- What you see is what ships
Hold the app. We’ll change it while you watch.
Tamz Market is a real marketplace app — home services, cars, property, classifieds — and every screen in it is a document on our server. Install it, keep it open, and we’ll restructure the home screen from the builder. Refresh. It’s different. No update, no store, no wait.
Install Tamz Market
iOS or Android — or open it in your browser if you’d rather not install anything. Same app, same server, same screens.
DEMO-••••Watch us edit it live
On the call we open the builder, move a section, change a token, add a tile — and save. Every change is validated before it is written.
Refresh, and it’s there
Your app picks it up on the very next request. Then we change it back just as fast.
T Web builder
LIVEWaiting for a published change…
What you get when the UI is data.
Not a faster way to write screens — a different relationship between your product and your release cycle.
Change reaches everyone at once
Publish, and the next request has it. Every device on every OS version sees the same thing at the same moment — and you can put it back just as quickly.
Product owns the product
Flows, copy, rules and content are data. The people responsible for the experience change it directly, instead of describing it to an engineer and waiting for a release.
Safe by construction
The vocabulary is a closed set. A service describes what the UI is and what a tap means — it cannot run a loop, open a socket, read a file, or call anything you did not sanction. That is not a policy. There is nowhere in the format to say it.
A new service is four documents
Catalogue, detail, action, confirmation. The components are built once, so the next service is JSON and a handlers file — days, not a project.
Old apps don’t break
An app older than the screens you serve renders what it understands and skips what it doesn’t. It never refuses a screen — so you are never held back by the slowest device in the estate.
Accessible because the parts are
Entities compose platform controls instead of building their own, so every service inherits the same screen-reader behaviour: controls report their role and state, loading and errors announce themselves, and authors add intent declaratively.
One design system, actually enforced
Colour, type and spacing are tokens resolved at render. Change a token and every screen in every service moves with it — consistency by construction rather than by review.
Four languages, no reload
English, Arabic, Hindi and Urdu ship today, with full right-to-left mirroring. Text is a token, so switching language re-renders in place — nothing refetches, and a half-filled form survives the switch.
Three ways to put it in people’s hands.
One engine, one server, one set of documents. What changes is the shape you ship.
Ship the whole app
One native app for iPhone and Android, phone and tablet, driven end to end by your server. Tamz Market — the demo you can install — is exactly this.
- Every device identical, from one source
- Features and fixes without a store release
- The app ships no screens — it fetches them
Drop it into the app you already have
Add the SDK to an existing native Android or iOS app and hand it one flow — an onboarding, a booking, a whole section — while the rest stays exactly as it is. It mounts as a view: your app keeps its window, its navigation and its release cycle.
- One line of setup, then name the flow you want
- The SDK hands the result back when the flow is done
- Ships as a standard AAR and XCFramework
Author one service on a shared platform
Entities author and own their own services and deliver them alongside everyone else’s. Each one is namespaced, cannot collide with or reach into another, and passes an admission check before it goes live. Running today, with a second company’s service already on the platform — independent per-entity deployment is next on the roadmap.
- Separate author and publisher roles, declared as data
- A rejection comes back as a per-document report
- No third-party code anywhere near the device
The engine is real. The platform is being built.
We publish the roadmap because early partners move it. Here is exactly what runs today, what we are building now, and what it becomes.
- RUNNING TODAY
Everything the demo shows
Not a prototype. Server-driven apps on iOS, Android and the browser, authored in the studio — with another company’s service already live on the same platform.
- Whole apps and embedded flows, from one engine
- The studio: the flow map, the builder, the running app
- Four languages with full right-to-left
- Admission gate, tenancy registry, editor and publisher roles
- IN BUILD
What we’re finishing now
The work between a working engine and a platform you can hand to other entities without watching over them.
- Declared handlers that reach your back-office through mediated connectors
- Versioning and promotion — draft, live, and roll a service back
- Full authentication on the publish and authoring paths
- Arabic and Urdu typefaces, and dynamic text sizing
- NEXT
Where the platform opens up
The point where an entity no longer needs us in the room to build, ship or run its own service.
- Services deployed and operated by the entity that owns them
- Say what you want, and land in the right service
- Screens drafted from the catalogue — never outside it
- THE DESTINATION
A platform you admit others onto
A central owner sets the rules, and every entity authors, publishes, versions and rolls back its own services as reviewable data — as a whole app, or embedded in one they already have. Every phase above is a step of it that already pays for itself.
- One platform, many owners, no third-party code
- Whole app or embedded feature, from the same documents
- Every service reviewable before it reaches anyone
We don’t publish dates. We publish order — and we’ll tell you where your service sits in it.
You’re buying the team as much as the platform.
Software nobody on your side can operate isn’t an asset. The engagement is built so your people are authoring without us by the end of it — and so is the platform.
Start with one real service
We pick a journey that matters, author it with you, and get it running on your platform. A working service beats a workshop — and it is the thing everyone else copies.
Build it alongside your team
Your people author with ours from day one. The goal is that they stop needing us — and the platform makes that realistic, because most of the work is documents, not code.
Hand over a platform you own
The registry, the publish gate, the tokens, the catalogue, the studio. Your teams author, review and publish on their own — and every entity you admit inherits the same floor.
Shape what gets built next
You’re early. The roadmap is ordered, not fixed — and a partner’s first real service is the strongest argument there is for moving something up it.
The people who built the engine build with you.
Small, senior, and the same team through discovery, delivery and handover.
Native at the core
The engine is Kotlin Multiplatform and Compose, rendering natively on iOS and Android from one codebase — built by people who shipped native apps before they built a platform.
Security as an architecture decision
The closed vocabulary, the mediated upstreams, the control plane that keeps nothing between requests — these were design decisions, not features added after a review.
Public-sector delivery
Built against real government and enterprise flows, with procurement, governance and accessibility as constraints from the first day rather than a later phase.
Design systems that hold
Tokens, a component library and a catalogue that cannot drift — the parts of a design system that usually erode within a year.
The things people ask before they book.
Straight answers, including where the honest one is “not yet”.
The engine is. Apps built on it render on iOS, Android and the browser today, and another company’s service is already live on our platform. The platform layer around it — connectors to your back-office, service versioning and rollback, full authentication on the authoring path — is being built now, and the roadmap says exactly where each piece stands.
No. Screens, flows, navigation and theme are documents on your server, and the app fetches them — a change is live on the next request. Only a genuinely new capability, a kind of component that has never existed before, ships with the app itself.
No. The SDK drops into an existing native Android or iOS app and serves one flow — an onboarding, a booking, a whole section — while everything else stays exactly as it is. Your app keeps its window, its navigation and its release cycle, and gets the result back when the flow finishes.
The format itself. A service describes what the UI is and what a tap means, over a closed vocabulary. There is no way to write a loop, open a socket, read a file or call a system you did not sanction — not because a policy forbids it, but because the format has nowhere to say it. Every service is reviewable as data and passes an admission check before it goes live.
English, Arabic, Hindi and Urdu today, with full right-to-left layout. Text is a token rather than a string in a screen, so switching language re-renders in place — nothing refetches, and a half-filled form survives the switch. Adding a language is a column in a file, not a code change.
Entities compose platform controls instead of building their own, so every service inherits the same screen-reader behaviour: controls report their role and state, loading and errors announce themselves, and authors add intent declaratively. We don’t claim a certification or an automated audit, and we’re precise about that — because procurement will ask, and a claim that doesn’t survive the question costs more than it wins.
They degrade rather than break. An app older than the screens it is served renders what it understands and skips what it doesn’t — it never refuses a screen. So you’re never held back by the slowest-updating device in your estate.
Your services, your documents, your content — yours. The engagement is built so your teams author, review and publish without us, and the platform is handed over with them: the registry, the publish gate, the tokens, the catalogue and the studio.