Skip to content
Data Forge

How we work.

A flow with gates you hold, six rules we do not bend, and three shapes an engagement can take. Written down so you can check us against it.

How work moves.

The same flow runs our own estate and every client engagement. Four of the six stages end at a gate you hold. Nothing ships unverified, and merging is never the finish line.

  1. Scope

    gate · path

    We write down the goal, the success criteria, the systems touched and the people needed. You see it before anything else happens.

  2. Design

    gate · spec

    One-way doors, meaning data models, wire contracts and store choices, are designed and agreed on paper. Reversible things ship lean.

  3. Plan

    gate · plan

    The spec becomes an ordered task list with a file-ownership map, so parallel work never collides.

  4. Build

    no gate

    Specialists build in isolated worktrees against a shared ledger. You can see what is in flight and what is blocked without asking.

  5. Verify

    no gate

    Tests, lint and type gates across everything affected, then adversarial review for anything high-stakes. Red does not ship.

  6. Ship

    gate · ship

    Merging deploys nothing. An image is built, pinned, released and reconciled, and the change is done when a probe shows it running.

What done means

A change is done when the pod is running the new image and a probe shows traffic. Not merged, not staged, not "should work". The same standard applies to a landing page, a migration and a model.

Six rules we build by.

These are lifted from the constitution that governs our own estate. They are the tiebreaker when the fast option and the right option disagree.

  1. The proper fix, not the recurring patch

    Root cause over symptom, even when the proper fix is the more annoying one this week. A stopgap is allowed to unblock work already in flight, with the real fix filed at the same time. A stopgap without a filed fix is a defect.

  2. Long-term choices on one-way doors

    Data models, wire contracts, store choices and dependencies are expensive to reverse, so they get design investment up front. Everything reversible ships lean. Knowing which is which is most of the job.

  3. Right tool for the right job

    The polyglot split is deliberate. "It is already wired up" is not an architectural reason. Putting work in the wrong store because that store was convenient is how systems rot from the inside.

  4. Done means running in production

    Not merged, not deployed to staging, not "should work". Done is the pod running the new image with a probe that proves it. Everything else is a status update.

  5. Instrumented from the first deploy

    Every service ships observed: traces, structured logs, metrics, error reporting. A component nobody can see cannot be called working. We learned that from a worker that sat wedged and silent for fifteen days.

  6. Built for the estate, never the instance

    Auth, tenancy, telemetry and tracking are built once and serve everything. The anti-pattern is the per-app copy: five slightly different auth flows, five places to fix the same bug.

Three shapes an engagement takes.

Fixed scope where scope can be fixed. Staged gates where it cannot. Nothing priced on an undefined scope, because someone always ends up paying for the guess.

Systems review

When the system has grown faster than the plan did.

A fixed-scope assessment of your architecture, data placement, deploy lane and measurement. You get the map whether or not you go further with us.

  • Architecture and data-flow map
  • Store placement and schema review
  • Deploy, rollback and observability audit
  • Tracking and attribution health check
  • Ranked findings with effort estimates
Book a review

Platform build

Greenfield, or a rescue that needs to stop bleeding.

We design and build the platform: services, data model, event pipelines, deploy lane and the surfaces on top. Staged gates, so you can stop or redirect at each one.

  • A committed design spec before any build
  • Services, pipelines and product surfaces
  • Infrastructure and a deployment lane
  • Observability from the first deploy
  • Handover documentation and runbooks
Scope a build

Build and operate

When you want it run, not just delivered.

Ongoing engineering plus operations: releases, capacity, upgrades, incident response and a roadmap reviewed with you each quarter.

  • Everything in a platform build
  • Ongoing feature engineering
  • Release management and upgrades
  • Monitoring, alerting and incident response
  • Quarterly architecture review
Talk to us

Straight answers.

Do you work with an existing codebase, or only greenfield?
Both, and the existing ones are usually more interesting. The first step is the same either way: we map what is really there before proposing changes. A rescue normally starts by making the system observable, because you cannot fix what you cannot see.
Who owns the code and the infrastructure?
You do. Work lands in your repository, on infrastructure you control, using tools you can hire for. We do not build on anything you cannot take over.
Where does our data live?
Wherever you need it to. We run self-hosted infrastructure in Australia and are comfortable with data residency and Privacy Act obligations. If you are already on a hyperscaler, we work there instead. The architecture matters more than the postcode.
What does "done" mean on an engagement?
The change is running in production and there is a probe showing it working. We do not report a task complete because a pull request merged. In our own estate, merging deploys nothing by design, and the same standard applies to client work.
Do you do fixed price?
For scoped pieces like a systems review, yes. For a platform build we work in staged gates with a cost per stage, because a fixed price on an undefined scope is a guess that someone eventually pays for. You can stop at any gate.
How do you handle privacy and consent?
As an architectural constraint rather than a banner. Collection is consent-gated at the source, suppression outlives erasure, and deletion is verified against the store rather than assumed from a success response. We have found and fixed the failure where an erasure pipeline reported success and deleted nothing.

Who is behind it.

Build things that keep working when nobody is watching them.

Jacob, founder of Data Forge. An advanced degree in AI, machine learning and data science, applied to business. Taught data science at Curtin University and the Institute of Data. More than ten years running companies, including a marketing business with over fifty staff. Owner-operator of the SURE group.

I used to run a multi-million dollar marketing company with over fifty staff. On paper it looked like success. Behind the scenes I was constantly putting out fires, working around the clock, and slowly burning out.

Then everything changed. I lost my mum, and I realised how much I had missed while buried in the grind. I left the company, moved home, and began rebuilding with a new goal: create freedom, not stress.

Data Forge is that goal turned into an engineering practice. I build systems that keep working when nobody is watching them, so the people who run businesses can be present, not just productive.

Open a conversation.

Tell us what you run today and what keeps breaking. We will tell you, plainly, what we would do about it and whether we are the right people to do it.