How we work

Four steps, same shape every time.

The shape is the same every time, which is not a lack of imagination. It is that the failures in this work are always the same failures, and each step exists to remove one of them.

A long pale wood meeting table seen down its length, strewn with printed sheets, two open laptops, a stack of ring binders and several mugs, chairs pushed back on both sides, a whiteboard of hand-drawn boxes and arrows on the far wall and daylight from a window on the left

Watch first

Before a line of code.

Watching first is the step most often skipped and the one that decides the rest. An operation described in a meeting and an operation observed on a Tuesday are different operations, and only one of them is the one you have.

The method

What each step is.

  1. 01

    Two people seen from behind at a desk in a working office, one pointing at a monitor filled with a spreadsheet while the other writes in an open notebook, beside ring binders, a desk phone, filing cabinets and a whiteboard of hand-drawn boxes and arrows

    Watch

    We work from your office. No code until we have watched the operation run.

    What happens
    Two or three of us sit with the people doing the work, for the real cycle of it, a week or a month-end. We read the spreadsheets, watch the handoffs and note what people do that nobody wrote down.
    What you get
    A written account of how the operation actually runs, including the parts that surprised the owner.
    Who from Zeta42
    The same engineers who will build the system. Not analysts who hand over to a build team.
  2. 02

    An office wall papered edge to edge with printed process diagrams, yellow and pink sticky notes and heavy hand-drawn arrows running between the sheets, with a table below covered in more printouts, markers and a roll of tape

    Map

    One shared picture of how the business runs, signed off by the owner.

    What happens
    The account becomes one map: every process, every handoff, every system and file, and where each one breaks. We walk it with the owner and the people who do the work until both agree it is true.
    What you get
    The map, signed off. It is the scope for the first build and the foundation for every build after it.
  3. 03

    A desk mid-build: one monitor showing a code editor, another showing a table of records, an open laptop, a printed specification marked up in red pen, a mug and coiled cables, lit by a window behind

    Build

    Working software on real data. Scoped end to end. Not a demo.

    What happens
    One workflow from the map, built on your real data from the first day, put in front of the people who will use it every week and changed when they say it is wrong.
    What you get
    A working system in production, used by your team, with the data migrated and the old spreadsheet retired.
  4. 04

    An open ring binder of printed runbook pages on a desk beside a monitor showing a live dashboard of charts and tiles, with a desk phone, a lanyard and a pen alongside

    Run

    We stay and run it, and build the next system on the same map.

    What happens
    We operate the system with you, fix what the first month reveals, train the people who own it, and scope the second build from the same map.
    What you get
    A system somebody owns, a runbook, and a number to ring.

The engagement

One build, then the next.

First build

A scoped, on-site engagement on your real data. We watch the operation, map how it runs, and build one working system you can put in front of your team. Working software at the end, not a slide and not a demo.

Pilot to production

The first build hardened, integrated with the systems around it, and rolled out to everyone who needs it.

Run and expand

We keep it running, and build the next system on the same map. Each one is faster than the last because the map already exists.

Your side

A desk, the files and an honest hour.

A place to sit in the office. Access to the spreadsheets and systems as they are, not tidied up first. An hour a week with the owner, and permission for the people doing the work to tell us how it really runs. That is the whole list.

On real data

The mess is the requirement.

Building on real data rather than a sample is the other non-negotiable. Software that works on tidy inputs is a demonstration, and the mess is where the requirements actually live.

Questions

What clients ask first.

Do we have to stop work while you build?+

No. The build runs alongside the operation, on real data, and the old spreadsheet stays until the new system has replaced it in daily use.

What if we already have an IT team?+

Good. They are in the room from the first week. The system is built in standard tools so they can maintain it, and the handover includes them.

Do you work outside Abu Dhabi?+

Yes. On site across the six GCC countries. The watch step needs us in your office; the rest can run from ours.

What if the map shows the problem is not software?+

Then we say so. Some operations need a process change or a person, not a system. You keep the map either way.

We stay afterwards. A system nobody owns after handover becomes the next thing somebody works around.