After three years scaling an app with millions of users at ManoMano, I received an interesting offer: join Macadam, a 15-person startup, as Lead Mobile Developer.
The pitch was direct: “We need an expert to rescue our mobile app”.
I accepted the challenge. And over the next year and a half, I transformed an app with critical legacy code into a stable and scalable platform.
This is that story.
The Concept: Walk-to-Earn
Macadam has a simple but addictive concept: it pays you to walk.
It’s not a fitness app. It’s a gamification platform with multiple monetization models:
Revenue Streams:
- Integrated ads
- Game promotions
- Brand-sponsored challenges
- Purchase cashback
The Hook: A Pokémon GO-style map where you collect virtual coins while walking through your city.
The model worked. Users were hooked. The problem wasn’t the concept.
The problem was the app.
The Critical State Upon Arrival
My first day reviewing the code was revealing.
Spaghetti code at its finest:
- Business logic mixed with UI
- Components with 1000+ lines
- No separation of concerns
- Inconsistent patterns
Non-existent infrastructure:
- ❌ No CI/CD
- ❌ No automated tests
- ❌ TypeScript configured but not working correctly
- ❌ No functional linting
- ❌ No established release processes
The result:
- Frequent bugs in production
- Constant crashes
- Fragile features that broke other features
- Impossible to iterate quickly
For a startup that needed to move fast, this was a critical bottleneck.
My Role: The Solo Expert
I was specifically hired as the expert who would solve this.
The team reality:
- 15 total employees
- 3 people in tech (including me)
- My colleagues: 100% busy with product features
Basically: I was the mobile team.
This meant:
- Architecture decisions: mine
- Infrastructure implementation: mine
- Legacy code rescue: mine
- Critical new features: mine
No support team. No second mobile developer to bounce ideas off. No safety net.
It was terrifying. And exciting.
The Transformation: From Chaos to Order
Phase 1: Foundations (Months 1-3)
You can’t build on sand. First I needed solid foundations.
Priority #1: CI/CD
- Complete GitHub Actions pipeline
- Automatic tests on every PR
- Automatic builds
- Automatic deploy to TestFlight and Google Play Beta
Priority #2: Functional TypeScript
- Fix TypeScript configuration
- Gradually type critical components
- CI enforcement
Priority #3: Testing
- Jest and React Native Testing Library setup
- Tests for critical components
- Business logic tests
- Incremental coverage
The goal: No more surprises in production.
Phase 2: Stabilization (Months 4-8)
With infrastructure in place, the next step was stabilization.
Crash Reduction:
- Identification of crash patterns in analytics
- Systematic fixes
- Error boundaries at critical points
- Better error handling
Gradual Refactoring:
- Couldn’t rewrite everything (startup, we need features)
- Incremental refactoring of critical components
- Separation of concerns where it mattered most
- Documentation of patterns to follow
Result:
- ✅ Crashes: Virtually eliminated
- ✅ Production bugs: Drastic reduction
- ✅ Team confidence: Restored
Phase 3: The Map (Months 9-15)
With a stable app, I could focus on the most critical feature: the map.
The Map: Gamification in the Real World
Macadam’s map was the heart of the app. And it was complex.
Component 1: City Streets
Real map integration:
- Rendering of walkable streets
- Performance optimization (many paths)
- Real-time updates as you walk
Component 2: Random Coins
Dynamically generated point system:
Logic:
- Points appear randomly on nearby streets
- User walks towards them
- Upon collecting a coin, gains points
- Value degradation: A coin’s value decreases with each collection by the user
Why degradation? To incentivize exploration. You can’t farm the same point infinitely.
Technical challenges:
- Client-side vs server-side point generation
- Location validation (anti-spoofing)
- Performance with many points on the map
- State synchronization
Component 3: Spots (The Star Feature)
Spots were permanent static points of interest on the map.
How it works:
- Appear at fixed locations (monuments, squares, etc.)
- User approaches the spot (~50m radius)
- A slot machine activates
- Random spin with variable prizes
- Tracking system:
- Who won
- How much they won
- When they won
- Complete history
Technical complexity:
- Precise geolocation
- Fluid slot machine animation
- Backend sync for prizes
- Exploit prevention
- Engaging and responsive UI
This feature became the app’s most addictive. Users returned daily to visit their favorite spots.
Working Solo: Advantages and Challenges
Being the only mobile developer had its pros and cons.
Advantages:
- ✅ Total autonomy: My decisions, my architecture
- ✅ Decision speed: No infinite debates
- ✅ Complete ownership: Responsible for everything, for better or worse
Challenges:
- ❌ No one to bounce ideas off: Decisions are solitary
- ❌ No backup: If I get blocked, there’s no one to take over
- ❌ Burnout risk: Everything goes through you
The key: Ruthless prioritization.
I couldn’t do everything. I had to choose:
- Technical quality or new feature?
- Refactor or maintain legacy?
- Tests or speed?
I learned that in a startup, balance is everything. Neither technical purism nor cowboy coding. The strategic middle point.
Measurable Results
After a year and a half:
Technical Metrics
- ✅ Infrastructure: Complete CI/CD, tests, functional TypeScript
- ✅ Stability: App infinitely more stable
- ✅ Crashes: Virtually eliminated
- ✅ Traceable bugs: Functional logging and error tracking system
- ✅ Code: Much more maintainable and scalable
Business Metrics
- ✅ App rating: Significant improvement
- ✅ User retention: Clear increase
- ✅ Engagement: Features like the map with spots increased daily active users
My Impact
When I left this year:
- The app was production-ready for the long term
- The next developer could iterate without fear
- The foundations were solid
- The map worked perfectly
I left the app in a state where the startup could scale technically.
Lessons Learned
1. Small Startups Are Different
Very different from large companies like ManoMano:
At ManoMano:
- Established processes
- Large team
- Legacy code but structured
- Time to do things right
At Macadam:
- No processes (have to create them)
- You are the team
- Chaotic legacy code
- Critical speed
Both have value. Both teach different things.
2. Being “The Expert” Is Responsibility
When you’re the expert, the startup trusts you completely.
That trust is:
- Empowering: Total autonomy
- Terrifying: If you fail, the project fails
- Educational: You learn to make decisions under pressure
3. Balance > Purism
In a startup you can’t be a technical purist.
Sometimes you need to:
- Write quick-and-dirty code to validate
- Postpone refactors to ship features
- Accept strategic technical debt
The key is knowing when and how much.
4. Infrastructure Is Investment
CI/CD, tests, TypeScript: all this takes initial time.
But it pays for itself in weeks:
- Fewer bugs
- More confidence
- Faster iteration
- Fewer production fires
In startups that ignore this, chaos is inevitable.
5. Features Matter, But Stability More
Macadam had interesting features. But without stability, users left.
First rule: Make it stable. Second rule: Make it fast. Third rule: Add features.
In that order.
Final Thoughts
Macadam was my most intense experience in mobile development.
Not because of technical complexity (ManoMano was more complex).
But because of the total responsibility.
I was the expert. I was the team. I was the one who had to transform a critical app into a stable platform. Alone.
And I succeeded.
When I left, I left an app that:
- Doesn’t crash
- Has solid infrastructure
- Can scale
- Has engaging features
But beyond the app, I left processes and foundations that allow the next developer to continue without starting from scratch.
That’s the good kind of legacy.
What’s Next?
After:
- Learning the basics at SiVasDescalzo
- Scaling to millions of users at ManoMano
- Rescuing a startup as an expert at Macadam
The question is: what comes next?
The answer: Projects where I can apply all this. Consulting. Freelancing. Startups that need mobile expertise.
Because now I know I can:
- Enter a chaotic codebase and bring order
- Build complex features that scale
- Work alone or in a team
- Balance speed and quality
- Be the expert when needed
That’s what years at SiVasDescalzo, ManoMano, and Macadam taught me.
Looking for the next level in your mobile career? Accept the difficult project. The chaotic startup. The role where you’re the expert. That’s where real growth happens.