Looking Back: Building GoRemote Africa - The Maximum Viable Product Disaster
The Situation: Spent the last year building GoRemote Africa, a job board for remote work in Africa. What started as a simple "jobs go here" idea turned into a proper mess of features, four complete rewrites, and honestly, a masterclass in what not to do when you're building a product.
The Decisions: Let me be clear about this - I made some spectacularly bad choices. Here's the honest rundown so you don't have to repeat my mistakes.
The MVP That Wasn't Minimum At All
No beating around the bush - I restarted my codebase four times. Why? Because apparently I thought MVP stood for Maximum Viable Product. I crammed in AI-powered forms, three OAuth providers, magic links, two payment gateways, API keys, and granular role-based access—all before a single job got posted.
This thing was giving me serious wahala. By the fifth attempt, I was so demotivated I could barely open VS Code. Finally said enough and stripped everything down to the core: a job board that lets jobseekers find roles and lets employers post jobs. That's it. No drag-and-drop builder, no magic links. Just jobs.
Here's what I discovered: it worked better than all the over-engineered versions combined. The real issue here is that I was building for some imaginary user who needed every feature under the sun, instead of building for the actual user who just wanted to find a job.
Pretty UI Is Just Procrastination
Spent weeks browsing Behance, obsessing over hex codes and button padding whilst my core product sat there doing nothing. The site looks clean now, but those pixel-perfect gradients didn't validate my idea—shipping did.
Let me tell you what went wrong: I was using design as an excuse to avoid the scary part of building—actually putting something out there for people to use. Users don't care about your beautiful hover animations if they can't find what they're looking for.
The Development Environment Nightmare
Here's the thing though - I coded on Windows, deployed to Vercel's serverless environment, then tried to run it on a Linux VPS with Coolify. It was like watching a horror film at 2 AM. The sharp library threw proper tantrums, and suddenly I'm debugging OS-level dependencies instead of building features.
# This haunted my dreams for weeks
Error: sharp: Installation error, please try npm install --verbose sharp
# Windows said it was fine, Linux said absolutely not
The solution was simpler than I thought: Docker. Should have containerised everything from day one, but past me thought he was too clever for that. Now everything runs in containers, and I sleep better at night.
Multitasking Is Just Stress With Extra Steps
Tried to code, design, handle payments, and answer support emails simultaneously. Long story short: nothing got done properly. Now I finish one task before touching the next, even if it's small.
What I didn't expect was how much mental energy gets wasted just switching between contexts. Your brain isn't a computer - it can't actually multitask efficiently. Focus on one thing, finish it, then move on.
Finding Your People Makes All the Difference
Joining The Build Forge and MuslimBuilders changed everything. Suddenly I wasn't the only one dealing with these problems. Met founders who'd survived the same challenges and actually shipped products.
Bottom line is: half the "experts" giving advice online have never actually built anything. The builders in these communities? They've been through the fire and came out with working products. Their advice actually matters.
Your Workspace Actually Affects Your Work
2018: Coding in notebooks (the paper kind)
2021: A 4GB RAM Celeron laptop that struggled to run VS Code
2024: 27" monitor, ergonomic everything, and proper airflow
After too many debugging sessions hunched over that ancient laptop, I realised laggy tools and back pain were just making everything harder. The upgrade wasn't luxury—it was necessary for actually getting work done.
Git History Is Your Friend
Used to write commits like "fixed stuff lol" and bundle 10 changes into one. Then a bad deployment broke my dashboard, and I had to roll back weeks of work because I couldn't figure out what went wrong.
# Before (terrible)
git commit -m "fixed stuff lol"
# After (actually helpful)
git commit -m "fix: auth token expiry logic
- Updated JWT validation to handle edge case where tokens expire mid-request
- Added proper error handling for refresh token failures
- Refs: #issue-123"
Now I treat git history like a timeline. Future me needs to understand what past me was thinking and why.
Automation Saves Your Sanity
Scraping and filtering 100% remote jobs from the web manually? Checking for dead links by hand? Creating social posts one by one? This approach is simply not viable when you're trying to scale.
Built scrapers with Node.js, cron jobs for cleanup, and AI for content generation. Now the boring stuff happens automatically whilst I focus on the interesting problems.
// Weekly cleanup job that saved my sanity
const cleanupJobs = cron.schedule('0 0 * * 0', async () => {
await removeExpiredJobs();
await validateJobLinks();
await updateRemoteStatus();
});
The Outcomes:
- GoRemote Africa is live and actually helping people find jobs
- Learned more about building products than any course could teach
- Automated job scraping handles 90% of content updates
- Built a tech stack that doesn't require 3 AM debugging sessions
- Users are finding jobs, which was the whole point
The Lessons:
- MVP means minimum, not maximum. Figure out the one thing your product must do, then build that.
- Ship first, polish later. Perfect is the enemy of done.
- Match your development environment to production. Or just containerise everything.
- Focus on one task at a time. Your brain isn't a computer.
- Find your community. Other builders understand your problems.
- Invest in your workspace. Frustrating tools slow you down.
- Write proper git commits. Future you will thank you.
- Automate repetitive tasks. Your time is better spent elsewhere.
- Mentorship is invaluable. Find people who've been where you're going.
The Changes:
Next time I'm building something, I'm starting with the absolute minimum viable version. No feature creep, no "just one more integration." Ship first, iterate based on actual user feedback.
Also sticking with the boring, reliable stack. SvelteKit + Node.js + Docker gets the job done without the fancy headaches.
What I'm doing differently: When I catch myself adding features before validating the core idea, I stop and ask: "Does this help users find jobs better?" If not, it goes in the "maybe later" list.
P.S. If you're hiring remotely, post a job on GoRemote. The AI forms are live now, and they actually work properly. 😉
Learn from my mistakes. Make new ones. What are you building BTW? 🛠️
Top comments (5)
Thanks for sharing these hard-earned lessons! your journey really resonates with me, as I’ve been going through a similar experience while building Deeditt, a platform where people can share their real-life achievements and lessons, just like the ones you’ve outlined here.
I have a few questions that I’d love to hear your thoughts on:
I also wanted to invite you to check out Deeditt! Your startup journey is full of valuable insights that could really inspire and help others who are just starting out, the platform is all about sharing real experiences, celebrating milestones, and learning from each other’s journeys.
Hey! First off, thanks for the kind words—and huge props for building Deeditt. Sharing real, unfiltered lessons is so needed. The startup world’s full of “overnight success” myths, so kudos for creating a space that keeps it real.
Your questions:
“How long did it take to recognize these mistakes?”
Oh, I was deep in denial for months. Like, “No, adding a third payment gateway IS necessary!” 😂 The MVP bloat hit me early, but I kept gaslighting myself into thinking, “users will want this.” It wasn’t until I launched and crickets chirped that I went, “Oh. Oh no.” Some lessons (like environment mismatches) bit me after deployment—like the
sharplibrary fiasco that broke took an entire night of trial and error. Classic “works on my machine” trauma.“Getting first users?”
Begging. Literally. I jumped into every WhatsApp group that had ever mentioned “remote work” and guilt-tripped my friends into testing it. Cold DMs, Twitter threads, even slid into a few Slack communities. The first 100 users were 80% people I knew personally. Pro tip: Offer something immediately useful. For us, it was “post a job for free while we’re in beta.” Scarcity works, but desperation works better.
“Moments of doubt?”
Bro, I rewrote the entire backend four times because I kept thinking, “This codebase is trash.” I had a full existential crisis when my parents asked, “When are you getting a real job?” Confidence? Nah. Stubbornness? Absolutely. The Build Forge community kept me sane—turns out, everyone feels like a fraud at 3 AM.
I see a pattern here too, and I think it’s because there’s no easy path to success, just our beliefs (or stubbornness, as you put it 😂).
Since I’m in a similar phase with Deeditt, I’d love to hear—how long did it take from idea to launch? And how did you approach budgeting in the early days? Bootstrapped all the way, or did you allocate a set amount from the start?
Hey, thanks again for sharing your journey, wishing GoRemote Africa all the growth and success, it’s an awesome mission!
Awesome post. 💯 Really liked the way you presented the lessons with a touch of humour. Thanks for sharing.
You're very much welcome 😀