Dan Petrescu
Bike sharing — the Citylink MVP

Bike sharing — the Citylink MVP

Citylink started as a bike-sharing MVP: the cheapest possible way to prove people would unlock a shared vehicle with a phone.

MVP

bikes before cars

Bluetooth

unlock mechanism that carried over

1

platform it grew into: Citylink car sharing

Context

Citylink, the car-sharing platform, did not start with cars. It started as a bike-sharing MVP — the smallest version of the same idea: a shared vehicle, a phone, a lock, and a stranger you have never met.

That sequencing was deliberate. Every hard problem in car sharing exists in bike sharing in miniature — identity, access, telemetry, disputes, theft — at a fraction of the asset cost. A mistake with a bike is an expense. The same mistake with a car is a write-off.

Constraint

An MVP only earns its name if it is cheap and fast, so the temptation is to build it as a throwaway and start again for cars. The risk cuts the other way: the lock mechanism, the unlock flow and the backend session logic are exactly the parts you will need at car scale, and rebuilding them from scratch throws away the only things the bikes actually proved.

Bikes also have the harsher connectivity problem. They live outside, move constantly, and end up exactly where signal is worst — basements, courtyards, dead zones between buildings.

Decision

We rejected the throwaway-MVP framing. The bike system was built as the first slice of the vehicle platform, not a demo of one — same unlock architecture, same backend model, same session logic, with the bike as the cheapest vehicle that could prove them.

We chose Bluetooth unlock for the same reason it later won for cars: it works without signal, and a customer standing next to a vehicle they paid for cannot be told to walk somewhere with better coverage.

We rejected bikes-as-the-business. The unit economics of bike sharing in this market did not support a standalone company, and we knew that going in. The bikes were paid learning: the cheapest way to find out where people abandon the flow, where locks fail, and what support actually gets asked.

What shipped

A bike-sharing MVP with phone-based Bluetooth unlock and the backend that would later run Citylink's car-sharing fleet. The unlock mechanism, the audit trail pattern and the session model carried directly from bikes to cars.

Numbers

One MVP that proved the unlock flow and the operational model, then became the foundation for Citylink car sharing — where the same architecture now controls assets worth tens of thousands of euros each.

What I'd do differently

I would have put a public date on the MVP decision. Running the pilot without a written 'we decide by this date, on these numbers' line lets an experiment drift into being maintained, and maintained is not the same as validated.

I would also have instrumented the physical side from day one — lock failures, battery levels, recovery runs. We measured the app carefully and the hardware by anecdote for longer than I like to admit.

Want this for your product?

Fixed-price scope in the first call. No discovery phase invoice.