Fixed-price prototype
A working vendor integration in one month
You name the vendor. Four weeks later there is a running service on a server you own, ingesting their data, and a small web app on top of it you can actually search.
Not a proposal. Not a slide deck. A deployed .NET REST API with its own database, its own scheduled ingestion, its own operational admin — and a search interface in front of it so the data is something you can use on day one rather than something you have to imagine.
€3,000, fixed. Four weeks. One vendor.
Why the offer is shaped this way
A claim about engineering ability is cheap. A running system, on a server you can log into, ingesting a vendor you chose, is not.
So this page does not ask you to believe anything. It offers the smallest complete version of the work, at a price where finding out costs less than a week of arguing about it.
What you provide
Four things, and none of them is a document:
- The vendor. Any provider with a documented REST API — market data, logistics, weather, CRM, payments, telemetry, public registries. If your team is already halfway into an integration, that counts too.
- API access. An account and a key with enough quota to run a real import. The account is yours and stays yours; the vendor bill is yours.
- The data surface that matters. Which of the vendor's objects you actually care about. We agree this in writing in the first days, and it is what "delivered" is measured against.
- One person who can answer questions within a couple of working days.
That is the whole ask. There is no discovery phase to buy first.
What arrives
Everything below is deployed and running at the end of the month, not described in a report.
The service.
- A .NET REST API with its own PostgreSQL database, running under systemd behind nginx, on a Hetzner server (or your infrastructure, if you prefer).
- Scheduled ingestion — a batch lifecycle that knows what is due, what ran, what failed, and what it cost. Not a cron line that calls an endpoint.
- A single vendor chokepoint. Every call to the vendor goes through one place that records it: what was requested, when, what it cost, what came back, and the exception if there was one. Because there is exactly one door, the call log cannot drift from reality.
- A raw response archive. The vendor's exact answer, preserved and content-addressed before your parser touches it. This is the thing that makes "was the vendor wrong, or were we?" an answerable question instead of an argument.
- A canonical internal model — the vendor's shapes translated into yours once, at one boundary, so nothing downstream has to know the vendor exists.
- Data-quality checks that produce verdicts without mutating values, and a measured answer to "how much of this data do we actually examine?"
- A permission boundary — the decision about what may be displayed versus what may feed a calculation, made in one place rather than re-decided by every consumer.
- An operational admin — what ran, what failed, what is stale, what it cost, what is checked and what is not.
- Tests, and a written handover: what I found out about your vendor, what is protected, what is not, and what I would do next.
- The source code, in your repository. No lock-in, no runtime licence, no dependency on me to keep it alive.
The app on top.
A small web application on the same server that consumes the API — search, filters, a result list, a detail view. Enough for you and your colleagues to put the data in front of a real question and see whether it answers it.
It is a working search prototype, not a designed product. It exists so the API has a user, and so the month ends with something you can show someone who does not read code.
The picture this is built from
This is the CompanyGraph admin, live, describing its own vendor pipeline — the system this offer is a bounded version of.
Look at what it says about itself.
Five layers. One is built. Three are partly built. One is marked, in red, DOES NOT EXIST — and the page states which migration step would build it and why that step is not first.
That red badge is the most important thing on this page. A dashboard that only reports good news is decoration. This one measures its own coverage on every load — 40 of 151 vendor columns carry a check is a number the page computes, not a number anyone typed — and it names the layer that is missing rather than quietly leaving it out of the diagram.
That is the standard the month is built to. Not "the integration works." Rather: here is exactly what is checked, here is what is not, and here is where you would look to find out.
An integration is five transformations, not one API call
The reason a vendor integration goes wrong is almost never the HTTP call. It is that five different jobs get collapsed into one method, so when a number is wrong there is nowhere to stand while you work out why.
| Transformation | The question only this layer can answer | |
|---|---|---|
| 1 | vendor response → preserved evidence | Did the vendor change their answer? |
| 2 | vendor-shaped → canonical | Is this field carrying the quantity it claims to carry? |
| 3 | canonical → assessed | Is this coherent — as distinct from well-formed? |
| 4 | assessed → admitted | May this value be used, and for what? |
| 5 | admitted → usable projections | What does this mean in comparable terms? |
Each layer earns its place by answering something no other layer can. Collapse any two and you lose the answer.
The one teams skip is 4. Without it, a value's trustworthiness is not a property of the value — it is a property of whichever function happened to touch it last. Every consumer then re-decides the question, differently, and nobody can tell you which numbers on the screen are safe to act on.
The month builds all five, at prototype depth, for the surface we agree.
What four weeks honestly establishes
I want to be precise here, because the difference matters and overselling it would poison the delivery.
The month buys the backbone, and an investigation of the agreed surface.
- Every layer exists and runs.
- The data surface we agreed is ingested, canonicalised, checked, and served.
- The vendor defects that show up in that surface are found, documented, and defended against.
- The uncertainties that remain are visible and named, not hidden.
The month does not buy exhaustive knowledge of your vendor.
Nobody can promise that before meeting the vendor's real data, and anyone who does is telling you something they cannot know. Vendors have undocumented behaviours that only appear at scale, on one exchange, in one currency, in one fiscal year. What the month gives you is not the absence of those — it is a system in which they surface as a flagged row instead of a customer complaint, and a place to put the fix when they do.
That limitation is not a weakness in the offer. It is the difference between someone who has integrated a vendor and someone who has only read the docs.
The four weeks
Deployment happens in week one, not at the end. A system that has not been deployed is a system whose deployment problems are all still ahead of it.
Week 1 — the boundary and the evidence. Server, database, deploy pipeline, the vendor chokepoint, call and cost accounting, the raw response archive. First real vendor data landing and preserved. You can watch the call log from day three.
Week 2 — canonical model and lifecycle. The vendor's shapes translated into yours. Persistence. The scheduled ingestion lifecycle — what is due, what is stale, what failed, what retries. The admin skeleton so all of that is visible rather than inferred.
Week 3 — assessment and permission. The checks, the verdicts, and the coverage measurement. This is the week the vendor's real behaviour shows up, and it is the week the work stops being generic. Then the admission boundary: what may be shown, what may be calculated on, what may not leave at all.
Week 4 — the app, the tests, the handover. The search interface on top of the API. Tests. Documentation. A walkthrough with you, and a written account of what I learned about your vendor that its documentation does not say.
What this looks like once it has been running a while
The same architecture has been running in production inside CompanyGraph against a financial-data vendor — roughly 14,700 companies, six-figure statement rows, continuous scheduled ingestion. What it has produced is the honest advertisement for this way of working:
- Seventeen numbered vendor behaviours catalogued, each with a reproduction and a defence — and one of them investigated and retracted when the evidence showed the vendor was right and we were wrong. A defect list nobody ever removes anything from is a wish list.
- A malformed symbol returning the wrong company's data with
HTTP 200 OK. Not an error. A different company, at success status, silently. The defence is to encode every identifier and reject any response whose echoed identifier is not the one requested. - A rate limit arriving as a success. Code that checks only the status writes an empty result over good data.
- The vendor's own documentation giving an identifier that 404s against the vendor's own live data.
- Pre-tax profit delivered inside a field named for net income, for about 28% of companies — which produced a false claim on 2,710 of them until a check caught it. Fixing it took a code change and a repair pass over 20,342 already-stored rows, because the store had never been designed to accept a correction.
- Whole fiscal-year filings arriving at the wrong scale, in both directions — a defect that survives every within-year check ever written, because it moves the income statement, the balance sheet and the cash flow together, so every identity between them still holds. It is only visible when you compare a year to the company's other years.
None of that is in any vendor's documentation. All of it is the ordinary content of integrating one.
This is also why the offer is a prototype rather than a guarantee. Those findings took months of running data, not four weeks. What four weeks buys is the machine that makes findings like them visible on your vendor instead of invisible.
Where this sits beside the other work
| This offer | Full pipeline package | Prototype to Product | |
|---|---|---|---|
| What it is | A running prototype on your vendor | A production integration inside your system | A full product foundation |
| Time | 4 weeks | 4–6 weeks | ~3 months |
| Price | €3,000 fixed | from €5,000 | €30,000 |
| Runs where | A new server, yours | Your infrastructure | Your infrastructure |
| Answers | Can this be done, and how would it look? | Make it operational. | Build the whole thing. |
They are a ladder, not alternatives. The prototype is the cheapest honest way to find out whether the shape is right for your data before anyone commits to the larger build — and if you go on to the production package, the prototype is not thrown away. It is the thing that gets hardened.
Price and terms
| Price | €3,000, fixed. Agreed in writing before work starts. |
| Payment | €1,500 at the start, €1,500 on delivery. |
| Duration | Four weeks from the day access and scope are settled. |
| Ownership | The code is yours. The server account is yours. The vendor account is yours. |
| Hosting | Not included — a suitable Hetzner box is roughly €5–20/month and the account stays in your name. I set it up. |
| Vendor costs | Not included. Your plan, your key, your quota. |
The scope — which vendor, which objects, which schedules, what the search app must let you do — is written down and agreed before implementation starts. Anything outside it is named at that point rather than discovered at the end.
What is deliberately not included
Naming this now is cheaper for both of us than discovering it in week four.
- Production hardening. No SLA, no on-call, no alerting beyond a status surface, no security review, no load testing. This is a prototype that runs, not a system under contract.
- Your product's UI. The search app is there to exercise the API and make the data usable, not to be your designed customer-facing product.
- Data rights. Whether you may display or redistribute the vendor's data commercially is between you and the vendor. I build the pipeline; the licence is yours to hold.
- Migration of historical data from an existing provider.
- Deep mapping into a large legacy model beyond what we agree at scoping.
- Vendor-side changes after delivery. If the vendor changes their API next quarter, adapting to it is separate work.
- Ongoing support or retainer. Available, quoted separately.
And one honest exclusion of a different kind: if the vendor's API is undocumented, unstable, or gated behind a partnership process you have not completed, four weeks cannot fix that. We will find out in the first conversation, and I will say so rather than take the month.
How to start
Tell me the vendor and what you want to be able to search. That first conversation is free and short, and its only job is to establish whether four weeks is genuinely enough for what you have in mind.
If it is, we write the scope down, agree the price, and week one starts with a server.
If it is not, I will tell you that — and what would be.
Tell me the vendor and what you want to search. The first conversation is free, and its only job is to establish whether four weeks is enough for what you have in mind.