How we work

01

Scoping

We work out what the system has to do and, more importantly, what it has to get right. This is where your success conditions get defined in writing, drawn from your SOPs and the standards your team already holds the work to.
02

Data and SOPs

We need access to the systems involved and the documentation for how the work is done today. Where the documentation and the actual practice differ, and they usually do, we go with the practice.
03

Initial build

We build against the scope and the tests.
04

Review

You'll see it working and tell us what needs to change. Changes will be needed. That's what this phase is for.
05

Iteration and testing

We refine, and we validate against the success conditions from scoping. The system does not go live until it passes them.
06

Deployment

Into your environment, under your access controls.
07

Monitoring

Systems drift. Your operation changes, your data changes, the underlying models change. We watch for it. Monitoring isn't automatically part of an engagement. It's available if you want us to stay on and support the system after the build.

How we know it works

You define what success means. We build the tests.

The scope names the conditions the system has to meet, drawn from your SOPs and the standards your team already applies, before we build anything.
We build tests against those conditions, and nothing goes live until it passes them.
If your SOP requires an exact match, we test for exact matches. If your team's real tolerance is a small exception rate reviewed by a supervisor, we test for that instead. We'd rather know which it is during scoping than after deployment.

Where a human stays in the loop

Three things decide it:

How reliable the technology is for that specific task
What the regulations require
How bad the worst outcome is

Where any of those calls for human review, there's human review. Everything else gets automated, and we put real effort into what reaches the reviewer: clean, contextual, fast to act on. A human-in-the-loop step that takes as long as the original process hasn't saved any work.

Your data

Your data stays in infrastructure you own. In many engagements it never leaves your environment: your cloud, your databases, your access controls.
Nothing lives in our accounts. We never use your data for training.
If you don't have that infrastructure yet, we'll build it. Establishing, migrating, or re-engineering GCP architecture is frequently the first phase of a larger engagement.
The specifics are yours to set: which models are permitted, where they're hosted, what retention looks like, who has access, and what happens to everything when we're done.

Pricing

Fixed fee for clearly defined scope with discrete deliverables. Retainer for ongoing work: monitoring, iteration, systems that have to keep up with a changing operation.
We don't publish ranges. The same request can be a three-week build or a six-month one depending on the state of the data underneath it. We have to scope the project to give you a number.
We're not the cheap option. What the difference buys: the person who understands your operation and the person writing the code are in the same conversation. That's most of why these engagements achieve their goals.
If budget is the primary constraint, we'll say so early rather than after you've spent time on us. We are generally capable of completing a pilot within any budget or under any threshold that would require an RFP, so you can see and test our work before you invest further.

See how we've worked in the past

Illustration of a robot painting gears onto a stack of reports

Automated Pre-Sales Report Generation

Their analysts couldn't produce prospect analyses fast enough to serve small and mid-sized manufacturers and distributors at all. Now it runs without them.

How the automated deck pipeline works →