How we work
The engagement, and what happens when a platform breaks.
Written for the person evaluating this technically rather than the person who wants it. The order below matters: nothing is built before something has been proven on your own accounts, and nothing is scoped without a handover date.
- Your credentials, your account
- Revocable without notice
- No fee to the report
- Sources connected6, none applied for
- Agreed measureSet in writing first
- Findings you keep3
- Fee to this pointNone
If the value is not obvious you revoke access and keep this. That is a fine outcome and it happens.
The engagement
Five steps, in this order, every time.
A conversation about the bottleneck
Not a discovery questionnaire. You describe the thing your team does manually and resents, or the number nobody can agree on, and we say honestly whether this is the right tool for it.
Usually 45 minutes
A trial on your own accounts
You create every credential at least-privilege scope, in your own account. The measure of success is agreed in writing before anything starts, so nobody grades their own homework afterwards.
You can revoke access at any moment, without notice or reason
A numbers report, then a decision
At the end you get a written account of exactly what it did and what it caught. If the value is not obvious, you revoke access and keep the report. That is a fine outcome and it happens.
No fee to this point
A scoped build
One workflow, one defined output, one handover date, written down before anything is built. New scope is a new document rather than a quiet expansion, which is the failure mode that sinks most engagements of this kind.
Handover includes a runbook you keep
A retainer, because platforms change
Meta, Google and the app stores change their APIs without asking. Fixing that breakage is included rather than billed, and it is the honest reason this is a relationship rather than a delivery.
Monitoring, platform fixes, iteration and support
Who is on it
Three disciplines, and the reason all three are needed.
Most systems of this kind fail at the seam between them: engineers who have never run a campaign, or marketers who cannot build. The point is that the seam is not there.
Performance marketing
Somebody in the room has run the account, missed the target and explained why to a CFO. That is what stops a technically correct answer from being a useless one.
Data and application
Connector work, warehouse modelling, pipeline reliability and the application layer. The systems are built rather than assembled from a no-code canvas, which is why they can be fixed rather than replaced.
Tracking and attribution
Tag configuration, conversions API, server-side tagging and analytics implementation. Most of the findings on this site came from reading configuration rather than reading results.
Engineering evidence
Things you can check rather than take on trust.
A technical evaluator wants facts about how the thing is built, not adjectives about how seriously we take it.
- One runtime dependency in the whole production codebase
- Every deploy gated on a test suite that must pass before it ships
- Continuous deployment behind that gate, so a fix reaches you the day it is made
- An append-only audit trail of every query and every send
- Per-client isolation: separate environments, credentials, configuration and audit trails
- Read-only connectors, so there is no write path to a source to misuse
Before you ask
Continuity, production risk, and who does the work.
What happens if you disappear?
You own every credential from day one, you have a documented runbook per system, and on exit you keep the accounts, the data, the outputs and the documentation. There is nothing of yours to hold, which is deliberate: lock-in through value or not at all.
We have paid for automation that broke in production before.
The demo is the running system rather than a mockup, and every engagement is scoped to one workflow with a defined output and a handover date. The retainer exists because platforms change and things need maintaining; support is the model rather than an afterthought.
Who actually does the work?
The disciplines above are on every engagement, and the person who understands your cost per acquisition is the person specifying the build. There is no translation layer between your problem and the engineering, which is the main reason this works at all.
What happens when a platform changes its API?
It is our job under the retainer. We fix first and explain after. That is the single most common reason systems like this quietly stop working elsewhere, and it is why the arrangement is ongoing rather than a delivery.
Start here
Bring one bottleneck and we will scope it honestly.
Including telling you when the answer is that you do not need us for it, which happens and is cheaper for everyone than finding out in month three.