In 2016, during a turbulent time in Turkey, I joined a startup with an ambitious goal: build a smart city. They were putting together a brand new engineering team from scratch, and they needed people who knew LoRaWAN. I was the person on the team with the most experience with it, which also made me the person who had to educate everyone else.
The starting point was smart water meters. Water infrastructure is everywhere, the business case is straightforward, and it is a solid foundation to build a broader smart city platform on top of. The CTO had strong conviction about LoRaWAN from the beginning. He wanted the entire network built on it and nothing else.
What followed was one of the most technically demanding and formative periods of my career. This is the story of what we built, what broke, what I rewrote, and what I learned that I could not have learned any other way.
The problem with starting in 2016
LoRaWAN in 2016 was not what it is today. The protocol was young. The ecosystem was thin. There were chipsets and modules, but the tooling around them was immature. And critically, there was no proven open-source network server. The infrastructure that teams rely on today, ChirpStack, The Things Network, Helium, none of that existed in a production-ready form.
If you wanted a LoRaWAN network, you built it yourself.
How the architecture evolved
The first gateway was a Raspberry Pi with an SX1301 LoRa concentrator board. I wrote the protocol stack from scratch in C, with the gateway also acting as the network server. The reason was simple: no existing network server did what we needed, and C was the right tool for a performance-critical radio stack running on constrained hardware. The gateway handled receive, decode, join, and downlink scheduling all in one process.
The C codebase worked but it was hard to maintain and extend. I rewrote the non-performance-critical parts in Python to make the code more accessible to the team. But Python could not handle the timing-sensitive parts of the radio stack, so I built C extension libraries that Python could call into. This pattern, a Python application calling into C for the heavy lifting, became the architecture we ran on for a while.
As the network grew, running the network server on the gateway became a bottleneck. The gateway needed to stay lean and focused on radio. So I migrated the network server to a cloud deployment, again in Python, and redesigned the packet flow accordingly. The gateway became a forwarder. The cloud handled session management, join server logic, and application routing.
By this point the scope had grown beyond pure embedded work. I ended up leading the web development team building the application server: the platform that utilities and city operators would use to view meter data, configure devices, and manage the network. That meant coordinating firmware, backend, and frontend teams to ship a coherent product.
What I had to figure out along the way
This project forced me to learn things I had never needed before, not from a course but from necessity.
The lesson that stayed with me longest
The technical lessons were significant. But the thing that has stayed with me longest from that project is not technical at all.
I watched junior engineers struggle, not because they lacked talent, but because nobody was guiding them. They were capable people. But they had been handed responsibility without context, without mentorship, without someone to help them understand not just what to build but why, and what to do when the expected path turned out to be wrong.
And I realized something that I have not stopped thinking about since: a junior engineer without a mentor is not discovering the technology. They are still discovering themselves. They are figuring out how they think, how they work, how they handle pressure, how they communicate when something is not working. That process takes time and it consumes capacity. You cannot expect someone in the middle of that to also independently navigate production architecture decisions.
The leaders who helped me most on that project were not the ones who had all the answers. They were the ones who asked the right questions at the right moments, who gave me enough rope to figure things out but caught me before I fell too far.
If you are building a team and nobody is leading the junior engineers, you are not building a team. You are accumulating potential that is not being converted into anything. And eventually those engineers will either leave for somewhere they can grow, or they will stay and build things that reflect the limits of what they could figure out alone.
That startup in 2016 taught me more than any project before or since. Not just about LoRaWAN, MQTT, radio design, and Python. About what it means to build something from nothing, with a team that is also building itself at the same time.
Next Tuesday: LoRaWAN deep dive, Part 1. How it actually works, from the network architecture down, starting where it matters for product decisions.