How scattered mobility administration became a free, local-first digital product.

Every ride leaves a paper trail.

Kilometres. Receipts. Maintenance. Reimbursements. Insurance documents. Costs that seemed insignificant until someone needs a monthly report or asks where the invoice went.

Most of it ends up scattered between calendars, spreadsheets, gloveboxes, emails and memory.

MoBud began with a simple question:

What would mobility administration look like if the user remained in control?

The starting point

MoBud began as a personal frustration

I regularly move between different forms of transport, each with its own costs, paperwork and practical realities. A bicycle commute is not registered in the same way as a motorcycle trip. A maintenance invoice is different from a fuel receipt. A private ride becomes something else when it needs to be reported to an employer or accountant. When you have mechanical failure, you just need the right documents available to make the call.

Existing solutions often covered one piece of the problem: a trip tracker, an expense app, a maintenance log or a fleet platform. What I needed was the layer connecting them.

One place to understand:

• which vehicle was used;

• where and why the trip happened;

• how many kilometres were travelled;

• what it cost;

• which documents belonged to it;

• and what the complete picture looked like over time.

The challenge was not simply to store more information.

It was to make mobility administration useful enough to return to, and light enough to use after an ordinary Tuesday commute.

Privacy as product architecture

Local-first by design

Mobility data is personal. It can reveal where someone lives, works and spends their time.

MoBud therefore works without an account or central customer database. Trips, addresses, costs and documents remain on the user’s own device. Backups can be stored locally or optionally in the user’s own Google Drive.

No advertising. No obligatory subscription. No business model. Privacy was not added later. It shaped the architecture.

Built around the ride

A commute should take seconds to register.

A monthly report still needs reliable data.

That tension shaped the product.

Quick registration keeps daily use simple. The calendar, garage and reports connect trips, vehicles, mileage, costs, receipts and maintenance into one clear system.

I built MoBud by combining product strategy, UX, visual design, data modelling and front-end development. AI-assisted coding shortened the distance between an idea and a working version, while every feature still had to earn its place.

Today, MoBud is an installable, multilingual PWA (progressive web application) for mobile, tablet and desktop. https://mobud.app/

Not a spreadsheet wearing an app costume.

A deliberate digital product built around one principle:

Useful technology should not ask for more than it gives.

MoBud currently combines:

• Trip registration

  Users can record dates, vehicles, routes, destinations, distances, purposes, stops and optional supporting documents.

  
  

• Costs and receipts

  Expenses can be linked to a vehicle, supplier, category, mileage and uploaded receipt. The interface also makes clear that a digital copy does not replace the legally required original document.

  
  

• Vehicle administration

  The garage brings together mileage, maintenance, repair contacts, insurance, roadside assistance, lease information, dealers and supporting documents per vehicle.

  
  

• Reports

  Monthly and yearly summaries make trips, costs, usage and vehicle information easier to interpret and export.

  
  

• Backup and portability

  Local and optional Google Drive backups allow information to be moved or restored without creating a central MoBud account.

  
  

---

The outcome

MoBud demonstrates the work I want to do more of.

Start with an ordinary human problem. Study the systems surrounding it. Connect business logic, data, design and technology. Then build enough of the answer to make the direction undeniable.

Not every useful product needs another subscription attached to it. Sometimes, it just needs to work.

My role:

Creative concept · Product strategy · Research · Brand direction · Competitive and product research · Naming and brand direction · UX/UI · User flows · Functional architecture · Data modelling · HTML, CSS and JavaScript · AI-assisted development · Testing · Content and documentation · Front-end development