I Work at an EDA Startup. But There’s Another Project I Can’t Stop Building.
Why I’m building ResQNet alongside my work in chip design, and what this side project is teaching me about engineering, consistency, and building something that matters.
Most of my day revolves around semiconductors.
I work at an EDA startup, where we’re building tools to make chip design faster and more efficient. It’s challenging work. There are algorithms to optimize, performance bottlenecks to investigate, and problems that sometimes take days just to understand properly.
And I genuinely enjoy it.
But somewhere between working on placement algorithms, debugging C++ code, and thinking about GPU acceleration, I found myself spending time on a completely different problem.
What happens when someone needs help, but the internet is gone?
That question eventually became ResQNet.
And despite everything else on my plate, I keep coming back to it.
The idea that stayed with me
We have incredibly powerful smartphones in our pockets.
We can video call someone halfway across the world, transfer money in seconds, and access almost anything online.
But take away the network, and suddenly many of those capabilities disappear.
Now imagine a flood, an earthquake, or a remote area where connectivity is unavailable.
Your phone still has battery. Its Bluetooth and Wi-Fi radios still exist. There might be dozens of other phones nearby.
Yet sending a simple message to someone who needs to hear it can become difficult.
I kept thinking about that.
What if nearby phones could help carry messages for one another, without depending on the internet?
I’m not the first person to explore mesh networking, and ResQNet isn’t trying to reinvent the concept.
I wanted to understand whether I could build a practical implementation myself.
So I started.
Building something very different from my day job
During my work at the EDA startup, I’m thinking about chip design, performance, timing, and optimization.
With ResQNet, the problems are completely different.
I’m working with Java, Android, peer-to-peer communication, distributed systems, message routing, security, and backend infrastructure.
The project is built around a simple idea: a phone should be able to pass an emergency message to another nearby phone, which can potentially relay it further.
The architecture includes an Android application, a Java mesh-routing core, a simulator for testing network behavior, a Spring Boot backend, and a React-based command centre.
One of the most interesting parts has been thinking about failure.
What happens if a device disconnects while forwarding a message? What if the same message keeps circulating? How do you know whether a message actually reached its destination rather than just the next phone?
These aren’t problems you solve by making a nice interface.
You have to think carefully about the system underneath it.
And honestly, that’s the part I enjoy most.
The part people usually don’t post about
Building a side project while working at a startup isn’t always exciting.
Some days, I make meaningful progress.
Other days, I spend hours debugging something that looked like a small issue.
There are evenings when I have plenty of ideas but very little energy left to implement them.
Sometimes a feature works perfectly in a simulator and raises entirely new questions when you try to test it on actual hardware.
ResQNet has made me appreciate how big the difference is between software that runs and software you can actually trust.
Get Amangautam’s stories in your inbox
Join Medium for free to get updates from this writer.
I’ve been able to test communication between two physical phones, and the project has automated tests and simulated multi-hop scenarios.
But there is still important work ahead, particularly validating multi-hop delivery across three or more physical devices and investigating real-world reliability.
I’m not going to pretend those problems are solved.
This is experimental software, not a replacement for emergency services.
A simulation passing is not the same as a system being ready for a disaster.
And that’s exactly why I want to keep working on it.
Why I made it open source
At some point, I realized I didn’t want ResQNet to be another repository that only I could understand.
So I opened it up.
Documentation, issues, tests, contribution guidelines, and development workflows became part of the work, not just things to add at the end.
Seeing other developers take an interest, ask questions, report issues, and contribute has been one of the most rewarding parts of the journey.
It changes how you think about your code.
You start asking whether somebody else could understand your design decisions. Whether your tests explain the expected behavior. Whether your documentation is actually useful.
You’re no longer building only for yourself.
And I think that makes you a better engineer.
Two different projects. A similar lesson.
People might wonder why I’m spending time on an emergency communication project while already working in a technically demanding field like EDA.
For me, the two experiences complement each other.
At the startup, I’m learning to think seriously about performance, correctness, and engineering trade-offs.
With ResQNet, I’m applying that same mindset to distributed communication, reliability, and open-source development.
Both keep reminding me that engineering isn’t just about getting an impressive demo running.
It’s about understanding what happens when things go wrong.
A faster algorithm means little if it produces incorrect results. A message-routing system means little if it tells someone their message was delivered when it wasn’t.
Different domains. Same responsibility.
I don’t know where ResQNet will go
Maybe ResQNet will grow into something genuinely useful.
Maybe it will remain an open-source research project that helps people learn about networking and distributed systems.
There are still difficult engineering problems to solve, and plenty of tests left to run.
I don’t have a dramatic success story to share yet.
What I do have is a project I care about, a growing codebase, people contributing to it, and a reason to keep improving it.
I’m still learning. Still making mistakes. Still figuring things out.
And between working on chip design tools and building ResQNet, I’m realizing something:
You don’t always need to know how big an idea will become before deciding it’s worth working on.
Sometimes you just need to care enough to keep showing up.
ResQNet is still under development.
And I’m still building.
ResQNet is free and open source.
If you’re interested in Java, Android, distributed systems, mesh networking, or simply building technology for meaningful problems, I’d love for you to explore the project, share feedback, or contribute.
GitHub: https://github.com/Gautam-aman/ResQNet
Thanks for reading. — Aman Gautam
