When we started SMOVECITY in 2018, the application did one thing. It found you a shared electric bike. That was it — one mode, one operator, one city. The thesis from day one was that the same product could one day connect to every operator in every city we ran in, and then keep going past mobility into the rest of the trip. Eight years later, that's what v2 is.
This is a working note on what changed between v1 and v2 — the architectural calls, the operator integrations that took the longest, the design decisions I'd take back, and the ones I'd make twice.
What v1 actually was
For most of v1, SMOVECITY was a bike-share operator first and an application second. We built the connected hardware, ran the fleet, took the support calls, dealt with the city contracts. The app was a thin layer on top of an operational business. It worked because we controlled both sides of the stack — but it was the kind of thing that only scales linearly with how many bikes you put on the ground.
By 2024 it was obvious that the actual leverage was in being an aggregator, not an operator. The cities we served all had three or four good mobility products that simply didn't talk to each other. Tourists in particular were stuck juggling four apps in languages they didn't speak.
The integration layer is the product
The single biggest call we made for v2 was that the integration layer is not a back-end concern. It is the product. We don't sell bikes; we sell the fact that every bike, scooter, tram, bus, ride-hail, flight and hotel in a city is on the same map, with the same price, in the same conversation.
What that meant in practice:
- Every operator integration ships with a "live" badge. If the operator's feed goes down, we don't fall back to estimates — we hide the data. The badge stays honest.
- We pay no operator for placement. The order of results on the live map is by distance and price, with no commercial layer on top. The minute we put a paid layer in, the trust dies.
- The booking surface is the same component everywhere — chat, trip detail, AI response. One renderer, three contexts. This was hard to get right.
What took longest
Honestly? Public transit. Bikes and scooters are mostly on shared data specs at this point. Walk into a new city as a shared-mobility aggregator and you can be on the live map in a week. Public transit is the opposite — every city has its own conventions, its own feed quirks, its own version of "we have a published spec but the live data is on a different endpoint nobody documents."
Brussels (where we started) took nine working days. Lisbon took four. Tokyo took six weeks and we're still tightening the rail-station polygons. Don't believe anyone who tells you "we cover transit" without asking which cities. Coverage is per-city, and per-mode, and per-quality-tier.
What we got right
One thing I'm proud of: the AI surface was designed alongside the integration layer, not bolted on after. Most "AI travel assistants" you can try today are a thin wrapper around the same three booking APIs the website already uses. Ours sits on the same primary feeds the live map uses, which means the AI can answer "is the 51 tram on time" with the same data the next-arrival badge uses.
The booking section on the marketing site shows the result format — the cards aren't mockups, they're the real component the AI returns.
What I'd take back
We spent too long on the v1 onboarding flow before v2. We knew we were going to rip it apart but we kept patching it. By the time we sat down to redesign it cleanly we'd accumulated three years of edge cases that nobody wanted to revisit. Lesson: when the next version of a flow is funded and scoped, stop investing in the old one.
What's next
The 124th city is shipping this week (Porto). The next four cities — Madrid, Athens, Rotterdam and Helsinki — are in integration. We're hiring city-operations folks for each. And we're starting to think seriously about the next thing past travel: what does a SMOVECITY for the events feed look like when the operator data is two-way — when you can actually do things from inside the app, not just see them?
More on that next month.