Building Buddy Check On Me: My Journey Into Mobile App Development

Six months ago, I set out to learn something new: mobile applications. Despite 25+ years in software development, I had never dived deep into iOS or Android app building. At the same time, I was volunteering as a board member at a cooperative and looking for new work. Progress was never going to be lightning-fast, but I wanted to stay busy, keep learning, and maybe create something useful along the way.

That's when a conversation with a friend sparked an idea: what if there was an app that started a timer, and if you didn't stop it in time, it alerted someone you trust?

I ran with it. The idea became Buddy Check On Me, a mobile app with a serverless backend that keeps your friends or family in the loop — without subscriptions, without ads, and without expensive hardware.

The Idea

I wanted Buddy Check On Me to be something I'd actually use myself: simple, low-cost, and ad-free. I was frustrated by services I'd used in the past that suddenly raised fees by 50% without adding features. My philosophy: prices should only increase if costs go up, not because of corporate buyouts and profit goals.

I had also used satellite services for hiking. Buddy Check On Me isn't meant to replace those, but to complement them — or at least provide something more reliable than doing nothing. The core concept:

You set an activity with a name, description, and duration.
If the timer runs out, your buddy gets notified.
If you enable location, your buddy also sees where you started and breadcrumb updates whenever you had cell service.

It's simple, direct, and built around SMS — because SMS works on virtually every phone.

Building the Prototype

I chose Expo (React Native + TypeScript) so I could write one codebase for both iOS and Android. That decision alone let me move quickly. Within one month, I had a working prototype with both a mobile frontend and an AWS serverless backend.

I thought: "Another month or two and I'll be done."

Spoiler: it took much longer. Along the way, I hit challenges I couldn't have predicted. Here are the big ones.

Challenge #1: Authentication

At first, I used OAuth for login — Google, Apple, etc. Technically, it worked. But the user experience was terrible:

Users had to leave the app.
Sometimes they didn't get redirected back.
It felt clunky and confusing.

Testers confirmed what I suspected: this wasn't going to fly.

The fix? Phone number login.

User enters a name and their phone number.
The app sends them a one-time passcode by SMS.
They confirm, and they're in — no redirects, no fuss.

It was dramatically simpler and much more natural for what the app does.

Challenge #2: Messaging

The app depends on SMS. My first attempt used AWS SNS, which worked fine for testing, but I wanted a production solution that was dedicated and polished. I picked Twilio because of its strong focus on messaging and a great dashboard.

At first, I thought it was easy: I just bought a random US number (978 area code, Massachusetts). Messages worked — at least in the US.

Then I tested with friends in Canada. Messages randomly disappeared. After weeks of trial, error, and digging, I learned why:

10DLC (10-digit long code) numbers are not reliably supported in Canada.
Canadian carriers (Telus, Rogers, Bell) treat them as low-trust.

The solution: toll-free SMS numbers. These are recognized across both the US and Canada. But toll-free required a vetting process:

Submitting forms.
Sharing my privacy policy.
Explaining message content.

For weeks, my requests kept getting rejected until I finally connected with someone at Twilio who helped me push it through. Credit where it's due: their support was excellent once I got a real person involved.

Challenge #3: Cost Model

From the start, I knew I didn't want banner ads, data harvesting, or endless subscriptions. But SMS isn't free.

Apple and Google enforce a minimum price of $0.99 for paid apps or in-app purchases. I had two choices:

Monthly subscription (simple, predictable).
Top-up tokens (complicated, but fair).

I chose tokens. Why? Because I dislike subscriptions. We're all surrounded by them — streaming, cloud storage, you name it. You pay every month, even if you don't use the service.

Buddy Check On Me uses tokens that only expire after a year:

150 tokens for $0.99 to start.
1 token per activity.
25 tokens reserved per buddy to cover SMS alerts (refunded if the activity ends on time).
More tokens available: 100 for $0.99 or 1000 for $4.99.

This way, you only pay for what you use, and you control the pace.

Challenge #4: In-App Purchases (IAP)

Another hurdle was enabling users to actually buy those tokens inside the app.

I tried the open-source React Native IAP library, but it was breaking constantly. Build errors, runtime errors — it was a mess. The maintainers had stopped keeping up with Apple/Google's constant changes.

That's when I found RevenueCat:

Free if you make less than $2,500/month.
1% fee after that.
Handles Apple + Google integration.
Bonus features: analytics, A/B testing, audience segmentation.

It wasn't painless — I had to debug product setups and sandbox tests — but it worked. RevenueCat saved me months of pain.

Challenge #5: App Store Approval

Building the app was one thing. Getting it approved by Apple and Google was another challenge I hadn't anticipated.

Apple required me to create a video demo of the app. I had never made an app walkthrough video before, so I had to quickly learn how to splice clips together using iMovie. It felt a little ironic: after all the coding and backend design, what tripped me up was video editing!

Google, on the other hand, had a very different requirement: before public release, at least 12 people had to install the app, and it needed to stay published for 12 days. The catch? Only official Play Store testers counted — sideloaded APK installs didn't. That sent me scrambling to recruit neighbors, family, and friends to hit that magic number. Then, I had to sit and wait nearly two weeks before Google would let me proceed.

Both processes were strange in their own way, but it reminded me that shipping software isn't just about code — it's also about jumping through the right hoops.

Challenge #6: Address Verification

Another unexpected roadblock: my address.

Because I was publishing as an individual, Google Play wanted to use my personal home address from my government-issued ID (driver's license). That would mean exposing my home address publicly on the app store. I wasn't comfortable with that, so I bought a PO Box.

Simple enough, I thought — until I discovered that Google wouldn't accept a PO Box as proof of residence. They required a "recognized" document: a lease, mortgage, utility bill, government ID, or bank statement. I tried changing my Koodo (mobile phone) bill to use the PO Box, but Google rejected it. Next, I tried my bank. Unfortunately, banks in Canada generally don't accept PO Boxes as an official account address.

I even asked the bank to issue a special mailing address accommodation — which they did — but I had to wait an entire billing cycle (a month!) before it would appear on an official statement. The bank even tried printing a letterhead for me, but Google's verification system (likely AI-driven) didn't recognize it as valid.

Finally, in desperation, I updated my Telus internet account to use the PO Box. Ironically, I wasn't even using Telus for mobile service… but their statement worked. Google accepted it, and my address was finally updated on the Play Store. That whole process cost me another three weeks.

Other Lessons Learned

Location tracking: balance is key — provide useful breadcrumbs, but don't drain batteries.
Notifications: make them informative without being overwhelming.
Time management: between volunteering, job searching, and the app, progress was slower than expected. Without those competing priorities, I might have finished earlier — but the unexpected challenges were always going to extend the timeline anyway.

The Result

After months of learning, building, debugging, and iterating, I'm proud to share
👉 Buddy Check On Me

It's not perfect, but it's real, it's mine, and it works.

Final Reflection

This project reminded me that building something new is never as fast as you hope — but always more rewarding than you expect.

I learned mobile development, navigated real-world messaging challenges, built a SaaS backend, and created something I'd actually trust to use myself.

And that's the heart of it: Buddy Check On Me isn't about selling subscriptions or showing ads. It's about building tech with empathy and keeping people connected.