Manecab — the admin system for small taxi operators

The problem: the binder, the paper slip and the spreadsheet

A taxi operator with a handful of cars rarely has trouble running the cars. What eats the evenings is everything around them: shifts reported on paper slips, receipts in a plastic sleeve, a spreadsheet somebody has been extending for four years, and a calendar reminder that is supposed to catch a permit before it expires.

That holds together right up until it doesn't. A slip goes missing. A receipt becomes unreadable. A date passes. And unlike a missed booking, that kind of miss only surfaces once it has already cost money — at year-end close, or during an inspection.

This is not primarily a technology problem. It is an administrative problem nobody has built good tools for, because the industry's software has spent its energy somewhere else.

Why not an existing taxi system

Dispatch and metering are solved problems. Established systems exist, they work, and a small operator does not need another one.

Day-to-day administration is not solved. It is still in the binder. So Manecab is deliberately not a dispatch system, not a booking centre, not an accounting bureau and not new hardware in the car — it handles the administration around what the operator already has.

What we built

Manecab is in production at app.manecab.se. The product site lists seventeen features across five areas, nine of which are modules the operator switches on and off depending on what it actually needs:

• Reporting and finance — shift reports, expenses and receipts, invoicing and customer register, bookkeeping exports, key figures and analysis.
• Vehicles and compliance — vehicles and maintenance, regulatory compliance, rest periods, equipment register, document vault.
• Staff and scheduling — scheduling, employment contracts and payslips, holiday and absence.
• Customers and pricing — online booking, price disclosures, pricing tools.
• Platform — roles, two-factor sign-in, GDPR, and routine operation inside the EU.

The way into all of it is the driver's phone. The driver reports the shift when it ends, and revenue, expenses and compliance land in one place instead of three.

The online booking module also runs in production outside the product itself: it sits as the booking form on a client's own website — see the NordWest Taxi case study.

The hard parts

The feature list says what the product does. What made it real engineering is that large parts of it are Swedish regulation turned into code — and regulation cannot be approximated.

• Invoicing on Swedish terms. Payment reference numbers, tax-status declarations and a Swish QR code on the invoice, with a customer register behind it. An invoice that is almost right is wrong.
• Employment contracts with two-step e-signing, against the statutory requirements for what an employee must be given in writing. Signing is not done with a national eID but as a simple electronic signature under eIDAS — signed while authenticated, with a SHA-256 checksum and an event log.
• Price disclosures under the transport regulator's rules. The product stores the evidence that the price information was actually given — at an inspection the burden of proof is what counts, not that a price existed somewhere.
• Rest-period limits that warn inside the schedule, not afterwards once the shift has already been driven.
• Reminders in three steps — 45, 14 and 1 day before a date. Three levels because one reminder is too few: the first gives time to act, the last catches whoever missed the other two. In total the product carries over 45 kinds of notification and reminder.
• Per-user bilingualism. The whole product exists in Swedish and English, each user picks their own, and notifications and email follow the user's language rather than the company's. Translating an interface is one thing; carrying the language choice all the way out into the outbound mail is another.
• Roles, two-factor sign-in, and routine operation inside the EU. An operator puts personal data about its employees in here. Access control and where the data sits are not afterthoughts.

What Manecab says about how we build

We sell web applications on the argument that a process which has outgrown the spreadsheet needs real data integrity, real access control and real traceability. Manecab is that sentence built in production, by us, with ourselves as the first demanding customer.

Concretely it is the same work an engagement with you would be: map a business that already functions, draw hard boundaries, design the interface around the person who will actually use it — here a driver standing by the car with one hand free — and then keep running it once it is out.

The difference from a client case is worth saying plainly: here we were both the client and the supplier. That makes Manecab strong evidence of what we can build, and weaker evidence of what it is like to be our customer. For that, see the NordWest Taxi case study, where somebody else set the scope, the budget and the date.

Where Manecab stands today

The product is built, deployed and open to new accounts. A new account gets full functionality for 14 days from approval, with no card required.

Pricing is per vehicle and not yet fixed — it is being set together with the first pilot customers.

What you will not find here is customer figures: how many operators, fleet sizes, or what anyone saves in time. That is a deliberate choice, not a gap. We describe what is built and what it does — our customers' numbers are theirs, not our marketing copy. Whether it holds up for your business is a question we would rather take in a conversation than in a headline.

To see the product, it is at manecab.se.