AI and language
- Vertex AI with Gemini for dialogue, classification and extraction
- Document AI for OCR on leases and invoices
- Cloud Translation v3 for ticket translation on the EU endpoint
Architecture
How VerwaltKlar is built.
This page is written for technical evaluators, partners and investors. It sets out the services in use, the path a report takes through the system, and the limits we deliberately imposed. The product is a working end-to-end system in pilot preparation.
Working end to end.
Every capability described here runs in the product today, on Google Cloud, in the europe-west1 region.
Platform
Entirely on Google Cloud, provisioned as code.
Every environment is created from Terraform. There are no hand-made production resources, and each change is traceable in version control.
Runtime
- Cloud Run for the chatbot service (FastAPI, Python)
- Cloud Functions for privileged workflows and triggers
- Cloud Scheduler for deadlines, escalations and review cycles
Data and identity
- Firestore as the primary datastore with server-side rules
- Cloud Storage for photos and documents, reachable only via signed URLs
- Firebase Authentication for identity, with roles held as our own source of truth
Operations
- Terraform as the single source of infrastructure
- Artifact Registry and Cloud Build for containers and delivery
- Secret Manager for every runtime secret, nothing in the repository
The path of a report
From a chat message to an assigned job.
Each step is a separate, auditable transition. None of it runs in the user's browser.
- 01
Arrival
The messenger webhook hits Cloud Run. Shared-secret authentication and IP validation happen before anything is processed.
- 02
Guided conversation
A state machine drives the intake while Gemini handles intent recognition and judges whether the description is sufficient.
- 03
The ticket is created
The case is written to Firestore. Photos go to Cloud Storage, reachable only through signed, role-checked URLs.
- 04
Automatic triage
A Firestore trigger starts liability classification, deadline calculation, translation and the scoring of suitable businesses.
- 05
Matching and approval
The office decides. Businesses respond through a secure one-time link, without an account, with atomic conflict resolution on acceptance.
- 06
Deadlines and closure
Scheduled jobs escalate overdue cases. Closed tickets move into an archive together with their history.
Design decisions
What we deliberately built this way and not another.
- 01
Rules beat the model on safety
Gas, electricity, escaping water and security risks escalate through a fixed rule. A model may raise that classification but never lower it.
- 02
Matching is deterministic
The ranking of businesses comes from a published formula — proximity, rating and completed cases — not from a model. The manager's trusted trades always rank ahead of the network.
- 03
Data minimisation before acceptance
Before accepting, a business sees only category, severity, a rough area and time windows. The full address and contacts are released only after acceptance.
- 04
No privileged writes from the client
Role, active status and linkages are closed to clients. Every sensitive workflow runs through a server-side function.
- 05
Tokens stored as hashes only
Invitation and job links are stored solely as SHA-256 hashes and never logged in clear text.
- 06
AI consumption is metered
Every model call records its token usage. Cost per ticket and per lease are therefore known quantities rather than estimates.
Scaling
How consumption grows with the portfolio.
Resource demand tracks almost entirely with the number of managed units. These are the quantities that drive cloud consumption:
- Gemini calls per report: guided dialogue, classification and the liability check
- Document AI pages per lease taken on and per invoice processed
- Translated characters per ticket and target language, cached server-side
- Cloud Run instances that scale to zero between reports
- Scheduled jobs on a fixed cadence, independent of portfolio size
Because every model call logs its usage, demand per additional unit can be extrapolated rather than estimated.
Status
Where the product stands today.
- Working end to end: lease intake, reporting, triage, matching, closure
- Four roles with separate interfaces: office, owner, tenant, trade business
- Telegram in use, WhatsApp connected as a second channel
- Access rules and workflows covered by automated tests
- Pilot preparation with property managers under way
Want to look under the hood?
We're happy to walk partners and technical evaluators through the system in detail.