ArendaOS: car-rental management software you can open and check
Every other case study on this site is anonymised. This one is not. ArendaOS is car-rental and fleet management software Yarvixo designed, built and shipped as a multi-tenant B2B subscription product — twelve modules, seven roles, PDF contracts, encrypted personal data, and booking conflicts made impossible by the database rather than by a validation rule. It is live in Russian at arendaos.com, and you do not have to take our word for any of it.
Two different reasons to be on this page. If you run a rental fleet and what you need is working software, the product is at arendaos.com — go there, not here. If you need a system like this built for your own market, that is what the rest of this page is about, decision by decision.
Why this one is named
A portfolio claim a reader cannot check is worth about as much as no claim at all.
Client work on this site is published without the client's name, because permission to name them has not been given. That is honest, and it is also weak evidence: an anonymised case study asks you to trust a description of a system you can never look at. ArendaOS is our own product, so there is nobody to ask. The name, the domain, the feature list, the twelve capability pages, the glossary, the blog and the legal operator details are all published, and every architectural claim below can be checked against the running application.
The site is in Russian and serves Belarus and Russia. If you do not read Russian, the machine-readable summary at arendaos.com/llms.txt is the fastest route in, and it is worth reading for a second reason: it publishes what the product does not do, which is the part of a vendor page that is usually missing.
The picture behind the title is a rendering of the dashboard, not a capture of one. ArendaOS sits behind a login and there is no self-serve demo, and a real screen carries renters' names, plate numbers and what each of them owes — none of which belongs on a public page. So the header is the product's own dashboard rebuilt from its live markup and translated into English, with invented rows: the same layout, palette and charts, and not one real customer, car or sum of money. The figures on it are illustrative and this page claims nothing from them.
Open arendaos.com → · SaaS development · What a build like this costs
Project snapshot
A multi-tenant subscription product, taken from an empty repository to a deployed system with its own public marketing surface.
The market: rental fleets from seven cars up
Car-rental and fleet-rental operators from roughly seven vehicles up — the point at which deposits, debts, fines, maintenance and paperwork stop fitting in a spreadsheet and a group chat. Belarus first, then Russia.
Delivery scope
Product design, full-stack build, background workers, PDF generation, the public marketing site, the SEO layer, deployment and the post-launch hardening pass — all of it, not a slice of it.
Shipped state
Twelve product modules, seven roles, four notification channels, PDF contracts and acts, Excel import and export, tiered subscriptions, an audit journal and a platform super-admin console — deployed and running.
Why rental operations break a generic CRM
Rental operations are not a CRM problem. The hard parts are money, custody and evidence — and all three arrive at once.
Why a double booking is a data problem
A double booking is not a bad user experience, it is a customer standing in a car park. Catching it in application code means catching it in every code path that ever writes a rental — including the import, the admin console and whatever gets added next year.
Deposits, debts and fines in one ledger
Prepayments, recurring rent, deposits held and released, debts, traffic fines rebilled to the driver, refunds. Six money shapes, each with a different owner and a different moment of truth, and an operator who cannot answer “who owes what today” is losing money silently. All six are stored as integers in minor units — whole kopecks, never a float — across the three currencies the product carries, because a rounding drift discovered during a deposit reconciliation is already wrong in the ledger, in a signed PDF and in the customer’s memory.
Personal data and damage disputes
The system holds identity documents and driving licences by necessity, and it has to survive a damage dispute months later. That makes personal-data protection and a tamper-evident record of who changed what into architecture, not features.
What we built into the rental system
The decisions worth naming, rather than the full module list — that lives on the product site.
How double bookings are prevented
Overlapping rentals for one vehicle are blocked by a PostgreSQL exclusion constraint, so the conflict cannot be written at all — not by the API, not by the importer, not by a future endpoint nobody has written yet. The product states “zero double bookings” as an absolute because it is enforced, not intended.
Multi-tenant from the first migration
Tenant isolation was in the schema before the first feature, because retrofitting it into a product that already has customers means touching every query and trusting that you found them all. Seven roles with per-section permissions sit on top, configured by the fleet owner rather than by support.
Documents and jobs off the request path
Contracts, acts and addendums render to PDF through headless Chromium, and both PDF and Excel work runs as background jobs on Redis and BullMQ. A fifty-vehicle export therefore cannot hold a web request open or time out behind a proxy.
Personal data encrypted at rest
Passport numbers, driving licences, phones and e-mail addresses are encrypted with AES-256-GCM, and the product is designed against Belarusian Law No. 99-З and Russian Federal Law No. 152-ФЗ. Analytics is confined to public pages and never loads inside the application.
Evidence at handover and return
Checklist, damage diagram, photographs, a signature captured on the customer's own phone, and a before/after comparison. This is the module that decides who pays for a scratch, so it was built to produce a record that holds up rather than a form that gets filled in.
A way in, and a way out
Excel import so an operator can arrive with the spreadsheet they already keep, and a full export of their own data at any time. Notifications reach them in-app, on Telegram, by e-mail and by SMS — four channels because a fleet owner is rarely at a desk.
What car rental software has to cover
The twelve modules a fleet operator gets, one line each. Every one of these ships full-stack and multi-tenant — there is no module that exists as a screen with no data behind it.
Fleet and status — the state of every vehicle in real time: free, out on rent, in service, off the road.
Calendar and bookings — the schedule for the whole fleet, with overlapping reservations refused at the database level.
Rentals — one record per deal, tying together the customer, the vehicle, the money, the documents and the photographs.
Customers, drivers and companies — history, risk notes and a blacklist, for individuals and corporate lessees alike.
Handover and return — checklist, damage diagram, photographs, a signature taken on the customer's phone, and a before/after comparison.
Documents — contracts, acts and addendums generated as PDFs from templates, rendered by headless Chromium.
Payments and deposits — prepayments, recurring schedules, deposits held and released, debts, refunds.
Fines — traffic penalties recorded against the rental that incurred them and rebilled to the driver.
Cash register — cash flow across accounts, so the ledger reflects money that actually moved.
Maintenance, repairs and insurance — costs per vehicle and reminders before a deadline rather than after it.
Dashboard and reports — profit per vehicle, fleet utilisation, outstanding debt.
Notifications — in-app, Telegram, e-mail and SMS, because a fleet owner is rarely at a desk.
Every module in detail, on the product site → · the build, decision by decision
The tech stack behind a car rental SaaS, and why each piece
Not a logo wall. Six choices, each with the reason it was made.
NestJS + TypeScript API
A modular monolith rather than services. At this size, microservices buy distributed-systems problems and no delivery speed; module boundaries inside one deployable give the same separation with none of the operational cost.
PostgreSQL + Prisma
Chosen for what the schema can be made to guarantee — exclusion constraints, transactional integrity across money and documents — not for the ORM. The database is where the invariants live.
Next.js, mobile-web first
The handover happens in a car park on a phone, not at a desk. A responsive web app that works on whatever device is in someone's hand beat a native app that would have to be installed before the first rental.
Redis + BullMQ
PDF rendering and Excel export run as jobs, off the request path. A fifty-vehicle export must not be able to hold a web request open or die behind a proxy timeout.
S3-compatible object storage
Damage photographs are the evidence in a dispute and grow without limit. They belong in object storage with lifecycle rules, not in the database next to the rows they support.
JWT + Argon2, TOTP second factor
Refresh tokens rotate within a family, so a stolen token dies the moment the real browser refreshes. Two-factor authentication is available to operators and owners, and the TOTP implementation is pinned against the official RFC test vectors.
What it connects to, and what it deliberately does not do
The second half of this list is the part a vendor page usually leaves out. All of it is published on the product's own site, which is why it can be repeated here.
What it connects to. Notifications leave the system over Telegram, e-mail and SMS as well as in-app, because a fleet owner is rarely at a desk. Excel comes in and goes out, so an operator can arrive with the spreadsheet they already keep and leave with their own data whenever they want it. Damage photographs and generated files sit in S3-compatible object storage, and contracts, acts and addendums render to PDF from templates rather than being assembled by hand.
What it does not do, on purpose. It does not read GPS trackers and does not show a vehicle on a map. It does not pull requests out of rental aggregators — a booking from a listing site is still entered by a human. It does not issue payment links or take card payments from renters; the money modules record money that moved somewhere else. There is no separate portal where a car's owner logs in to watch their own statistics, no native app in either store, and no self-serve demo environment — the team shows it on request. And liability for damage is assigned by a person rather than inferred by the software, which is the honest design for a decision that ends with somebody paying.
Every one of those is a scoping decision with a reason behind it, not a hole in the build. Two of them — telematics and acquiring — are the integrations a client in another market usually wants first, and they are the reason an integration count moves a quote more than a feature count does.
How a rental SaaS gets built, layer by layer
The build ran in layers, each one shipped full-stack before the next started — no half-finished tier waiting on a later one to become usable.
Tenancy and identity first
Organisations, users, roles and the audit journal before any product feature, so nothing downstream had to be re-plumbed once real data existed.
The rental as the central aggregate
Fleet, calendar and rentals built as one contour rather than three screens, because the questions an owner asks cross all three at once.
Money and documents together
Payments, deposits, debts and fines shipped alongside the PDF contracts and acts that reference them, so the paperwork and the ledger could not drift apart.
Operations and reporting
Maintenance, repairs, insurance and reminders, then the dashboard and per-vehicle profitability — the reports last, once the data feeding them was real.
Hardening pass
A security review worked top to bottom: encryption at rest, session and refresh-token handling, two-factor authentication for operators, dependency scanning, backups and restore.
Public surface and go-to-market
The marketing site, twelve capability pages, a glossary, a blog and the SEO and analytics layer — built in the same repository, under the same review, as the product.
How much does it cost to build car rental software?
The published answer, before you ask for one.
A rental or fleet management platform with a real multi-tenant surface runs $40,000–$90,000 and ships in 8–12 weeks: fleet and status, the booking calendar, the rental record, customers, the money model, generated documents, roles and deployment — a product an operator can run their working week on.
What pushes delivery to 14–20 weeks is rarely the screen count. It is the number of external systems and the depth of the money model. Card acquiring, an accounting sync, an aggregator feed and telematics are four separate integrations, each with its own authentication, rate limits and undocumented behaviour. Deposits held and partially released, and fines that arrive months after the rental closed, are the other half: a ledger that has to stay true through a dispute costs more than a payments screen.
An off-the-shelf rental platform charges a monthly subscription and is the right answer for most operators. Building becomes the cheaper option at the point where the software is the thing you sell rather than the thing you use, or where the workflow the business actually runs cannot be expressed inside somebody else's product. If neither is true yet, buy.
Every band we publish · what inflates a quote · SaaS development
The same architecture in equipment, property and plant hire
The vertical changes the vocabulary. Custody, deposits, evidence and per-asset profitability are one problem underneath — the part that does not transfer is the paperwork, and that is template work rather than architecture.
Equipment and tool hire
The whole job is custody: what went out, in what condition, against what deposit, and who pays for the damage. The rental record, the handover evidence and the deposit ledger carry over unchanged. What changes is rates by hour as well as by day, consumables billed on top, and serial numbers where registration plates were.
Property and short lets
Overlapping bookings are the same impossibility, and the same constraint refuses them. Deposits withheld in part, an inventory at check-in and check-out, and utilities rebilled after the stay all sit in the money model as it stands. What changes is that the asset does not move, so handover evidence becomes an inventory rather than a walk-around.
Plant, machinery and trailers
Profit per asset, maintenance intervals and insurance deadlines are the reports an owner already asks for, and they are the ones this build ends on. What changes is servicing measured in engine hours rather than kilometres, plus certification and operator licensing as data the system has to hold and check before a handover.
Outcome and what it evidences
No revenue figures, no customer count, no uptime percentage. The product is early, and inventing those numbers would cost this page the one thing it is for.
A finished product, not a prototype
Every module ships full-stack and multi-tenant, with background jobs, observability, backups and end-to-end tests behind it. The difference between a demo and a system somebody's business depends on is exactly that list.
Compliance treated as architecture
Encryption at rest, tenant isolation, an audit journal and a full data export were designed in, not bolted on after a customer asked. The overlap between GDPR and the Belarusian and Russian statutes is not total, but the engineering they ask for is: data minimised, personal data protected at rest, access recorded, and a subject's data producible and deletable on request. The export exists because of that last one.
Proof you can inspect
The product, its documentation, its capability pages and its published limits are all open at arendaos.com. For a buyer evaluating a delivery partner, one checkable project outranks three descriptions.
Common questions
About the product, and about having something like it built.
Want the same thing built for your market?
Bring the operational problem, not a feature list. We will map the modules, name the parts that have to be enforced rather than validated, and put a scope and a fixed price in writing within 48 hours.
Message received
We’ll review your enquiry and respond within one business day.