Paparcar: where did you park

Paparcar makes parking and driving more effortless: it detects your trips, remembers where you parked, helps drivers discover and share parking spots, and turns driving data into useful statistics.

Comment

Project Story — Paparcar

Inspiration

Paparcar started with a very simple thought.

Back in 2019, I was sitting on a bench with a friend when I saw a driver slowly going around the streets looking for a parking spot.

I remember thinking:

“I saw an empty spot on the next street, but of course, the driver has no way of knowing it is there until they pass by.”

That was the moment Paparcar was born.

At the time, I knew almost nothing about programming. I did not have a technical background, I had never built a mobile application, and I had no idea how difficult the problem would become.

A few months later, after becoming unemployed and being tired of working on things I did not enjoy, I decided to give that idea a shape.

I was very naive at first. I thought it would be a matter of watching some YouTube videos, learning Java and Kotlin, and building an Android app.

It did not take long to realize how wrong I was.

The more I learned, the bigger the project became. I understood that I was trying to build the house starting from the roof, so I stepped back and decided to learn properly.

I followed Google's official Android courses, joined developer communities, learned from Android developers and creators, and met people who ended up becoming an important part of my journey.

Some of those people are still part of my life today. Over time, several developers and I built a small community where we collaborate on different projects, production applications and different areas of software development.

Paparcar became much more than an app idea.

It became one of the reasons why I decided to become a software developer.

There were also long pauses.

I did not have unlimited time or financial freedom. I had to work on jobs I did not enjoy just to pay for everyday life, and sometimes the project had to be put aside.

But I never completely stopped.

Even after work, I would come home and continue programming.

After around two years of learning and building, I realized that I could eventually try to make software development my profession while continuing to work on Paparcar on the side.

In 2024, I managed to create an early version of the application. It worked, but it was still very basic and far from what I imagined.

So I put it aside again.

Instead of forcing the project forward, I focused on becoming a better engineer.

In 2025, I completed advanced training in software architecture and started actively looking for professional opportunities. After several technical interviews, I finally got the opportunity I had been working towards: a professional Android development role where I could continue growing and proving what I had learned.

Then, in February 2026, I came back to Paparcar.

This time, I decided not to continue the old codebase.

I started again from zero, with a much clearer understanding of software architecture, maintainability, product design and, most importantly, the problem I actually wanted to solve.

And this time, I also had something that did not exist when the idea began in 2019: modern AI and LLM tools.

They became part of my development process, helping me research, debug, iterate and explore ideas faster. But the product decisions, engineering, architecture and especially the real-world testing still required a huge amount of hands-on work.

Today, Paparcar is finally becoming the product I imagined years ago.

What it does

Paparcar is designed to make driving and parking more effortless.

Its core feature is automatic parking detection.

Instead of asking the driver to manually remember where they parked, Paparcar combines signals and sensors available on the device to detect trips and identify when a vehicle has finished driving and has been parked.

When the driver leaves the vehicle, the parking spot can then become useful information for the community.

How to start: mark your car once. For automatic detection to work, Paparcar needs to know where your car is the first time. After adding your vehicle, tap "Mark parking", drag the map to where the car is and confirm with "Park here". From that moment on, Paparcar watches the car on its own: when you drive off it detects the departure and frees the spot, and when you park again it saves the new location with no taps (if it is not sure, it simply asks "Did you park?"). Linking the car's Bluetooth makes detection even more reliable.

The experience can be summarized as:

Drive → Park → Remember → Leave → Give the spot back to the community.

But the original parking problem has evolved into something much bigger.

Because Paparcar can understand driving and parking activity, it can transform that information into useful statistics, estimations and insights about the driver's own habits.

These include:

  • Estimated fuel consumption and spending.
  • Approximate CO₂ emissions.
  • Kilometres travelled.
  • Weekly, monthly and yearly driving and fuel estimations.
  • Average trip duration.
  • Time spent looking for parking.
  • Usual parking locations.
  • Most common days and peak hours.
  • Automatically detected parking sessions.
  • Parking spots given back to the community.
  • Historical driving and parking information.
  • Other personalized statistics and estimations derived from the user's own activity.

Paparcar also includes:

  • Community-reported available parking spots.
  • Public parking information, including free and paid parking where data is available.
  • Fuel stations.
  • Fuel prices in supported countries.
  • Multiple vehicle management.
  • Vehicle sharing, allowing other people to access the location of a shared vehicle.
  • A map that combines parking-related information with useful driving resources.

The important part is that these features are connected.

Paparcar is not just a map, not just a parking reminder and not just a statistics dashboard.

The automatic detection system is the foundation that connects them.

The long-term vision is simple:

Every time someone parks and eventually leaves, that parking session can become useful information for the next driver.

How we built it

Paparcar has been rebuilt several times as my technical knowledge evolved.

The current version uses a modern Kotlin Multiplatform (KMP) architecture, allowing the project to share core logic across platforms while keeping platform-specific integrations where they make sense.

The project is organized around clear domain, data and presentation responsibilities, with a strong focus on maintainability, separation of concerns and testability.

On Android, the automatic parking detection system combines multiple signals rather than depending on a single sensor.

Bluetooth, GPS/location data and Android Activity Recognition are used together to understand whether the user is driving, arriving, stopping or leaving the vehicle.

The application uses Kotlin coroutines, Flow, StateFlow and a unidirectional state approach for reactive state management.

Local persistence is handled through a multiplatform database, while Firebase is used for authentication and cloud data.

The system also has to work under real mobile constraints: background execution, battery consumption, delayed events, GPS inaccuracies, Bluetooth state changes and operating-system restrictions.

One of the main architectural decisions was to treat automatic detection as a core system rather than just a feature attached to a UI.

That meant building a pipeline capable of receiving imperfect signals, storing intermediate information, correlating events and deciding whether a real parking session had occurred.

AI and LLMs also became part of the process during the latest rebuild.

They helped accelerate research, debugging, code exploration and iteration, but they were not a replacement for engineering judgment or real-world testing.

The application had to be tested with physical devices and actual journeys because a large part of its most important behaviour simply cannot be validated from a desk.

Monetization with RevenueCat

Paparcar's philosophy is product first: the core experience (automatic parking detection, remembering where you parked and giving the spot back to the community) stays free. There is no hard paywall and no hidden buttons.

On top of that we introduced Paparcar Plus, an optional subscription built with RevenueCat on top of Google Play Billing:

  • Monthly: €1.99 / month
  • Yearly: €13.99 / year (roughly 7 months' price, ~41% off)
  • 7-day free trial for new subscribers on both plans

Free keeps the last 7 days of history, one car and two zones, and looking (spots, car parks, fuel prices) is always free. Plus unlocks your full history and statistics, routes saved in your account, alerts for spots in your zones and for fuel prices, a monthly recap, unlimited zones, all your cars (also in the widget) and a shared car for up to five drivers.

How it is wired:

  • A single RevenueCat entitlement (plus) represents the capability, decoupled from the store SKUs so the same entitlement can be shared with the iOS app later.
  • A default offering with monthly and annual packages mapped to the Google Play base plans.
  • A subscription repository wraps the RevenueCat SDK and exposes the entitlement state as a reactive Flow, injected with Koin and consumed by the ViewModels exactly like any other app state (location, detection, etc.).
  • RevenueCat is the single source of truth for subscription status: we do not duplicate expiration dates in Firestore or any custom backend. Google Play real-time developer notifications are connected so status changes propagate automatically.
  • The paywall is contextual: it appears when the user tries a Plus action (for example, looking further back in their history), and there is a visible but unobtrusive Plus section in Settings.

The full purchase flow (trial → entitlement active → Plus features unlocked in the app) has been validated end to end.

Challenges we ran into

The biggest challenge became the heart of Paparcar:

How do you know that someone has actually parked without asking them?

Detecting that a person is travelling is one thing.

Reliably detecting the exact moment when a vehicle has stopped being a journey and has become a parking session is much harder.

Real-world conditions are messy.

A user can:

  • Stop at a traffic light.
  • Get stuck in traffic.
  • Wait outside a shop.
  • Lose GPS accuracy.
  • Disconnect from Bluetooth.
  • Walk away from the vehicle temporarily.
  • Receive Activity Recognition events late.
  • Experience sensor or location data that does not match the expected sequence.

A false positive can be annoying.

A false negative can completely break the main experience.

Approximately 70% of the development effort of Paparcar has gone into the automatic parking detection system.

And debugging it has been one of the strangest engineering challenges I have faced.

Many of the problems could only be reproduced while actually driving.

You cannot simply place a breakpoint on a road and wait for the next bug to happen.

We had to repeatedly perform real journeys, inspect timestamps and sensor events, analyze edge cases, change thresholds and combine different signals until the system became more robust.

There was also another unusual challenge: the feedback loop is slow.

A UI bug can often be fixed in seconds.

A parking-detection bug might require:

Change code → build → install → drive → park → leave → wait → inspect logs → understand what happened → repeat.

And sometimes the bug only appears under a very specific combination of location accuracy, Bluetooth behaviour, movement patterns and event timing.

Battery usage and Android background-execution restrictions added another layer of complexity.

The system is still something we continuously improve, but reaching a point where Paparcar can automatically detect parking sessions in real-world conditions has been one of the biggest milestones of the project.

Accomplishments that we're proud of

The biggest accomplishment is not a framework, an API or a particular architectural decision.

It is that an idea that started in 2019, when I did not know how to program, has finally become a real product.

There were years of learning, pauses, financial limitations and moments when I genuinely thought I might never finish it.

In 2024, I managed to create an early version, but it was still too basic.

In 2025, I focused on improving my engineering skills, especially software architecture, and eventually made the transition into professional software development.

Then, in February 2026, I returned to Paparcar and decided to rebuild it from zero.

This time, I had the knowledge to understand what I was building instead of simply trying to make the idea work.

I could think about architecture, maintainability, testing, scalability and product design from the beginning.

And that changed everything.

Today, Paparcar includes:

  • Automatic parking detection.
  • Community parking.
  • Public parking information.
  • Vehicle management and sharing.
  • Fuel stations, with fuel prices in supported countries.
  • Historical data.
  • Driving and parking statistics.
  • Advanced estimations and personalized insights.
  • A multiplatform architecture.

Most of it has been built by me, with support from one teammate and the developer community that has accompanied me throughout the journey.

But there is another accomplishment that matters even more to me.

Paparcar has been with me for years.

It survived periods when I had almost no time, periods when I had financial difficulties, periods when I had to work on things unrelated to software, and periods when I had to stop development completely.

I kept coming back to it.

So today, seeing a real application running and knowing that the automatic parking system actually works in the real world is deeply personal.

I did not start Paparcar as a developer.

I became a developer partly because I wanted to build Paparcar.

For years, I thought that perhaps I would never build the thing I had imagined on that bench in 2019.

Now I have.

And that is probably the accomplishment I am most proud of.

What we learned

The first lesson was that software projects rarely develop in the order you imagine when you start them.

I began with a simple product idea, but turning it into reality required learning Android development, Kotlin, architecture, databases, networking, testing, background processing, location, sensors, cloud services, product design and eventually multiplatform development.

I also learned that complex problems are solved through iteration.

The automatic parking system did not magically work after the first implementation.

It required hundreds of small decisions, failed experiments, real-world tests and constant adjustments.

We learned that combining multiple signals can provide a much richer understanding of context than relying on a single sensor.

We also learned that real-world software behaves differently from software that only works in controlled environments.

A system can look perfect in logs and still behave incorrectly when a real person drives through a city, loses GPS for a few seconds, disconnects Bluetooth, stops in traffic and parks several minutes later.

Another important lesson was that architecture matters most when a project becomes complex.

Paparcar has evolved far beyond its original scope, and the ability to change parts of the system without rewriting everything became essential.

And perhaps the most important lesson was that technology itself is not the goal.

It is easy to become excited about sensors, maps, AI, Kotlin Multiplatform or architecture.

But at the end of the day, the question that matters is much simpler:

Does Paparcar make parking easier for the person using it?

That question has guided the project much more than any particular technology.

What's next for Paparcar: Where can I park?

The original question behind Paparcar was:

“Where did you park?”

And the answer became:

“Paparcar remembers.”

But that is only the first half of the vision.

The next question is:

“Where can I park?”

And that is where Paparcar is heading next.

The goal is to evolve from an application that remembers your parking spot into a system that can help drivers understand where parking may be available around them.

When a Paparcar user leaves a parking spot, that information can be released back into the community.

One user's departure can become another driver's opportunity.

This creates a network effect:

Someone parks → Paparcar remembers → They leave → The spot becomes information → Another driver can discover it.

But this also introduces our biggest challenge going forward:

We need people to use Paparcar.

Community-driven parking data only becomes really valuable when enough drivers participate.

We are at the very beginning of that journey.

Our next steps are to:

  • Improve automatic parking detection using more real-world data.
  • Expand parking information and coverage.
  • Continue developing the multiplatform experience.
  • Improve vehicle statistics, estimations and insights.
  • Expand fuel information where reliable data is available.
  • Grow the community of drivers contributing parking information.
  • Turn individual parking sessions into a useful collective network.

The final goal is not to build another map.

It is to build a system where every driver can benefit from what other drivers have already experienced.

The original idea came from watching one person drive around looking for a parking space.

Seven years later, the idea is still the same — but now there is a real product trying to solve it.

Where did you park? Paparcar remembers.

Where can I park? Paparcar knows.

Built With

Share this project:

Updates

Submission history