Well, wipe those tears away, because this is a different story. This is a story of victory. This is the tale of how Blogify, my blogging brainchild, is not just alive and kicking, but fully deployed and functional on the internet for all to see. My laptop, for once, is cool, quiet, and probably as surprised as I am.

🚀 From Glacial Builds to Lightning Deploys

Remember when testing a single line of code felt like waiting for a glacier to melt? Where a 20 minute build cycle was just… normal? Moving from that bare React Native nightmare back to web development was like swapping a rickety donkey for a sports car.

Building Blogify was a dream. With React, TailwindCSS, and Framer Motion, I could tweak a component, hit save, and BAM! see the change instantly. It felt less like coding and more like witchcraft. A very productive, well documented form of witchcraft.

What Blogify Can Do (Besides Not Crashing My Machine)

This isn't just a "hello world" with a blog skin. Oh no. Blogify is a fully loaded, feature rich, blogging beast. Here’s what you can do:

• Write & Publish with Ease: The core of any blogging platform. Create, edit, and delete your literary masterpieces. It’s so smooth, you’ll forget you’re even working.

• User Authentication that Actually Works: Secure user login and profiles. No more pretending to be someone you're not (unless that's your thing, I don't judge).

• Your Own Personal Dashboard: Log in and you’re greeted with a sleek User Dashboard where you can see all your blogs and even check out analytics on your profile. Watch those view counts climb higher than a peak in Hunza!

• Filter Like a Pro: Can’t find that one post you wrote about that thing? Filter articles by authors, tags, and categories in a flash. The search is over.

• Trending Now: The home page showcases trending posts based on most viewed, so you know what’s hot and what’s not. It’s like a popularity contest, but for articles.

• Dark Mode or Light Mode? You Choose: It has a dark and light theme because your retinas deserve choice. My eyes have personally thanked me.

• Butter Smooth Animations: Thanks to Framer Motion, every page transition and hover effect is smoother than a polished ice rink. It just feels modern.

• Fully Responsive: Whether you’re reading on a massive monitor or squinting at a phone on a bumpy jeep ride in Skardu, the experience is seamless. Fully responsive on mobile and big screens? Check.

The Final Boss: Deployment on Vercel

After all the coding, the real test was the deployment. I’ll be honest, I was prepared for another multi day saga of cryptic error messages and existential dread.

But then I used Vercel.

Linking my GitHub repo and hitting deploy was almost… anticlimactic. It was so straightforward, so painless, that I kept refreshing the page, waiting for the catch. There was no catch. Just a beautiful, live URL. My app was on the internet. My laptop, for the first time in months, was silent. The only thing overheating was my sense of pride.

The Lesson Learned (The Sequel)

The lesson from my last blog was "know when to retreat." The lesson from this one is "know when to charge forward."

Pivoting from the mobile app wasn't a defeat; it was a strategic relocation of passion. By focusing on a project that matched my tools (my beloved, underpowered laptop), I was able to build something substantial, see it through to the end, and actually enjoy the process.

I went from debugging existential JDK crises to successfully deploying a full-stack application with a modern tech stack. The win wasn't just the deployed app; it was reclaiming the joy of coding.

What's Next?

Is Blogify "done"? Is any software ever truly done? I’ll be adding more bells and whistles, but for now, it’s a solid, working product out in the wild.

As for the mobile app dream? It’s still there, on the back burner, waiting for the day I upgrade my hardware. But for now, I’m going to bask in the glorious, quiet hum of a successful deployment.

Go forth and explore! The app is live, the code is on GitHub, and my motivation is higher than the K2 base camp.

[https://blogify-seven-rho.vercel.app/]
[https://github.com/SehrishHussain/Blogify]

Missed the dramatic prequel? Read about my great laptop tragedy here: My Hashnode Blog Series

This blog was long due and, honestly, very hard for me to write. Not because I forgot my password, but because this one isn’t about a glorious breakthrough. It’s about a bottleneck so severe it made my laptop weep and forced me to pause one of my dream projects. Think of it less as a blog post and more as a tech themed tragedy. With slightly more debugging.

The Dream (Before the Nightmare)

I was building a travel tracking app for my beloved Gilgit-Baltistan. Not just another map app that gets lost the moment you lose a bar of service, but a legit safety tool. The kind that says, "I got you, fam," even during a power outage or a surprise landslide.

The crown jewel feature?
Background location tracking. The ability for the app to whisper your coordinates even when it's napping.

Why?

• Frequent power shortages: Tourists can't be expected to have their phones plugged into a mountain.

• Battery life: My app saving a life while draining a battery to 0% is a terrible review waiting to happen.

• The obvious: Lives > likes.

I started in Expo. It was beautiful. It was fast. It was like coding on a smooth, freshly paved road. But Expo, for all its wonders, doesn't let you do the hardcore, background stuff. It's the "we don't do that here" of the mobile world.

So, like a developer who has just read one too many "Real devs use bare React Native" comments on Reddit, I made the switch.

I entered the jungle. I was not prepared.

💻 The Bottleneck (Or, How My Laptop Learned to Hate Me)

Bare React Native development isn't just coding. It's a ritual. A sacred, frustrating ceremony of summoning ancient SDKs, appeasing the JDK gods, and trying to get Android Studio to not look at you with utter contempt.

Somehow, through tears and copious amounts of caffeine, I did it. I debugged the environment, installed everything, and got my first build running. I did a victory dance. My laptop, now sweating and making a sound like a distant helicopter, did not dance with me.

"Then… reality hit. The kind of hit that leaves a mark.

Every. Single. Build. Command. took 15-20 minutes. I could boil chai on chula, drink it, and have a philosophical debate about the meaning of undefined in the time it took to see if my button color changed. My laptop transformed into a space heater that occasionally allowed me to type. I'd type a line of code, hit save, and go for a walk. By the time I came back, the cursor was still thinking about it. Testing a one-line change felt like waiting for a glacier to melt. A very, very slow glacier that also had to compile Java first.

Yet somehow, I managed to build user authentication, integrate Google Auth, and even implement itinerary generation pulling data from MongoDB. The catch? What should have been a day's work stretched into a 4-5 day marathon of watching progress bars like they were the main feature. My stubborn self the same part of me that tries to fix a leaky tap with chewing gum kept going for days. But after the 100th minute-long fan solo, I had to face the truth: I was trying to run a Formula 1 race on a bicycle. With a flat tire.

It wasn't me.
It was my glorified toaster of a laptop."

The Hard Call (Aka, The Smart One)

Stopping this project felt like giving up on a pet. A very complex, code-based pet that was constantly on fire.

But it wasn't giving up. It was strategic retreat. It was recognizing that sinking weeks into 20 minute build cycles isn't productivity it's a form of digital self flagellation.

So, for now, the background tracking app is on pause. Not cancelled. Just cryogenically frozen until I can afford a machine powerful enough to handle it (read: until I sell a kidney and buy a Mac, because apparently, that's the entry fee).

The Pivot → Enter Blogify (A Phoenix from the Ashes)

Since my laptop can handle web dev without threatening to launch into orbit, I shifted gears. I started building Blogify, a blogging platform.

And folks, the joy. The sheer, unadulterated joy of hitting 'save' and seeing changes INSTANTLY. It’s like going from communicating via carrier pigeon to using a phone. It’s magical.

Here’s what I’ve built so far in the time it would have taken me to do one mobile build:

Tech Stack

• Frontend: React + JavaScript + TailwindCSS (It's fast, it's responsive, it doesn't judge me).

• State Management: Redux (For storing all the important stuff, like whether you're logged in or just pretending to be).

• Authentication: Google OAuth (fancy!) + Email/Password (old reliable).

• Backend: Appwrite (My new best friend. It handles the boring stuff so I can focus on the fun stuff).

Features Implemented so far…

• Redux store: Auth state is flowing smoother than a hot cup of Hunza’s famous tumuro green-tea.

• Full CRUD Operations:

  • Create blog. Done! (The "Eureka!" moment)

  • View blog and saving number of views. Done! (The "It works!" moment)

  • Update blog. Done! (The "Whoops, typo" fix)

  • Delete blog. Done! (The "This idea was terrible" button)

• Editor workflow: Write, save, publish. No 20 minute wait to see if your headline is centered.

The Lesson (Because There Has to Be One)

Sometimes in tech, you have to pause something you love, not because you're a quitter, but because you're not a masochist. Continuing under terrible conditions isn't grit it's a great way to burn out and start hating what you do.

The mobile app dream is on ice. But it's not dead. It's just waiting for a stronger machine and a developer with a few more scars (and hopefully, a MacBook).

In the meantime, I'm back in my web dev comfort zone, building cool things, and remembering that coding is supposed to be fun, not a test of your patience while you sit and do nothing but wait for results nor its a test of laptop's cooling capabilities.

Gilgit Baltistan may be full of obstacles landslides, power cuts, internet that dies when a cloud looks at it funny but I’ve learned to treat coding challenges the same way we treat mountain treks: sometimes you have to turn back, regroup, and wait for a clearer day to climb.

👉 What's next? I’ll keep polishing Blogify, maybe add some hilarious features, and who knows, maybe I'll even let you all try it out. The journey continues, just on a slightly different path!

Check out the GitHub repo for Blogify here and feel the need for speed!

Catch up on the rest of the chaos I call a journey here: My Hashnode Blog Series

The Mission

I’m building a mobile app (React Native) and web app (Next.js) for tourists in Gilgit Baltistan, with a very real use case: people get lost or have accidents in places with no cell coverage. My app should:

✅ Let mobile users send location to backend
✅ Show that location on a map (web + mobile)
✅ Cache the last known location offline
✅ Help rescuers/family track them when they go off-grid

Simple, right?

The Login That Works (and Finally Sends a Token)

After wiring up user registration and login, I hooked Redux into my mobile app to store the accessToken. This allowed me to protect location routes and ensure only logged-in users could send their location.

const token = useSelector((state: RootState) => state.auth.accessToken);

I also added feedback to the user:

Alert.alert("Login Success", `Welcome ${res.user.fullName}`);
navigation.navigate("Home");

Sending Location from Mobile

Here’s how I did it:

1. Requested foreground location permission using expo-location

2. Fetched lat/lng

3. Sent it to backend via Axios with bearer token

4. Saved it to MongoDB in the backend

const location = await Location.getCurrentPositionAsync({});
const { latitude, longitude } = location.coords;
await axios.post("/api/location/save", { lat: latitude, lng: longitude }, { headers: { Authorization: `Bearer ${token}` } });

It felt good to finally see:

Location saved successfully 🟢

The Real-World Use Case

The app is meant to work even in emergency mountain scenarios, where:

• Cell signals vanish

• No internet means no live tracking

So we added AsyncStorage to save the last known location offline, so:

• It can be sent to backend when internet returns

• The web app can show the last known position for families/rescuers

It’s not perfect, but in GB sometimes good enough is life saving.

Reverse Geocoding & City Names

Getting a lat/lng is cool. But displaying:

“Passu, Gilgit Baltistan, Pakistan”

is way more meaningful to a user than just numbers.

I considered:

• Nominatim (OpenStreetMap): free, no billing, fair usage (1 req/sec)

• Google Maps API: more accurate, but requires billing and strict quotas

I picked Nominatim for now, to stay within budget and dev sanity.

GET https://nominatim.openstreetmap.org/reverse?lat=35.5&lon=74.4&format=json

Choosing Map Frameworks 🗺️

I needed maps in both mobile and web versions.

Web (Next.js)

• MapLibre GL JS: Opensource, performant, no billing drama

• Leaflet: Easy but a bit old school

Mobile (React Native)

• react-native-maps works with Google/Apple Maps, easy to integrate

• Future plan: react-native-maplibre-gl for offline maps

Offline maps are ideal for GB, where signal can be lost. But we’ll phase that in later.

AsyncStorage (a lifesaver in no-signal zones)

In mountain areas, a user might:

• Lose signal before their location gets sent

• Be unable to call for help

We designed it so:

• Their last known location is cached offline

• When signals return, the app will try sending it again

• Families using the web app can see that cached location

It’s the tech version of dropping breadcrumbs in the forest, except it works.

Important Considerations

Battery: GPS polling can drain battery. We only get location:

• When user taps "Send Location"

• On SOS/fall detection trigger

Rate Limits: Nominatim (free API) allows 1 request/sec per IP, which is fine for my small user base.

Offline support: No map tiles = no visual. With MapLibre, I can cache map tiles for key GB regions.

Emergency Use: Even if user can’t send a location, their last known coordinates help rescuers.

Summary: Tracking Progress (and Sanity)

In this episode of “What Fresh Bug Is This?”, we strapped on our hiking boots and took our mobile app for a real adventure through the valleys of React Native, past the ridges of Redux, and into the high altitude zones of location tracking.

What I Actually Built

✅ Secure user login
✅ Redux-based token management
✅ Location tracking screen in React Native
✅ Backend API to receive and save coordinates
✅ Successful save to MongoDB
✅ “Send Location” button actually works!
✅ Accurate error logs when it doesn’t (thank you, logs)
✅ Mobile → backend → database pipeline is alive!

What I Thought About (A Lot) 🤔

• Unreliable connectivity

• Battery efficiency

• Offline fallback

• Accurate location (village-level + GPS pin)

• Caching with AsyncStorage

• Designing for emergencies, because let’s be honest if someone’s hanging by a rock ledge with no bars on their phone, my app’s fancy UI animations won’t save them. But a last pinged GPS with a timestamp just might.

How I Chose Maps & Location APIs 🗺️

I had a full on developer dharna about which map frameworks and APIs won’t:

• Drain the battery

• Drain our wallets

• Break when there's no internet

• Violate rate limits

Final Picks:

• MapLibre (for both React Native + Next.js)

• OpenStreetMap + Nominatim

• AsyncStorage

I decided against Google Maps for now because:

• They want your billing account

• They track you harder than your desi mom on Eid

• Rate limits are more forgiving elsewhere

Where I am Headed Next (no pun intended)

• Cache last location offline

• Automatically send when internet returns

• Show it on a map in the app

• Build a simple web dashboard so family members can see the last location

• Add SOS button + fall detection (because gravity is not always a friend)

If you're building a mobile app from scratch, remember: even if your app doesn’t always save lives it should at least not crash when trying.

🧭 Until next time track responsibly, debug often, and don’t forget to breathe (or hydrate).

Welcome to Episode 3 of “The Rocky Road to Clarity”, where I full-time parent, part-time debugger set out to bring location tracking to life... and end up tracking my own sanity instead.

This time, I thought:

“Let’s just build a simple login screen for my React Native app.”

Ha.
Haha.
😐

What followed was a glorious mess of:

• 🔌 mysterious plugin errors,

• 🌐 ghostly network issues,

• 🔐 SecureStore tantrums,

• and 👶 a toddler who thinks "Why?" is the only word in the dictionary.

The Tailwind Spiral

It all started with ambition:

“Let’s use Tailwind for mobile styling! It’ll be fast and elegant!”

So I installed nativewind, added the plugin in babel.config.js, hit save...

Boom.

pythonCopyEdit.plugins is not a valid Plugin property

Me:

“I… didn’t even touch plugins. Who touched plugins?!”

Turns out I either:

• added the plugin wrong,

• added it too early,

• or summoned some ancient CSS curse.

After uninstalling, reinstalling, purging caches, and spiritually cleansing my project (basically an exorcism), I gave up.

• Tailwind: ❌

• Vanilla stylesheets: ✅

• Sanity: 🤷‍♀️

The Case of the Disappearing Backend

Next: connect the mobile app to my Express backend for login.

Tried localhost:5000/api/auth/login.
❌ Failed.
Tried 172.x.x.x.
❌ Failed.
Tried praying.
🙏 Still failed.

My phone was like:

“I don’t know where localhost is. Is it a tourist spot in Gilgit?”

Eventually realized: Expo Go can’t access localhost on your laptop.
It needs your actual IP address, like 192.168.1.20.

So I ran ipconfig, got the right IP, and finally connected.

Meanwhile, my toddler, noticing my increasing frustration, chimed in:

“Mama, why doesn’t your app work?”

Me: “Because… I used the wrong localhost.”
Her: “Why?”
I almost said, “Because Mama was dumb,” but figured I shouldn’t model low confidence in tech this early.
So I tried: “Because localhost only works on the same device. My phone isn’t my laptop.”
Her: “Why?”
Me: “Because… network interfaces, IP addresses, TCP routing, DNS something something…”
Her: “Why?”

By the end, I was muttering "why" not just to her, but to:

• my backend,

• my frontend,

• Expo,

• SecureStore,

• and every life decision I’ve ever made.

SecureStore Isn’t That Secure… If You Don’t Use Strings

Finally, success! I received the token from backend after login.
Victory was near.

Then Expo hit me with this:

vbnetCopyEditInvalid value provided to SecureStore. Must be string.

Of course.
SecureStore only stores strings. I had given it an object. Or maybe undefined. Or maybe a half baked promise of success.

The fix:

tsCopyEditawait SecureStore.setItemAsync("refreshToken", JSON.stringify(token));

Moral of the story:
If you don’t stringify(), you’ll sufferify().

What I Learned (Again) 🧠

✅ What Works Now:

• ✅ Login screen

• ✅ Talking to backend

• ✅ Receiving & saving token

• ✅ Redux state updated

• ❓ Knowing where it breaks next... stay tuned.

Coming Up Next

🏠 Home screen,
📍 Location tracking,
📴 Offline support...

… if I don’t go offline myself first. ☕️

Until then,
Still debugging in pajamas, coffee in hand, toddler on lap.
👣

Remember when I said React Native would make me weep? Turns out Google OAuth beat it to the punch! In this next leg of our Glacier to GitHub journey, I traded mountain switchbacks for authentication switchbacks and discovered why environment variables haunt developers' dreams.

The Authentication Base Camp: Email vs. Google Gates

1. The Traditional Ascent (Email/Password):

   • Next.js form → Express backend

   • Passwords hashed like frozen lakes

   • MongoDB as our gear stash

   • JWT summit flags planted

2. The Glacier Slide (Google OAuth):

   • @react-oauth/google package as our ice axe

   • Frontend harvesting idTokens like ripe apricots

   • Backend verifying with Google’s google-auth-library

   • "Either find existing sherpa or carve new path!"

Simple map, right? *Cue ominous foreshadowing crevasse sounds._

The Two Day Whiteout: When Google Said "Wrong Recipient!"

There it was – the error that stole my sleep:

Error: Wrong recipient, payload audience != requiredAudience

Translation: *"Your token tried to summit K2 but brought Everest gear."_

As a beginner? Those 48 hours felt like:

My debugging expedition:

1. Checked gear at base camp:

   • Triple-verified GOOGLE_CLIENT_ID matched across Google Cloud/Next.js/Express

   • Frontend token generation? Perfect. ✅

   • Backend route receiving tokens? Confirmed. ✅

2. The Crevasse Dive (console.log glacier):

    console.log("Token payload:", payload); // { aud: undefined, ...wait WHAT? }  
    console.log("Expected ID:", process.env.GOOGLE_CLIENT_ID); // undefined 🤯
   

   Discovery: GOOGLE_CLIENT_ID was vanishing like summer snow in auth.controller.ts!

The Ice Axe Fix: Order of Operations Saves the Day

Root cause: My .env file was late to the expedition!

• ❌ Before: dotenv.config() buried after imports

• ✅ After: Strategic positioning at the very summit of server.ts:

// 🚨 EMERGENCY POSITIONING SYSTEM ACTIVATE 🚨  
import dotenv from "dotenv";  
dotenv.config(); // FIRST. BEFORE. EVERYTHING.  

import express from "express";  
import authRoutes from "./routes/auth"; // Now env variables survive!

Why it worked:

• Environment variables loaded BEFORE controllers

• OAuth2Client stopped receiving empty strings ('' vs actual client ID)

• Google finally nodded: "Correct gear, proceed, little mountaineer."

Lessons from the Auth Avalanche

1. Dotenv is diva: It demands center stage.

2. Undefined > wrong value: More terrifying to debug!

3. Beginner’s badge of honor: Two days? Standard acclimatization period!

Next on the Glacier to GitHub Trail

While I bandage my OAuth wounds, React Native looms like Nanga Parbat. Will I:

• Conquer mobile SOS buttons?

• Wrestle location-sharing demons?

• Discover new ways to anger environment variables?

To fellow coders: Ever survived an ".env ambush"? Share your war stories below misery loves company at 15,000 ft! ❄️

// This mom-coder, signing off with functional Google auth and irrational fear of semicolons 🏔️🔑

Why Real Guides Beat AI (For Now)

My vision was simple: connect travelers with battle tested itineraries crafted by local guides and tour companies who've spent decades navigating these mountains. These aren't algorithmically generated checklists they're wisdom packed routes refined through thousands of tourist footprints, unpredictable weather, and real world logistics.

I'll admit I initially flirted with AI-generated itineraries. But staring at ChatGPT's "helpful" suggestion to visit a glacier during monsoon season (a sure path to trouble), reality hit hard. Hallucinations + mountain safety = unacceptable risk. While I might revisit AI later if users demand it, for now, authenticity wins. Our itineraries will carry the fingerprints of experts like Adventure Pakistan and Hunza Guides – people who've literally saved tourists from whiteout blizzards.

The Web-First Temptation (And Its Wisdom)

Confession time: I built the web version first partly because mobile development terrifies me. There, I said it! Fresh off learning Next.js and TypeScript, my inner code-nerd screamed: "USE THE NEW TOYS!" But beyond the shiny tech allure, two practical reasons won out:

1. No-Download Peace of Mind: If you're sharing your live location with worried parents, forcing them to install an app defeats the purpose. A web link works instantly on any device.

2. Zero-Barrier Itineraries: Letting potential travelers browse guide curated routes without logins? Essential. First impressions shouldn't have friction.

Quick aside: That SOS/location sharing magic I mentioned last time? It’s fully designed but not yet coded, my brain’s mapped the switchbacks, but my fingers haven’t hiked the trail!

The Itinerary Quandary: Weather Warnings and AI's Slippery Slope

Here's where things got thorny. I wanted dynamic itinerary notes like: "Heavy snow expected in Naltar tomorrow – pack microspikes and extra layers!" Naturally, my mind jumped to AI-generated real time alerts. But after coffee chats with tour operators, cold water splashed that idea:

"What if AI hallucinates 'light sweater weather' during a blizzard?"
"Will you stake your app's credibility on a chatbot's mountain judgment?"

Their point hit home. More variables = more uncertainty. While AI could theoretically synthesize weather data, terrain difficulty, and gear lists, one wrong suggestion could erode trust instantly. For now, I'm leaning toward human vetted static checklists (e.g., "Always carry oxygen in Khunjerab Pass") with manual weather alerts. But I'm torn where should AI's role safely begin? I'd love your thoughts!

Next Stop: React Native and the Mobile Frontier

The web app is my training wheels. Now comes the real climb: building the mobile experience with React Native. As a mountain mom with zero native app experience, I equal parts dread and crave this challenge. Will I weep over deployment quirks? Probably. Will seeing that first SOS button work on a phone in the Karakoram make it worthwhile? Absolutely.

To fellow builders wrestling with AI tradeoffs: How do you balance innovation with reliability in high stakes contexts? Hit reply your war stories might just save my sanity (and my users' safety)!

// This mom coder, signing off from a misty valley, wondering if React Native has a "panic mode" tutorial. 🏔️💻

Hey wanderers and builders! 👋 I’m a housewife and solo developer living in the breathtaking but treacherous mountains of Gilgit-Baltistan (GB), juggling code, motherhood (my 6 and 3 year-old tornadoes 😅), and the daily chaos of mountain life. Today, I’m sharing the first brutal truth of building my travel safety app: the agony of defining what this app should actually DO.

That Exhausting Back-and-Forth? It’s Called Product Discovery.

You know that phase where you’re drowning in ideas, scribbling features on napkins, questioning every choice, and wondering if any of it solves real problems? That’s Product Discovery the critical process of defining:

• What your app does (and doesn’t do).

• Which features genuinely solve user pain points.

• Why it deserves to exist.

For weeks, I’d put my kids to bed, open my notebook, and spiral:

“Should it just track location? Or also send SOS alerts? What if there’s NO signal? How do I make it work offline? Should it notify emergency contacts automatically? Wait—is this even technically possible?!”

Back and forth. Forth and back. Mom guilt knocking (“Should I be sleeping instead?”). Doubt whispering (“Who am I to build this?”). The mountains outside my window stunning yet deadly reminded me why I started: after seeing news of travelers found dead in ravines days after vanishing. GB’s beauty hides peril: no network, crumbling roads, and zero margin for error.

Why Product Discovery Felt Like Hiking Through a Blizzard

As a solo dev with limited time (naptime = coding time!), every decision carried weight:

1. Feature Triage: I wanted EVERYTHING live tracking, offline maps, automated checkins. Reality check? I’m one person. I forced myself to ask: “If I build ONLY ONE THING, what saves lives?” Answer: Offline location tracking with automated emergency alerts. Everything else? V2.

2. Tech Stack Panic: React Native? Flutter? Pure native? With spotty electricity and a toddler climbing my lap, I needed:

   • Cross-platform (I can’t maintain two codebases).

   • Shared logic (backend + web + mobile in one place).

   • Speed.
     So I chose: TurboRepo + React Native + Express.js. One monorepo to rule them all (shoutout to NPM workspaces!).

How I Tamed the Chaos (Sort Of)

1. Embraced the “Minimum”: My MVP (Minimum Viable Product) became painfully simple:

   • Logs your route offline via GPS.

   • If you miss a checkpoint, it alerts your emergency contacts when signal returns.

   • No fancy UI. No social features. Just a digital lifeline.

2. Leaned Into Constraints:

   • Time? I code during preschool hours and after bedtime.

   • Resources? My “office” is the kitchen table. My “team” is my husband’s feedback after kids sleep.

   • Connectivity? I test in GB’s dead zones (which, sadly, are everywhere).

Progress So Far: Monorepos & Mom Wins 🚀

I’ve set up the bones:

travel-safe-app/  
├── apps/  
│   ├── mobile (React Native)  
│   ├── web (Next.js)  
│   └── backend (Express)  
└── packages/  
    └── shared (Typescript utils, DB models)

TurboRepo is my sanity-saver. One npm install to rule them all? Yes, please.

Why This Matters to Me (And Maybe You?)

I’m not just building an app. I’m coding against helplessness. Every time I hear about a missing hiker in these mountains, I think: “Could my app have given them a fighting chance?”

To every solo dev, mom, or dreamer staring down a mountain of doubt:

Product Discovery isn’t procrastination it’s laying the foundation.
Your constraints? They’re your superpower.

Next Up: How I’m hacking offline GPS tracking in zero-network zones! (Spoiler: It involves file syncing and sheer stubbornness 😤).

Follow my journey here on Hashnode! I’ll share code snippets, mom-fails, and the raw reality of building tech where the wifi stops but the cliffs don’t. ✨

P.S. What’s the hardest part of your Product Discovery phase? Share below—let’s suffer together! 👇

🌍 About the App: "Safe Trails GB" aims to reduce traveler fatalities in remote areas by providing offline location tracking and emergency alerts. Built with love (and chaos) from the mountains of Pakistan.