obiekt.io — case study

Project overview

A planned SaaS tool for building managers: residents report faults by QR code, voice or e-mail, contractors work from a link, and every job ends with a PDF protocol and acceptance. Only the foundation exists so far.

Status

In development

Source

Private repository

Problem

A building manager receives a report, has to pass it to a contractor, follow the case and later show that the repair was done. Today that happens across phone calls, e-mails and spreadsheets. obiekt.io is meant to keep the whole path, from report to acceptance, in one place.

Product and users

For: building managers, their contractors and the people who report faults. The intended product (a goal, not a working feature):

• Report a fault by scanning a QR code, by voice or by e-mail, with no account and no app
• Send the job to a contractor as a link, with the exact location and entry route
• Follow the case through blocks, a completion form and a PDF protocol
• Accept the repair, or send it back, and keep the history of the building
• See a monthly report, shareable with a residents’ board by link

What is coming

The repository is at the end of its foundation stage. Most of the work is still ahead, and this is the order it is planned in. Nothing below the first line exists yet.

Done · Foundation

Three service skeletons (a web page in three languages, a Spring Modulith core with 15 modules, a FastAPI service), initial API contracts, a local Docker Compose environment and the engineering rules.

Next · Core flow

Organizations and roles, buildings with exact locations and QR labels, tickets and work orders, assignment, and the contractor link with SMS verification.

Next · Completion

The completion form, versioned PDF protocols, acceptance by the manager, notifications and the entry-code vault.

Later · Channels and AI

The voice assistant, e-mail intake, AI classification with Polish, English and Ukrainian translation, and the danger-alert path.

Later · First pilot

Monthly reports, monitoring, backup and restore drills, a security review and a first pilot with a residential property manager.

Later · After the pilot

An office-building profile (zones, tenants, on-site teams), connectors to property-management software and a searchable knowledge base per building.

Architecture

A planned modular monolith: one Spring Boot core owns permissions, state changes and background jobs, a separate FastAPI service only returns AI proposals, and PostgreSQL keeps the facts with every row tied to an organization. Voice runs on ElevenLabs and calls back into the core through a few narrow tools.

The core decides everything that has consequences: who may see what, which state a job may move to, what a contractor may read. The AI service never writes to the database, and the voice agent can only call a handful of core tools.

Engineering challenges ahead

1. Isolation between organizations

   Every row belongs to one organization and the database enforces it with row-level security. Tests generated from the API check that one customer never reads another’s data.

2. Entry codes for contractors

   Codes are encrypted, shown only to a verified phone on the right job, and never copied into logs, AI prompts, documents or the browser cache.

3. Voice intake that cannot lose a report

   The draft is saved while the call is running, the case number is given only after saving, and a tool call and the final webhook must never create two tickets.

4. Jobs that survive restarts

   State changes and events are saved together, background jobs retry safely, and reminders still fire once after a restart.

Technical decisions and trade-offs

Stack

Testing and quality

What is checked so far is recorded in dated local reports in the repository. No passing CI run is claimed yet.

Checked so far

The core architecture test over 15 modules, the web build with a Playwright smoke test and accessibility scan, and a health test for the AI service.

Planned checks

Isolation tests for every endpoint, a canary test for entry codes, voice and AI evaluation sets, load tests and a restore drill before the pilot.

Evidence limits

Local runs on one machine. No CI result, no business endpoints or tables, no full login and no AI features yet.

Screenshots

Pinned screenshots from a local run of the project. It is not deployed, so there is no live demo.

Source code