🚀 From 7 Years at EPAM to Building My Own iOS Navigation App

Yesterday marked the end of an incredible 7-year journey at EPAM Systems. I’ll miss my colleagues, the challenges we solved together, and, of course, our Berlin office at Kurfürstendamm.

The last three months have been nothing short of a rollercoaster. Instead of slowing down and reflecting, I dove headfirst back into something that has always fascinated me: iOS native app development.

This isn’t new territory for me. Back when the App Store first launched, I built and sold several apps, even one called iBiertje, a student-focused app to find the cheapest beer deals. Those were the early days, when even a small app could reach thousands of downloads.

But this time, I wanted to tackle something bigger. A project that combined my passion for mobility, technology, and real-life usability. The result? Urban Rider, the first dedicated navigation app for scooters, mopeds, and brommers.

---

🌍 Why Build a Scooter Navigation App?

If you’ve ever tried using Google Maps or Apple Maps on a scooter, you know the struggle. Standard navigation apps push riders onto highways or major roads, places where scooters simply don’t belong. Setting routes to “bike mode” or “avoid highways” isn’t enough, because avoid still isn’t the same as never.

On top of that, cities like Berlin and Nürnberg are filled with cobblestone streets, which are frustrating on two wheels. Riders want to avoid them, but existing navigation apps don’t give that level of control.

For years, I saw people on Reddit asking for a true scooter navigation app, but no one built it. This summer, after buying my own scooter, I decided to step up and make it happen.

---

💻 From Idea to App Store

What started as a simple experiment quickly grew into the biggest project of my career. I handled everything:

• Design & UX – clean, rider-focused, safe navigation.

• Routing engine – initially tested on Apple Maps but later replaced with a much more accurate solution after 100+ test rides across Berlin.

• Production release – launched on the App Store at €4.99 to validate the market.

Yes, the first versions had rough edges and some negative reviews—but every single issue taught me something valuable. I worked nights and weekends, debugging live on the road with my laptop connected via hotspot. That grind paid off: routing is now rock-solid, rerouting works seamlessly, and version 4.0.0 is almost ready for release.

---

📱 Urban Rider Today

Urban Rider is now a fully-featured scooter and moped navigation app, designed for real riders in real cities:

• 🚦 Scooter-only routes (no highways, no unsafe detours).

• 🛵 Moped-friendly road types, avoiding cobblestones and tricky surfaces.

• 🔄 Fast rerouting that respects your actual driving direction.

• 📍 Multi-stop planning and round-trip support.

• 🌍 Tested on the road by early users across multiple countries.

You can check it out at www.urbanrider.app or download it directly from the App Store with a free 8-day trial.

---

🧑‍💻 A Note on AI & Development

Did I use AI? Yes, but not in the “AI built my app in 2 days” way you sometimes hear about. With 20+ years in development, I use AI for:

• Summarizing API documentation.

• Suggesting alternative approaches.

• Speeding up research.

But complex projects like navigation still require deep architectural thinking, relentless debugging, and hands-on problem solving. AI is a tool, not a co-pilot.

---

🌱 What’s Next?

Building Urban Rider from zero to production in just three months has been the most rewarding challenge of my career. It reminded me how much I love building products that solve real problems.

And now? I’m open to new opportunities—whether as an Engineering Manager, Senior iOS Developer, or something entirely different. Maybe even starting a coffee shop (I make a mean espresso ☕).

If you’re looking for someone who blends technical depth, leadership, and entrepreneurial spirit, let’s connect.

---

👉 Check out Urban Rider – the first navigation app made for scooters and mopeds.
👉 Open to collaborations, leadership roles, or innovative new ventures.

My Order Was "A Simple Script." The API Chef Served a Three-Course Automation.

I had what I thought was a simple order. A straightforward request for the kitchen. "I'd like to automate posting about my new iOS app, Urban Rider, to Reddit. Nothing fancy, just a script that posts to a different, relevant subreddit each day without being a spammy nuisance."

Simple, right?

I sat down at my favorite table here at the Restaurant of Mistaken Orders, the one with the wobbly leg and the IDE open. I thought I knew exactly what I wanted. But the chef, a quirky, undocumented platform called Relay.app, had other plans. What followed was a delightful, maddening, and ultimately illuminating multi-course meal of errors, discoveries, and a final dish that was far more interesting than the one I originally ordered.

First Course: The Appetizer of Confusing Errors

My first order was simple: "I'll have the plain JavaScript, please." I wrote a script to authenticate with the Reddit API.

The waiter (the error log) came back almost immediately. "Sorry, chef says this is a TypeScript-only dish." It was covered in red squiggles complaining about things like Promise<Output>.

"Okay," I said, a little confused. "No problem, I can speak TypeScript. Let me rephrase my order." I carefully rewrote the script with all the proper types. This time, I asked for some standard ingredients: fetch to make the web request, and Buffer to encode my credentials.

The waiter returned, looking apologetic. "About that... we're out of fetch. And Buffer. Actually, we don't have any of the ingredients you'd normally find in a kitchen."

This was a truly mistaken order. I was in a restaurant that had no ingredients. It was like ordering a steak and being told the very concept of "cow" was not supported in this establishment. Every attempt failed. The code couldn't find axios, then it couldn't find http, then it complained about invalid characters in a header that my own tools had corrupted.

The "Aha!" Moment: Reading the Chef's Menu

This is where the magic of this restaurant kicks in. After sending back every dish, I realized my mistake. I was trying to tell the chef how to cook using my own recipe book. I needed to stop and ask: "What's the Chef's Special today?"

I stopped trying to write code. Instead, I looked at the menu the platform provided: the no-code UI steps. The user manual I found (thanks to my helpful AI rubber duck) confirmed it: the Code step was a tiny, limited kitchen, but the Custom HTTP Request step was a full-service Cordon Bleu kitchen, complete with all the tools we needed.

I had ordered a custom meal, but the real solution was the buffet all along.

Second Course: Getting the Recipe Right

Switching to the no-code UI was a game-changer. All the complex authentication logic was suddenly a set of simple fields. But there was one last mistaken order. My request was rejected with a 401 Unauthorized error.

After double-checking everything, we discovered the "secret sauce." The UI didn't have a clear Authentication button. The solution? We had to create the Authorization header manually.

1. Combine the ingredients: We took my app's Client ID and Client Secret.
2. Use a special tool: We used an online Base64 encoder to transform them into a single, secret string.
3. Add the finishing touch: We added the Authorization header with our new encoded string.

Voilà. The API returned a 200 OK. We had successfully authenticated.

Third Course: The Smart Automation Dessert

Now for the fun part. With the connection established, we built the workflow I had wanted from the start.

1. The Daily Special (Choosing a Subreddit) To avoid posting to the same place every day, we added a small JavaScript step. This code acts as our friendly host, seating us at a new table each day. It uses the number of days since 1970 to create a rotating index, ensuring we cycle through our list of 12+ subreddits with plenty of time between visits to the same one.

2. The AI Sous-Chef (Generating the Content) This is where it gets really cool. We added an OpenAI step. But instead of just telling it "write a post," we gave it a detailed recipe (a prompt) to follow:

• Act like a human: "You are a helpful and passionate developer, not a marketer."
• Know your audience: "The target subreddit is [Subreddit Name]. Analyze the name and tailor your tone."
• Focus on one thing: "Pick ONE key problem Urban Rider solves (like avoiding highways) and make that the theme of the post."
• Be engaging: "End with an open-ended question to start a real conversation."

The result was magic. The AI produced a perfect, authentic-sounding post that didn't feel like an ad at all.

3. Plating and Serving (Posting to Reddit) The final step took the output from the AI (title and body), the chosen subreddit, and our auth token, and used another "Custom HTTP Request" to serve the final dish to Reddit.

The Moral of the Story

My visit to the Restaurant of Mistaken Orders was a success. I didn't get the "simple script" I originally ordered. Instead, I was served a sophisticated, multi-course automation that was far more robust and intelligent.

The experience taught me a valuable lesson: sometimes the best solution isn't about forcing a tool to work your way, but about understanding the tools you're given and using them to their full potential. The "Chef's Special" is often better than anything you could have ordered off the menu.

So, what's your favorite "mistaken order" story from a project you've worked on? I'd love to hear it in the comments. And if you're a scooter rider tired of being sent onto the freeway, you know which app to check out.