Daniel Hopp
Back to selected work

One project.
Six
 departments.

Tauron is the reusable platform behind Bohris, a German vertical SaaS product for geothermal drilling companies. This page is the public engineering case study: no customers, no productive use. It follows one synthetic job from inquiry to field execution, invoicing and management oversight.

Flutter / RustIndependent product · case study
PROJECT / DEMO-001SYNTHETIC DATA
WOHNQUARTIER HAVELBOGEN · POTSDAM One shared
operational story.

Every handoff adds context without replacing the project underneath it.

  1. 01Customer inquiry
  2. 02Sales
  3. 03Project operations
  4. 04Field execution
  5. 05Documentation
  6. 06Finance
INQUIRYDELIVERYOVERVIEW

A workflow is only as strong as its handoffs.

Specialized work crosses roles, devices and connectivity conditions. The difficult part is not another dashboard. It is preserving meaning while responsibility moves: what was promised, what was planned, what happened in the field and what remains financially open.

Follow the same project all the way through.

Start with the explanation, then see the workflow in the application. Each animated chapter has a matching product recording below it, using synthetic demo data. Recordings show the UI journey, not every technical guarantee illustrated in the diagrams.

Customer inquiry

Start with the actual site.

Location, specialist layers, building context and contact data become one qualified starting point for the business.

Handoff
Site → inquiry
Outcome
Stored assessment
See productBack to explanation Actual application · 0:41

Enter a site, review the initial assessment and sizing, then submit an inquiry. This is an initial estimate with demo geodata, not a permit or geological certification.

0:00 / 0:41

Actual application · synthetic demo data · German UI · no audio. Recorded 18 Sep 2026; not production use.

Customer inquiry animated process diagram

Sales

Keep the context attached.

Sales carries the same request through a reviewed offer, explicit acceptance and a linked order before releasing it to operations.

Handoff
Inquiry → order
Outcome
Released order
See productBack to explanation Actual application · 1:07

Carry the inquiry into an offer, acceptance and a released order for project operations.

0:00 / 1:07

Actual application · synthetic demo data · German UI · no audio. Recorded 18 Sep 2026; not production use.

Sales animated process diagram

Project operations

Turn intent into a plan.

The released order becomes operational work: boreholes, evidence, crew, equipment and date stay connected to one project.

Handoff
Order → field plan
Outcome
Executable assignment
See productBack to explanation Actual application · 4:12

Plan boreholes, record permit documentation and assign equipment and a crew to the project.

0:00 / 4:12

Actual application · synthetic demo data · German UI · no audio. Recorded 18 Sep 2026; not production use.

Project operations animated process diagram

Field execution

Make the plan survive the field.

Measured depth, layers, reports and photos remain on the device while offline, then synchronize into the shared project state.

Handoff
Plan → actuals
Outcome
Durable field record
See productBack to explanation Actual application · 1:13

Record drilling work and progress in the native Android app. This recording shows the connected field workflow; it does not demonstrate an offline recovery or conflict scenario.

0:00 / 1:13

Actual application · synthetic demo data · German UI · no audio. Recorded 18 Sep 2026; not production use.

Field execution animated process diagram

Documentation

Turn execution into evidence.

Plan and actuals are reconciled, sources are bundled and only a complete, unchanged evidence set can become the final document state.

Handoff
Actuals → evidence
Outcome
Verified document
See productBack to explanation Actual application · 1:27

Review measured quantities and test reports, then assemble and finalize the documentation package.

0:00 / 1:27

Actual application · synthetic demo data · German UI · no audio. Recorded 18 Sep 2026; not production use.

Documentation animated process diagram

Finance

Close the information loop.

Advance, progress and final invoices remain linked to the same project while payments update the view available to management.

Handoff
Evidence → finance
Outcome
Visible payment state
See productBack to explanation Actual application · 3:41

Follow project-linked invoices and recorded payments through to the management overview.

0:00 / 3:41

Actual application · synthetic demo data · German UI · no audio. Recorded 18 Sep 2026; not production use.

Finance animated process diagram

One uninterrupted data line.

The complete 160-second film joins the same six chapters without repeating their introductions. It is a schematic view of implemented workflows, not a recording of production use.

Complete Tauron and Bohris animated workflow overview

A platform beneath the department views.

This is deliberately a public abstraction. It shows responsibility and data flow without revealing the private repository, deployment topology or internal service inventory.

01Flutter role clientsWeb / iOS / Android
02HTTP gatewayOne product boundary
03Typed contractsExplicit handoffs
04Domain servicesBusiness ownership
05Durable storesData / events / objects

Disconnected work cannot become invisible work.

Pending field changes stay on the device. Reconnect drains the queue while the app is running. The push API can answer a stale edit with 409 and both versions when a base version is supplied; the field client does not send that version yet, so a stale field edit is a designed contract, not a demonstrated 409 in operation.

01Capture locallyWork survives a connection loss.
02Queue on the devicePending state stays inspectable.
03Sync or conflictSuccess is explicit; the conflict contract keeps both versions.

Prove the seam, then prove the journey.

The local full-flow proof combines web stages and a native field stage against one shared backend. Browser flows write through the UI, reload or open a fresh page, and verify persisted readback. Published animations explain the system; they are not a substitute for the underlying test gates.

STAGE 01

Contracts and focused behavior

Fast tests pin down typed boundaries, state transitions and failure semantics close to the code that owns them.

STAGE 02

Role-level product paths

Real UI writes, discards local client state through a reload or fresh page, and reads the persisted result back, so a client-only success cannot masquerade as a working handoff.

STAGE 03

Cross-device demo journey

Web inquiry and planning, native field execution, then web finance and overview are specified as one journey. The native field stage is reported separately, and the last dated full run is historical (4 Jul 2026), not a fresh pass.

Evidence boundary Product implementation and focused offline/conflict proof live in the private repository. The public case study exposes sanitized product behavior and its limits without publishing private source or infrastructure.

Product thinking and engineering in one loop.

I own

  • Product concept and vertical workflow design
  • Flutter product surfaces across role contexts
  • Rust service boundaries and data contracts
  • Architecture, quality strategy, integration and release approval; coding agents speed up implementation under my review

Public limits

  • No customer, adoption or production-use claim
  • No source code or private infrastructure detail
  • No public demo account
  • No test freshness claim without a dated proof run
WHY THE CODE IS PRIVATE

The source repository remains private because it contains proprietary product and infrastructure details. This case study shows the public product boundary, my engineering contribution, selected architecture decisions and sanitized evidence.

Design the product around the work that must survive.

This page is the public case studyBack to selected workGet in touch