Otutu Chinedu has lived through the challenges and realities of building products across continents, working from Nigeria with teams based in Portugal, collaborating across American time zones on products used in markets he has never visited in person.
His path, from contract work at Projaro in Abuja to his current role at GreenPlaces, has spanned three continents and various tech environments.
Specialising in Node.js, React, Laravel, and TypeScript, Chinedu shares what actually works when building cross-border software systems.
In this interview, Chinedu speaks about shipping products across the border, and how he collaborates with global talents:
What’s the biggest misconception about distributed development?
The biggest misconception is thinking it’s just like working in an office, but everyone’s on Zoom. In a physical office, you can walk over and resolve an issue in five minutes. That luxury disappears across time zones.
Working from Nigeria with a Portuguese-based team meant being thoughtful about overlap hours, you can’t schedule meetings freely or expect quick responses. It makes you more self-sufficient and deliberate about communication.
Teams that struggle remotely are usually those trying to replicate the office environment. Those that thrive make asynchronous the default and treat synchronous time as a precious resource.
How did that play out at RealFevr when building the NFT platform?
RealFevr was interesting because the Web3 space moves incredibly fast. We made documentation sacred, every decision, every architectural choice, every API contract got written down. When someone in Lisbon made a change at 4 PM, I could wake up in Lagos, read the documentation, and understand exactly what changed without waiting hours for them to come online.
Design collaboration was particularly challenging. Rather than quick back-and-forth about feasibility, we’d batch questions, priority order for animations, mobile-first designs, icon availability. Getting answers took longer, but it forced better planning.
How does a learning environment like 100Devs differ from production teams?
100Devs was organised chaos in the best way, people at different skill levels, learning collaboratively, building MVPs while following a structure that encouraged accountability and mentorship.
Code reviews became teaching moments. Feedback wasn’t just ‘this doesn’t work’, it was “here’s why this causes problems at scale, here’s a better pattern, here’s the documentation.’ That level of mentorship is harder in production environments where velocity matters more.
The distributed nature forced good habits early. We learned to write clean, documented code, ask precise questions, and treat collaboration as a skill separate from coding. Those habits carried forward, joining a production team already independent and communicative makes you valuable immediately.
How meta was it building ZuriChat, a collaboration tool, while working remotely?
Incredibly meta. We were building real-time communication features using Centrifugo for WebSockets while coordinating via Slack ourselves. You notice every friction point because you’re living it while building it.
That experience crystallised what makes good collaboration software: it needs to be fast, reliable, and stay out of your way.
Slow message delivery, unclear notifications, poor search, these aren’t just features, they’re the difference between productive collaboration and constant context-switching.
Our eight-person engineering team had to trust each other completely across a full-stack platform. The core lesson: we all had to understand how our pieces fit together, even without writing every line of code ourselves.
What advice would you give engineers entering global team environments?
First, over-communicate early. Share context generously, ask clarifying questions, and document everything. As trust builds, you’ll naturally find the right balance.
Invest time in understanding cultural communication differences. Directness that’s welcomed in one culture can come across as rude in another.
Consensus-building that’s expected in some places may seem inefficient elsewhere. Spotting and adapting to these differences makes collaboration smoother.
Finally, reframe how you see time zones, they’re a feature, not a bug. With teams spread across continents, you get follow-the-sun development. Someone is always making progress, issues get resolved faster, and having a team that reflects global reality ultimately builds better products.
