Approach
How we
work with you.
Written scope first, engineer contact throughout, clean exit at the end.
Most of what goes wrong on projects like these goes wrong before any code is written — an unclear scope, a decision nobody owns, a requirement that only ever existed in one person’s head. Here is how we avoid that, the ways you can work with us, and what moves a price.
Engagement
From first call to running system.
You can stop after any stage. The scoping study in particular is designed to be a complete, useful thing on its own.
- 01
Conversation
Thirty minutes on the actual problem. We are trying to work out whether this is a data problem, an automation problem, a software problem, or something you should not be paying anyone to solve. Free, and occasionally it ends with us saying don't.
- 02
Scoping study
A paid, fixed-fee piece of work that produces a written specification: what gets built, how it behaves when things go wrong, what it costs to build and to run, and what would make it a bad idea. Yours to keep, including if you take it to somebody else.
- 03
Build
Work happens in short cycles against the scope, with something you can look at early. You talk to the engineer building it, not to an account manager relaying questions.
- 04
Acceptance
The scope document is the test. Each deliverable is checked against what it said, in your environment, with your data.
- 05
Handover
Source, schemas, credentials, runbooks, and documentation. Whether or not we stay on afterwards, you are not stranded if we stop.
- 06
Operate
Optional and separate: monitoring, fixes, and changes under an agreement with a defined response time and a clean way out.
Shapes
Four ways to work with us.
Most clients use two of these in sequence.
Scoping study
Fixed fee, one to three weeks. Produces the written specification, the architecture, and the cost of building and running it. The cheapest way to find out whether the rest is worth doing.
- Fixed fee
- Deliverable is a document
- No obligation to continue
Fixed-scope build
A defined piece of work with a written acceptance test: an extraction pipeline, an automated process, a system module. Priced as a project once the scope exists.
- Priced after scoping
- Acceptance against the scope
- Handover included
Managed service
We run it: extraction pipelines, automated processes, or a deployed system. Monthly, covering operation, monitoring, and the fixes that keep it working when sources and APIs change.
- Monthly
- Defined response time
- Cancellable with notice
Retained capacity
A block of engineering time each month against a backlog you control. Suits organisations with continuous small work rather than one large project.
- Monthly block of time
- You set priority
- Unused time does not roll forever
Pricing
Priced per project.
We do not publish Starter, Pro, and Enterprise tiers, because the work is not shaped like that. A published tier would either be wrong for you or quietly become the number regardless of what you needed.
What we can do is be clear about what moves a price, so you can place yourself roughly before we speak. The real number comes out of the scoping study, based on your data rather than a guess.
Two numbers, kept separate: our fee for building and running the work, and operating cost — infrastructure, proxies, and model spend — which is passed through at what it actually costs.
- 01
Volume and frequency
A source crawled hourly across a national market and one crawled weekly in a single city are different products, even though the parser is the same.
- 02
Fragility of the target
Well-structured sources and stable APIs are cheap. Sources that change layout monthly carry a real maintenance cost, and we price that honestly rather than discovering it later.
- 03
Consequence of failure
Work where a bad record costs money needs more validation, more monitoring, and more review. Work where it does not, does not.
- 04
Integration surface
How many systems this must talk to, and how well they are documented. Undocumented internal systems are the most common source of overrun in this business.
- 05
Operating cost
Infrastructure, proxies, and model spend are your running costs. We estimate them at scoping and report them once running, separately from our fee.
- 06
Support expectations
A response time of one business day and one of one hour are different commitments, and only one of them is free.
Operating standard
What you can hold us to.
These apply to every engagement regardless of shape or capability.
Scope before code
Every engagement starts with a written scope: what gets built, what it must do to be accepted, and what is explicitly out. It is short, it is boring, and it prevents the argument that ends most projects.
Fail loudly
Silent degradation is the real failure mode in data and automation work. Systems we build are designed to stop and tell somebody rather than continue producing plausible nonsense.
Measured, not asserted
Coverage, accuracy, and cost are numbers we report, not adjectives we use. Where we cannot measure something, we say that instead of implying we can.
Boring where it counts
Novel technology goes where it earns its place. The parts that must not break — delivery, retries, permissions, backups — are built the well-understood way on purpose.
You own the exit
Source, schemas, data, and documentation are yours, and handover is written into the engagement from the start. Staying with us should be a decision you keep making, not one you cannot reverse.
You talk to the engineer
The person who scopes your project is the person who builds it. There is no account layer between you and the work, and that is a deliberate limit on how many clients we take.
Your side
What we need from you.
Short list, and every item on it is something that has delayed a project somewhere.
- One person on your side who can make decisions, or the project stalls waiting for consensus.
- Access to the people who actually do the work, not only to the people who describe it.
- Real data, or a realistic sample. Systems built against tidy test data fail on contact with yours.
- Credentials and environment access arranged early, because this is the most common cause of week-one delay.
- An honest answer about what has been tried before and why it did not stick.
Questions
Asked before.
Can we skip the scoping study?
For small, well-defined work, yes. For anything where the requirements are still a conversation, no — we would be guessing at a price, and guessed prices are how projects end badly for both sides.
Do you sign NDAs?
Yes, routinely, before any detail is discussed.
Who owns the code?
You do, on the engagements that include handover, which is most of them. Where we reuse our own internal libraries, you get a licence to use them rather than ownership of them, and we say which parts those are up front.
What happens if we want to stop?
Managed service and retained agreements end with notice. Handover of source, data, and documentation is written in from the start rather than negotiated at the exit.
How many clients do you take at once?
Few enough that the person who scopes your work is the person who builds it. That is a real constraint on our capacity and it is the main reason we sometimes say no.
Do you work with other agencies or in-house teams?
Yes. Taking one capability inside a larger programme — running the extraction layer, or hardening an automation estate — is a normal engagement.
Next step
Start with the conversation.
Thirty minutes, no brief needed, no obligation. Worst case you leave with a clearer description of your own problem than you arrived with.