← WORKSHEET 02 / 07SINCE 2022LIVE

Rhome World

A global mobility platform that keeps cross-border work compliant: workations, business travel, and international assignments. It automates the legal paperwork, like A1 certificates and per-country rules, behind a self-service portal and real-time dashboards.

VISIT THE SITE
Role
Software Engineer
Stack
Vue · Python
Data
PostgreSQL · AWS
Scope
Core · CI/CD
Client
Rhome GmbH, Germany (remote)
Timeline
Jun 2022 to now. Part-time first, full-time since Nov 2023

100+

one engine, every jurisdiction

CONTEXT

Companies send people across borders constantly. A week working from Lisbon, a client visit in Zurich, a six-month assignment in Berlin. Every one of those crossings triggers social-security and labour-law obligations, and they differ by country, by duration, by whether the person is employed or posted, and by which treaties apply.

rhome turns that into software. Employees request a trip through a self-service portal, the platform works out what the trip legally requires, generates the documents (A1 certificates, posted-worker declarations, certificates of coverage) and gives HR real-time dashboards over the whole population. Data is hosted in Germany.

THE HARD PART

The forms are easy. The rules are not. They are conditional, they interact with each other, they differ per country, and they change. Getting an answer wrong is not a cosmetic bug, it is a compliance failure for a real employee standing at a border.

So the centre of the product is an assessment engine: given a trip, evaluate it against every applicable rule set and produce the required outcomes. Everything else in the platform is a surface onto that engine.

WHAT I BUILT

  • Work on the compliance assessment engine itself, the core that evaluates each cross-border trip against per-country rules and produces the A1, posted-worker and certificate-of-coverage outcomes the rest of the product is built on.
  • Full-stack features around the engine, across a Vue 3 and TypeScript frontend and a Python/Flask backend on PostgreSQL.
  • The statistics and approval flows that sit on top of the engine.
  • Observability for a weekly release cycle: structured logging into Loki, dashboards in Grafana.

REVISIONS · THE CALLS I MADE

A

Layered services: resource, controller, service, repository

Core account and configuration access had callers reaching straight into data access, which tangled rule logic together with HTTP concerns. Layering put a testable seam between them, so the rules can change without dragging request handling along with them.

B

Characterization tests before touching anything

Compliance output is legally consequential, so you cannot improve it by accident. Writing tests that pin the existing behaviour first meant the refactor could be proven to change nothing, which is the only safe way to move code whose output someone relies on at a border.

C

One structured logger, consistent event names and fields

Scattered ad-hoc log lines answer no questions under pressure. Central structured events make an incident searchable in Loki instead of grepped, which is what a weekly release cadence actually needs.

D

Agent-first development, including on the refactors

The large mechanical refactors are where an agent earns its keep, because the work is broad, repetitive, and fully covered by the tests written in rev B.

OUTCOME

  • The engine evaluates trips against 100+ country rule sets.
  • Core account and configuration access runs on a layered service architecture, with behaviour locked by characterization tests.
  • A weekly release cycle monitored on Loki and Grafana, with production questions answered against real data.