Yes, the title is correct. This is really what happened to me, and today I'm going to write about this unusual experience and how my career as a software engineer led me to this simple solution.
1. Preface & Context
A few years ago - December 2022, to be more precise - I called a cab using a transportation service like Uber. It was around 10:00 p.m., not too early and not too late. Maybe it was because of the season, but getting a confirmation from the app was taking it's time.
The taxi arrived after approximately 30 minutes. When it did, everything seemed normal. The vehicle was relatively new, without dents, and the interior was clean. The driver seemed kind, too. Everything seemed normal. Little did I know that this would be the start of an experience I wouldn't wish on anyone.
1.1. Llegar a Casa - a web application
While talking with a good friend about my experience, he mentioned that one of his friends had gone through something similar while using another service. It was far more common than we thought. He mentioned how cool it would be to have an app that let you review drivers by license plate. I agreed, and we discussed how it could prevent people from riding in that vehicle, potentially saving their lives.
In my opinion, this idea had one major issue: to be helpful, the app needed a large user base. Let's be honest: most of our apps have fewer than 100 users, so this was a huge deal-breaker.
In the nights that followed, I couldn't shake the urge to build an app that could verify the transportation people were about to use. That's when I thought: what if data about these incidents was public and available to use? That's how the first idea, "Llegar a Casa," was born. If I made a website that let users check a vehicle's information before riding the vehicle, they could help prevent cases like this.
It took me around a week to figure out how to access the public data, design the website, and create a system to handle requests. I was excited, and I built the project with love: micro-services, caching, rate limiting, a database, cron jobs, and more. I was over-engineering a simple solution for the love of learning.
I was proud of the solution. Everything worked great locally. I even built a landing page! Then it was time to deploy the app to the cloud and make it available to everyone. Once it was deployed, I immediately grabbed my phone and tried to make my first request. I typed in the license plate and clicked. Error.
Looking at the logs, the error was crystal clear. The data sources were blocked because of a geolocation issue. When I developed the application, I tested it directly from my laptop, never in the cloud (a rookie mistake). That meant my requests used my real IP address, which worked fine. But once the app was in the cloud, its requests came from a foreign IP address, triggering Incapsula's protection. I decided I didn't want to spend more time or resources on the project, so I left it open source and let it slowly fade away.
2. Building and distributing Takya
It's 2026, and Ecuador is facing record levels of violence. In 2025, the country recorded 9,216 intentional homicides, about 32% more than in 2024 and the highest annual total on record (Primicias). Similar incidents have happened to people I know, and they seem to be happening more often. One night, while thinking about how to solve the problem that stopped the web version from accessing public records, I had an idea: what if the app made those requests directly from the user's phone? That would remove the backend server between the app and the public data sources.
2.1. Simplicity is better
Over the years, I've learned that a simpler solution is often the better one. Takya's core job was to request information from public data sources, so I asked myself: did it really need a complex backend?
I'm not a mobile developer, but I have several years of experience building production applications with React. That experience helped me choose a practical way to test my idea: could users retrieve the information if their phones made the requests directly? I developed and tested Takya on an iPhone 12 and a Samsung A17.
I chose React Native and Expo, which let me build for multiple platforms from one codebase. This attempt felt very different from the first one. AI tools are now part of my development workflow, and they helped me build a minimum viable product (MVP)—an early version with the essential features—quickly.
I started with a flowchart of the user journey, then used Cursor and Codex to help build the app. I provided the URLs of the public data sources and asked Codex to retrieve information from them. Seeing it work on my phone was a great moment.
AI made it possible to get to a working version quickly, but I still guided the work and made the key engineering decisions. I organized the project, designed its components, created reusable hooks to share logic, and tested the app at both the unit and end-to-end levels. The tools accelerated implementation; I was still responsible for deciding what to build and making sure it worked.
Once the core flow worked, I added a couple of safeguards. SQLite caching stores recent results on the device, so the app can reuse them instead of requesting the same information again. I also added a rate limiter to control how frequently searches send requests and reduce unnecessary load on the public data sources. After several days of testing, the app was ready to prepare for release.
2.2. Publishing Takya
With development and testing complete, I turned to preparing Takya for the App Store and Google Play. Before setting up developer accounts, I also wanted to present Takya as a complete product rather than just a side project.
First, I built the marketing website with plain HTML, CSS, and JavaScript, then deployed it using Cloudflare Workers. I also prepared a privacy policy and a support channel for people using the app. Then I made promotional materials with HTML, CSS, and Codex. Building them this way made it easy to adjust the designs.
With the app and promotional materials ready, I created developer accounts for Apple's App Store Connect and Google Play Console. This was the most tedious part of the process. Both platforms require developer registration before you can submit an app for review.
The App Store submission was quick and straightforward. Google Play required more steps: before the app could be released, I had to complete a 14-day closed test with at least 12 testers. At the time of writing, that process was still underway, so the Android version wasn't available yet.
3. The outcome
Up until today, Takya has no more than 10 users - most of them friends or relatives. Despite of this, I feel satisfied with the outcome. It was my first mobile application and was a joy to develop after failing a few years ago.
Nowadays, it is easier than ever to create application - either mobile, web, desktop or whatever - why not try to contribute a bit to our society in some way? Ten users may not be a lot but it is at least important for me as they are family and friends.
I'm looking forward to keep improving the application and develop some others I have in mind! I do have some old projects that would benefit for the mobile format. Thank you for taking the time to read the blog, I hope you enjoyed this short journey.
3.1. Contribution
Takya is open-source, you can read the source code and contribute to the project in Github. I would like to expand to neighbor countries on the future!
Top comments (0)