Building Stuurmy: The Project That Taught Me to Ship Imperfect

There's a word in Afrikaans — *stuurmy*. It means "send me."

Say it out loud. Feel how it rolls off the tongue, half-request, half-promise. That's exactly what we wanted the app to be: a small act of faith. You tap a button, and someone shows up at your door.

This was my first real personal project. I built it near the end of varsity, coffee-fueled and stubborn, over the course of a year that stretched like taffy. It never fully launched.

And honestly? It's one of the most important things I've ever made.

Let me tell you why.

The Problem We Were Chasing

Here's a scene that plays out in homes across South Africa every week:

You need your garden done. Or your car washed. Or someone to deep-clean before the in-laws arrive. So you ask a friend. You scroll through Facebook groups, squinting at blurry profile pictures. You hope — really hope — that the person who shows up is trustworthy.

It's a small gamble every time. And it shouldn't be.

A friend brought me the idea over lunch one afternoon. *What if we built the Uber for home services?* A marketplace where you could find verified people, pay without fumbling for cash, and actually trust who walks through your gate.

I saw it as something bigger than an app. A test. Could I build something real, alone, with no roadmap and no team? Just me, a laptop, and an idea that felt too big for my hands?

I said yes before I knew what I was agreeing to.

Learning to Walk by Running

Here's the thing about starting from zero: you don't know what you don't know.

When I began, I wasn't fluent in any mobile language. I was learning grammar and syntax while trying to write poetry.

My first instinct was Kotlin. It felt right — widely respected, Android-focused, the kind of choice that sounds good when you say it out loud. I dove in. Built screens. Made progress.

Then reality knocked.

*What about iPhone users?*

Going Android-only meant slicing the market in half. I sat with that thought for a few days, staring at the code I'd written, feeling the weight of the decision.

Then I deleted everything. Started over with Flutter.

It hurt like pulling stitches. But Flutter gave me both platforms from a single codebase. And Firebase became my constant companion — handling messages, catching crashes, storing data, running backend logic. For a solo developer watching every rand, Firebase was a lifeline.

Startup-friendly. MVP-friendly. *Broke-student-with-a-dream* friendly.

The Uber-Style Dream

The core idea was beautifully simple: make finding help as easy as hailing a ride.

**For customers**, it worked like this:

1. Open the app, pick a service — cleaning, gardening, car wash, mechanics
2. Tell us what you need
3. Tap "Find Provider" and watch a map spring to life, searching for the nearest available hands
4. Get matched, confirm, and wait

**For service providers**, it was about possibility:

1. Sign up, list your skills, set your hours
2. Get validated
3. Start receiving requests from people in your neighbourhood
4. Accept jobs, build your name, earn money

The dream underneath it all? Empower young people to turn their skills into income. Give homeowners a way to get things done without the anxiety.

Simple dreams are often the heaviest to carry.

Where the Code Fought Back

Two challenges nearly broke me. I remember both vividly — the specific frustration, the late nights, the small victories that felt enormous.

**The geolocation balancing act**

When a provider accepts a job and starts moving, customers want to watch that little dot crawl across the map toward them. Real-time tracking. The feature everyone expects now.

But every location update hits the database. Push updates every second and you'll bleed money, overwhelm your servers, and watch your costs spiral.

I spent weeks finding the balance. *How often is often enough?* Frequent enough to feel live. Sparse enough to stay sustainable. It's the kind of problem that doesn't sound hard until you're neck-deep in it.

**The timeout cascade**

When a customer requests help, the nearest provider gets first chance. But people don't always respond. Life happens. Phones go silent.

You can't leave someone hanging, staring at a spinning circle forever.

So I built a timeout system. Providers get a window to accept or decline. Miss it, and the request cascades to the next closest person. Sounds simple, right?

Edge cases ate me alive. What if two providers are equidistant? What if someone declines at the exact moment the timeout fires? What if the customer gives up mid-cascade?

Getting the logic smooth took longer than I'd like to admit.

The Honest Part

I could dress this up. Make it sound like a near-miss success story.

But I'd be lying.

Stuurmy onboarded 5 service providers. 17 customers. Then we stalled.

The tech worked. The app functioned. But we hit the oldest problem in marketplaces: the chicken and the egg. You need providers to attract customers. You need customers to attract providers. Neither comes first. Both have to come together.

And geography made it worse. On-demand services need people *close*. We couldn't find enough trusted providers clustered near enough to actually reach the customers signing up.

We kept fixing. Iterating. Chasing bugs, smoothing edges. But momentum slipped through our fingers like water.

We never truly launched.

What Made People Smile

Despite the stall, something beautiful happened.

People loved the idea. Not politely — genuinely. The vision of young people building their own income, taking control, finding work without the hustle of traditional job hunting... it resonated.

Service providers who tested the app saw real possibility. A way to find consistent work. A path that didn't require knowing someone who knew someone.

The vision was right. The timing, the resources, the runway — those were what needed more.

The Lesson I Carry Everywhere

If I could go back and whisper one thing to my younger self, it would be this:

**Launch in public. Fix as you go.**

I spent so long trying to make Stuurmy perfect before anyone saw it. Every bug squashed. Every edge case handled. Every pixel polished.

But perfection is a mirage. The closer you get, the further it recedes. And while you're chasing it, you're bleeding time, energy, and momentum.

The better path? Ship something that works. Get it in front of real hands. Let people break it — then fix what matters. Iterate based on actual feedback, not imagined scenarios playing on loop in your head at 2 AM.

Done beats perfect. Shipped beats polished. Real feedback is worth a thousand internal reviews.

I've carried this into every project since. It changed how I work.

Why This Lives in My Portfolio

Stuurmy never launched. So why show it?

Because it represents something I'm proud of: **the courage to try.**

When I started, I didn't know mobile development. Had no team. No roadmap. Just an idea and the stubborn belief that I could figure it out.

Over a year, I taught myself Flutter. I learned Firebase inside and out. I wrestled with real-time location, marketplace dynamics, the strange psychology of two-sided platforms.

I made the hard call to restart when Kotlin wasn't cutting it. I solved problems I'd never faced before. I built something *real* — imperfect, unfinished, but real.

That's what I love about this work. Taking ideas that live only in conversation and turning them into something you can hold. Something visible. Something that runs.

Stuurmy didn't become the next Uber. But it made me the developer I am today.

And that's worth more than any launch.

---

Technical Summary

**Timeline**: ~1 year (with pivots, restarts, and a lot of learning)

**Results**: 5 service providers, 17 clients (testing phase)

**Key Learning**: Ship imperfect. Iterate in public. Perfect is a trap.

---

*Have an idea you want to bring to life? [Let's talk.]*