How we work
What, Where, Who?
Three questions decide an engagement, and we align on all three before anything is built. What are we building? Where does it run — your infrastructure, or ours? Who looks after it once it works? Most of what goes wrong in an integration project is one of these left implicit.
Three questions
Answer these and the rest is scheduling
They are answered in this order, because each one narrows the next. What we are building decides what it needs to run on; where it runs decides who can reach it; and only then is “who looks after it” a question with a real answer.
What
What are we building
Which datasets you want, and what the source forces on the connector to get them. Two sources that look alike can be a week apart, and it is the source that decides.
Where
Where does it run
Your infrastructure, or ours. Not a one-way door — the same container runs in both, so starting on ours does not commit you to it.
Who
Who looks after it
You, or us. We agree the split rather than assuming it. A connector you own keeps running whether or not anyone is watching it — the question is who notices when it stops.
What
Two things, and only one of them is what you wanted
You are buying a connector and the data models on it. Keeping those apart is the most useful idea on this page, and it is why you are not charged per endpoint.
Connector
The technical connection
One source system into one warehouse — Personio → BigQuery. It handles authentication, API access, scheduling, retries, rate limiting, state management, monitoring and deployment.
Charged once per source system. Every data model on it shares it.
Data model
The data you actually asked for
A complete, usable business dataset in your warehouse — Employees, Absences, Applicants, Customers, Orders, Invoices. One data model may need several API resources; that is our problem, not your line item.
Three come with the Base Connector. After that they are priced by type — cheaper in bundles.
The source decides how hard the connector is
Some sources are a scheduled request. Others force pagination that shifts under you, work that has to be split across workers, or a connection held open all day. That is what puts a connector in the Standard or the Complex band, and it moves once per source system — never per dataset. The four shapes set out what changes between them.
A difficult source never makes a data model a more expensive type. Otherwise you would pay for the same authentication problem once per dataset. What decides a data model's type is the dataset itself — how many resources it needs, whether the source can say what changed, and how much has to be derived.
What you supply, and what we work out
You describe
- Which API
- Which warehouse
- Which datasets you need — Employees, Absences, Applicants
- How often, and how much history
We work out
- Which API resources each dataset needs
- How they relate, and how to keep them in sync
- The type of each data model, and the reason for it
- A fixed price and a delivery window
Pinned down in a brief, before the build
Four things, and none of them is a specification document. The brief is where we agree what “done” means, before the build rather than after it.
The data you need
Named as business datasets — Employees, Absences, Orders — not as endpoints. Which warehouse they land in, how fresh they have to be, and how much history you want on the first load.
The validation checks
What has to be true of the data before your team will trust it: which fields cannot be empty, which keys must be unique, which totals have to reconcile against a report you already run. These become tests that run on every load, not a one-off inspection.
The acceptance criteria
The checks that decide the connector is correct. Four are standard and mechanical, and they are the same on every engagement — set out below. Anything specific to your data is agreed here before we start.
The test data
A sandbox account, test credentials, or a representative extract — enough to exercise the connector without touching production. Where a source has no sandbox, we say so early, because it changes how the connector is built and how it can safely be changed later.
Where
Your infrastructure, or ours
One question, and we would rather you took the easy answer than spent three weeks picking the perfect one — because it is reversible.
Your infrastructure
- Your cloud, your cluster, or on-premise.
- Nothing of yours passes through our systems. This is the only arrangement where that sentence is literally true, so it is the only one we say it about.
- You hold the credentials, and your change process governs deployments.
Ours
- The fastest way to have data arriving — days, not a procurement cycle.
- We host the connector, so we are a data processor and sign a DPA on that basis.
- The data still lands in your warehouse. That part never changes.
Who
Who looks after it
Three columns, and the middle one is the point: some of it is neither of us by default until we agree it. The rest is settled the same way — we align on it up front rather than finding out during an incident.
Always ours
- The connector meets the acceptance criteria it was built against
- The SDK and control process are maintained for the term of the agreement
- You are told when a source breaks, whether or not we can fix it
Always yours
- The warehouse, and everything in it
- Access to the source — credentials, and approvals for allowlisting
- The source's own data quality. A wrong figure in the API arrives as a wrong figure
- What the data is used for downstream
Agreed per engagement
- Service-level objectives — what we respond to, how fast, in which hours
- Term, notice and what happens at the end of it
- Who deploys, and who has to approve a deployment
- Who reviews a change to connector code
- Where alerts go, and who is expected to act on them
- How a change request is raised, estimated and priced
- Who holds the secrets
Worked example
One dataset, four API resources, one price
You ask for Employees. Working out that it needs four resources — and landing all four in raw form alongside the model — is included.
The nine steps
The first four are free
They produce a fixed price you can hold us to. Step four is the only meeting you have to attend.
01
Sign up and request a connector
Free. Set up your organisation and repository, then tell us which business datasets you want — Employees, Absences, Orders — in your own words.
What we do
Give you an account, a dashboard and a repository, then read the API's own specification and work out which resources each dataset needs.
What you provide
The datasets you want, a link to the API documentation, your warehouse, how often, how much history.
What you get
A repository with your code in it from the first commit, and never a question about how many endpoints the API has or how it paginates. No card, no commitment.
02
Assessment
The connector is profiled once. Then each dataset you asked for is classified into Simple, Standard, Advanced or Custom.
What we do
Profile the connector, classify each data model against the same factors for every customer, and work out what your environment needs. A hard connector never pushes your data models up a type.
What you provide
Nothing. If the API has no documentation and can't be reached, we'll say so.
What you get
A type and the reason for it per dataset, in plain language — and an honest answer if a vendor connector would serve you better.
03
Estimate
Two subtotals in four-hour blocks: what the environment costs, and what the connector costs. Then one row per data model.
What we do
Write down the architecture, the environment work, a price per data model, the effort in blocks and the delivery window.
What you provide
Nothing.
What you get
An indicative fixed price, the hours behind it, and your expected monthly cloud cost — free. The block counts are our estimate, not a rate: the price is fixed whether or not it takes that long.
04
Confirm scope
One call. Which data models, cadence, backfill depth, acceptance criteria, order.
What we do
Fix the data model list, the sync design, where it runs and what 'correct' means.
What you provide
A decision, and who will issue credentials.
What you get
An order at the indicative price. This is the only meeting you have to attend.
05
Discovery
We call your API for real, prove the incremental cursor moves, size the backfill, and confirm the price in writing.
What we do
Four mechanical tests against your live API, then commit the data contracts to your repository and confirm, re-quote or withdraw the price.
What you provide
Credentials, and an approval by email on one page.
What you get
A price that has survived contact with your actual API. This is inside the fixed price, not added to it — nothing here is a separate charge.
06
Build
The connector once, then each data model on top of it.
What we do
Build the connector (auth, pagination, rate limiting, state), then each data model: resource extraction, mapping, transformation, incremental logic.
What you provide
Sandbox or read-only credentials, and a warehouse dataset to land in.
What you get
Progress you can see in your own repository, commit by commit — and the raw resources landing as they are built.
07
Test
Four checks: schema conformance, completeness, idempotent replay, recovery.
What we do
Run the full backfill, kill a run mid-execution and prove it resumes cleanly.
What you provide
Someone to confirm the data looks right.
What you get
Evidence, not assurance. The backfill has actually been run, not sampled.
08
Deploy
Into your cloud account, through your pipeline, from your repository.
What we do
Deploy from code, wire the secrets, set up the monitors and alert routes.
What you provide
Deploy permissions, and network access if the API is private.
What you get
A connector running in your account. Not ours, then migrated later.
09
Handover
One hour, recorded. Then our access can be revoked and nothing stops.
What we do
Walk through the code, the runbook, the monitors and the failure modes.
What you provide
The people who will own it.
What you get
The data models, the raw data behind them, the code, the infrastructure, the credentials and the docs. Support is optional.
Acceptance
How we prove the connector is correct
Not by a demo, and not by asking you to write a specification. Four mechanical checks against the API's own responses.
| Check | What it demonstrates |
|---|---|
| Schema conformance | Every landed row matches the agreed contract; violations quarantine rather than silently drop |
| Completeness | Row counts reconcile against the API's own counts, or an independent re-extract over a bounded window |
| Idempotent replay | The same run executed twice produces one copy of the data |
| Recovery | A run killed mid-execution resumes from its checkpoint without loss or duplication |
Fixed price
When we will quote a fixed price, and when we will not
We will
- The API is reachable from somewhere we can run code.
- Test or sandbox credentials can be issued.
- Some specification exists — a spec file, docs, or one working example call.
- You already have BigQuery, Snowflake or Databricks.
- You can name the datasets you want as business datasets.
We will not
- The API has no documentation and cannot be called.
- Nobody can issue us credentials, so we cannot see a real payload.
- There is no warehouse yet. We do not build those.
- The API's terms of use prohibit extraction.
- The dataset needs reconciling across several APIs — that is Custom, quoted individually.
Tell us about one API
Send the documentation link. You get a complexity tier, a recommended architecture, a fixed price and a delivery window — free, usually the same day. If a vendor connector would serve you better, we will say that instead.
Get an estimate