This case study is about a real person doing real work the hard way, a workflow that needed to exist as software, and a two-day build that produced enough to apply for funding and teach a methodology.
It is also about why there are two versions of the site — and why the older, smaller one is the more instructive one.
The Person and the Problem
The client is an environmental advisor for the Norwegian Dance Company. His work is specific and consequential: he plans the company's tours with the goal of minimizing CO2 emissions. Every flight, every hotel, every ground transfer — he evaluates the options, makes the decisions, and documents the impact.
The documentation part is where the work breaks down.
Every receipt is scanned manually. Every data point is entered by hand into a spreadsheet. Tickets, hotel confirmations, transport invoices — each one requires a human to read it, extract the relevant numbers, and place them correctly in the model. The spreadsheet is large. The tours are complex. The process is slow, error-prone, and deeply tedious for someone whose actual expertise is environmental strategy, not data entry.
He asked for his full workflow to be modelled and automated as far as possible. The goal: receipts and invoices go in, CO2 impact data comes out, without manual transcription in between.
HITM was not chosen for this project after the project started. HITM was the reason the project could be taken on at all.
Why HITM Was the Starting Condition
A workflow automation of this kind — multi-modal input, n8n orchestration, multilingual interface, structured data output, ODS export for handoff — is not a project a non-developer would typically propose to build in two days. The technical surface area is wide. The integration points between systems are numerous. The margin for silent errors is high.
The reason it was proposable is that HITM separates the question "what must the system do?" from the question "how does the system do it?" The first question is a product question, answerable from a deep understanding of the client's workflow. The second question is an implementation question, delegatable to an AI executing within defined constraints.
The client's workflow was understood before a line of code was written. The intake modes — schedule-based planning and receipt/invoice processing — were defined as separate systems with separate data shapes before either was built. The n8n webhook architecture was specified as the integration layer before the workflows were designed. The trilingual requirement (English, Norwegian, German) was a constraint in the spec, not a feature added later.
Structure before execution. That is what made the two-day timeline possible.
What Was Built in Two Days
The frozen teaching snapshot represents approximately one third of the client's full workflow. It is not a prototype or a mockup. It is a working system — deployed, testable, and demonstrably functional — that covers the first major arc of the automation.
The demo UI is a trilingual web interface (English, Norwegian, German) with a language switcher. It supports two intake modes: schedule ingestion (for tour planning data) and receipt/invoice ingestion (for processing travel and accommodation documents). A technical operator panel handles the review step (R05) and ODS export (R08) — the point at which processed data is handed off to the client's downstream tools.
The backend proxy sits between the UI and the n8n workflows, handling CORS cleanly and keeping the browser out of direct contact with the webhook endpoints. This was an architectural decision made early — not a fix applied after a CORS error appeared in production.
The n8n workflow architecture handles the actual processing: ingestion payloads arrive at versioned webhook endpoints, are validated and processed, and return structured responses. The versioning discipline — `/v1-9/`, `/v2-1/`, `/v2-2/`, `/v2-5/` — means each workflow iteration is a named, addressable endpoint. Rollback is possible. Parallel testing is possible. Nothing is overwritten silently.
The receipt/invoice intake mode was the hardest problem to solve. A schedule is structured data — dates, locations, transport modes — with a relatively predictable shape. A receipt is not. Hotel invoices, flight confirmations, and ground transport documents from different countries, different airlines, and different hotel chains arrive in formats that share almost no structural consistency. The intake mode had to handle that variance without requiring the client to pre-process or normalize the documents.
Getting that right required iteration, documented constraints, and clear approval gates at each step. It was not solved in the first session. It was solved through the same compounding-spec discipline described in the editorial design case study: each failure became a constraint, each constraint narrowed the failure space, and the system became progressively more reliable as the specification became more complete.
Docker deployment was part of the spec from the start. The system runs in a container, with webhook URLs configurable via environment variables. This means the same build can run locally for development, in a staging environment for client review, and in production without code changes. That is an architectural decision, not a deployment afterthought.
Why There Are Two Versions of the Site
The CO2Calc site exists in two states: a frozen teaching snapshot and a live evolving version.
The frozen snapshot is the two-day build. It represents the state of the system at the point where it was clean enough to teach from — where the architecture was legible, the decisions were documented, and the constraints were visible. It is the version described in this case study.
The live version is further developed. The receipt intake and processing pipeline is fully working. Additional workflow stages have been added. The system has moved closer to the client's complete workflow.
The frozen version is preserved because a live, evolving codebase is a poor teaching artifact. It changes. The decisions that shaped its early architecture become buried under later additions. The moments where the methodology produced a specific outcome — a clean integration point, a correctly-bounded workflow, a well-structured handoff — are harder to identify once the system has grown beyond them.
The frozen snapshot holds those moments still. It is the version that can be handed to someone learning HITM and said: here is a real build, at the point where the architecture was clearest. This is what two days of structured building produces.
What Comes Next
The frozen snapshot is the basis for a funding application to NLNet, the European foundation that funds open-source and public-benefit infrastructure. The application is being made jointly with the client.
The funding, if awarded, will be used for hardening, testing, and server infrastructure. The longer-term plan is to establish an NGO to maintain and expand the open-source repository. The goal is a reusable, openly-licensed workflow automation framework for environmental impact tracking — one that can be adapted for other clients with similar documentation burdens in similar domains.
The commercial path alongside the NGO: adapted versions of the workflow for end clients who need the same automation for their own touring, logistics, or event operations, without the capacity or intention to maintain an open-source tool themselves.
CO2Calc is simultaneously a client deliverable, a teaching artifact, a funding application, and the seed of an open-source project. It is the most structurally complex thing in the JBA case study portfolio — and it was started, in its teachable form, in two days.
What This Case Study Demonstrates
HITM enables proposals that would otherwise be unproposable. Taking on a multi-system workflow automation as a non-developer, on a short timeline, for a real client with a real problem, is only credible if the methodology separates product decisions from implementation decisions cleanly. HITM made that separation explicit before the build began.
Versioned webhook endpoints are an architectural decision, not a naming convention. The `/v1-9/`, `/v2-1/` structure in the CO2Calc n8n layer reflects the same discipline as the frozen/live split on the website: the state of the system at each significant point is addressable and preserved. Nothing is silently overwritten. This is HITM applied to infrastructure.
The hardest problem was the most irregular input. The receipt/invoice intake mode was difficult precisely because it faced the highest variance. A schedule has a predictable shape. A receipt does not. The solution was not a more sophisticated parser — it was a more precise specification, built from documented failures. The same compounding-spec principle from the editorial design case study applies here at the data-intake layer.
A frozen teaching snapshot is a first-class deliverable. The decision to preserve the two-day build in its original state, rather than letting it be overwritten by subsequent development, is itself a HITM decision. It treats the architecture at that moment as something worth preserving — not just as a step toward a more complete system, but as a legible artifact that demonstrates what structured building produces.
Technical Reference
Stack: FastAPI backend proxy, n8n workflow orchestration, plain HTML/CSS/JS frontend, Docker deployment.
Intake modes: Schedule ingestion (tour planning data), receipt/invoice ingestion (travel and accommodation documents).
Operator panel: R05 review step, R08 ODS export.
API endpoints: `/health`, `/api/config`, `/api/ingest`, `/api/receipt/review`, `/api/receipt/export-ods`.
Webhook versioning: Separate test and production endpoints per workflow version, configurable via environment variables.
Languages: English, Norwegian, German.
Deployment: Docker container, environment-variable-configured webhook URLs, local and remote compatible.
Live versions:
- Frozen teaching snapshot: co2calc-lab.schmidtpabst.com
- Live evolving version: co2calc.schmidtpabst.com
The Human-in-the-Middle methodology is documented at jba.schmidtpabst.com. More case studies at context.schmidtpabst.com.