Case study

uRent: a rental platform that moves money and survives an audit.

uRent is a B2B SaaS suite for commercial vehicle rental operators — a marketplace, an operations system, a white-label shop and an iOS/Android app. I founded it in 2023, designed and built it, and have operated it ever since. This page covers the three decisions that decided the outcome, and what each of them cost.

Role: Founder, architect and sole developer
Period: since 10/2023, ongoing
Status: in production, with paying business customers
Scope: Marketplace, Fleet OS, white-label shop, mobile app

uRent marketplace home page with search fields for location, vehicle type and dates — The marketplace — booking, payment and chat in production

Fleet OS product page showing a live booking from enquiry through to DATEV export — Fleet OS — from enquiry to DATEV export in one pass

The starting point

A commercial vehicle rental operator typically runs the business across half a dozen tools that know nothing about each other: availability in spreadsheets, rental contracts in a word processor, deposits by bank transfer, damage as photos in a messenger, receipts in a shoebox for the accountant. A vehicle standing idle only becomes visible at the month-end close — that is, once it can no longer be changed.

Existing industry software solves parts of this, but is built for fleets above a certain size and priced accordingly. For an operator with thirty vehicles the patchwork remains the economically rational choice — until the first auditor asks for a compliant, tamper-evident journal.

The core of the problem isn't administration, it's the flow of money: rent, deposits and payouts move between renter, operator and platform. Automating that puts you immediately into payment regulation, identity verification and bookkeeping obligations. That is exactly where most solutions give up and hand it back to the operator.

Three decisions

The platform stands or falls on three architectural decisions. Each had a price, and each had to be defended against a more convenient alternative.

Stripe Connect with multi-tenancy from day one

Problem: When a renter pays, the money doesn't belong to the platform, it belongs to the operator. Every payout needs a verified identity, an account and a trail that still holds up months later. The convenient path would have been to run everything through one platform account and transfer onward by hand.
Decision: Stripe Connect as a marketplace model, one connected account per operator, native identity verification, two-factor sign-in, and a permission model that lets external applications access data with graded rights. Tenant separation as the floor plan, not a later conversion.
Effect: A new operator comes on board without anyone setting up payments for them. That is the difference between a platform that scales and one that generates more manual work with every customer.

Accounting an actual tax advisor accepts

Problem: Generating invoices is easy. A bookkeeping path that survives an audit is not: it needs a complete invoice lifecycle, formats the other side can import, direct debits including returns, dunning, partial payments — and a log that visibly proves nothing was altered after the fact.
Decision: A dedicated accounting module rather than a third-party integration: invoice lifecycle, ZUGFeRD and XRechnung export, SEPA direct debit per pain.008 including return debits, dunning, partial payment, and a tamper-evident audit log. Export in DATEV format.
Effect: The operator needs no second accounting stack, and their tax advisor gets what they expect. In sales this is the argument that triggers the switch — not the interface.

A recommendation you can recompute

Problem: An operator wants to know which vehicle to deal with next. A trained model would have an answer but no justification — and a recommendation whose reasoning isn't visible gets ignored in daily operations.
Decision: A priority formula stated in the open: impact in euros times confidence, divided by effort. Plus an evaluator that holds the prediction against the actual outcome afterwards and feeds confidence back.
Effect: The recommendation is explainable, and therefore actually used. And because prediction and outcome run against each other, it gets measurably better rather than merely more plausible.

What it cost

Each of these decisions has a downside. Leaving them out here would be the fastest way to make the case study untrustworthy.

Multi-tenancy rules out bespoke solutions
One shared codebase for all operators means nobody gets special treatment. That regularly costs deals in sales, and it is at the same time the only reason a single person can support over a hundred operators without operations collapsing.
Immutability is inconvenient day to day
A tamper-evident log means nothing is overwritten or deleted. A typo in an invoice is cancelled and re-booked, not corrected. Users initially experience that as a step backwards — it is the precondition for the export being worth anything at all.
The transparent formula is weaker than a model
An open formula captures fewer relationships than a trained model. The trade was deliberate: traceability over predictive power. In an operation where a human makes the call, explainability wins — a recommendation nobody understands doesn't get followed.

Where it stands

uRent has been in production since 2023. The platform carries over 1,000 vehicles from more than 150 operators; Fleet OS bundles 23 modules into one workspace and has been in piloted rollout with allocated seats since 05/2026. The cross-platform app for iOS and Android is published on the App Store.

More telling than the numbers is the operating state: the platform moves real money between third parties, produces records that hold up for tax purposes, and is used by businesses whose daily operations depend on it. Mistakes here are not cosmetic.

customer vehicles under management: 2,200+customer vehicles under management
registered business users: 400+registered business users
modules in one workspace: 23modules in one workspace
Google, 8 reviews: 5.0 ★Google, 8 reviews

Used

Frontend: TypeScript, React, Next.js (App Router), React Native, Tailwind CSS
Backend: Node.js, Python, REST APIs, webhooks, independently deployable microservices
Data: PostgreSQL, Supabase, Drizzle ORM, multi-tenancy, event-driven workflows, real-time
Payments: Stripe Connect, subscriptions, Stripe Tax, SEPA direct debit (pain.008), return debits
Compliance: GDPR, GoBD, DATEV EXTF, ZUGFeRD, XRechnung, audit logging
Telematics: OBD2 integrations with Webfleet, Samsara and Vimcar
Operations: Docker, GitHub Actions, CI/CD, Vercel, Azure, Sentry

What carries over into an engagement

For a project in rental, fleet or mobility I bring finished work rather than willingness:

Money moving between third parties — marketplace model, payouts, identity verification, return debits. Not "integrated Stripe", but operated in production.
German bookkeeping obligations a tax advisor actually accepts: GoBD, DATEV, ZUGFeRD, XRechnung, SEPA.
Multi-tenancy as a floor plan rather than a retrofit — including knowing what it costs you in sales.
Domain knowledge in rental: availability, handover records, deposits, damage handling, telematics data and which of it is actually needed.
Operating it, not just building it: rollout, monitoring, backups, and standing behind decisions three years later.