Leaving Jupiter After Two Years
Today marks my last day at Jupiter.
When my team and I first joined Jupiter through the acquisition of Coinhall back in 2024, there were only 40 people in the company. Over the last 2 years, it has since grown to 150+. My role also expanded from Head of Engineering overseeing 15 engineers to VP of Engineering with 40+ direct reports and 30+ more indirect ones, spanning various product, frontend, backend, data, and infra teams.
The journey wasn't easy, and this article contains my honest attempt at putting into words what I've accomplished, why I chose to leave, and lessons I've learnt along the way.
Product
There wasn't a shortage of interesting and complex projects to work on. Products and features Jupiter pushes out affect millions of users and literally billions of dollars. This section contains a non-exhaustive list of the more interesting stuff I've had the privilege of contributing to.
jup.ag
I was involved in multiple overhauls of Jupiter's flagship product. The one I'm the proudest of was when Joe and I proposed turning jup.ag into a "Super App" in late 2024, with the aim to have all Solana primitives under one roof: swaps, terminal, perps, lending, yields, prediction markets, portfolio, and more.
It was a very contrarian bet at that time and was met with a huge amount of internal resistance, but we pushed through it anyway and it has now become the literal motto of the company: "Just Use Jupiter".
Ultra
Again in late 2024, a few months after joining Jupiter, I proposed the initial product and technical specs for what would become Ultra. I've since handed the day-to-day to other engineers, but otherwise remained very involved in the constant fine-tuning, bug-fixing, and UX improvements.
Today, it does $100M+ in daily volume and $2M-$5M in MRR. All while being built and maintained by a core engineering team of just two!
Real-Time Slippage Estimation (RTSE)
In building Ultra, I also proposed, designed, and architected (what I believe) is Web3's first genuinely capable Real-Time Slippage Estimation for swaps.
Prior to RTSE, users trading on Jupiter were failing 1 out of every 5 swaps. Now, only 1 out of every 50 fails when RTSE is used - a literal 10x improvement in swap success rates.
Jupiter Wallet
In June 2025, I wrote the very first commit for what would become Jupiter Wallet: a non-custodial browser extension wallet. I was the only engineer on it till December 2025, shipping and maintaining it solo while simultaneously managing 20+ engineers and other products. The first version went live in just 3 months.
It's currently sitting at 100K+ users on the Chrome Web Store, with a 4.5-star rating. It also became profitable almost immediately, earning many times over what it currently costs to run.
Data Platform
The Coinhall acquisition brought Jupiter both the data ETL pipelines and the data team I'd built. This became the foundation almost every other product relied on: real-time token prices and charts, the terminal, Limit/Recurring Orders, RTSE, etc. None of them can work well without a fast and accurate data layer.
Solana's 400ms block time, coupled with the fact that hundreds of swaps happen and new tokens and pools are created every second, made this quite a challenging data problem. Building a pipeline that stays real-time, accurate, and resilient at that pace was one of the most fulfilling problems the team and I have solved.
Departure
The original Coinhall team remains at Jupiter today. I remain grateful that Jupiter took a bet on us back in 2024, giving my team a much bigger arena to play in. Jupiter also had the perfect mix of early-stage startup chaos, high-impact product work, and crazily hardworking individuals. Leaving the team I've personally built over 5 years across Coinhall and Jupiter remains one of the hardest decisions I've made in my life.
And thus we've come to the elephant in the room: why did I choose to leave?
As the company grew, I personally hired and onboarded dozens of engineers, and spent as much time on org design as on code. The bulk of my work the past year has been redesigning how the engineering teams work, not just within and amongst themselves, but across the product, design, marketing, and QA teams. Not everything was rosy though - scaling org structure past 100 people is as much politics as design, and I've honestly lost many of those fights.
It's inevitable for politics to exist, especially when a company scales and when one is in a leadership position. However, I wouldn't describe myself as a particularly good politician, nor do I enjoy politicking much at all. I've always viewed myself as an operator: being in the trenches with the engineers, late-night debugging over the stupidest of bugs that occur, and charging forth together with the team on the ground.
In the past 6 months, however, my time was increasingly spent on being an "executive" and making higher-level decisions, and less on day-to-day operations. Yes, high-level work is less enjoyable to me, but this wasn't really the crux of the problem. There's a post by John Carmack detailing why he left Meta. I'll leave a quote here, but I could have taken his post word for word and it'd be reflective of my experience as well:
It has been a struggle for me. I have a voice at the highest levels here, so it feels like I should be able to move things, but I'm evidently not persuasive enough. A good fraction of the things I complain about eventually turn my way after a year or two passes and evidence piles up, but I have never been able to kill stupid things before they cause damage, or set a direction and have a team actually stick to it. I think my influence at the margins has been positive, but it has never been a prime mover.
https://daringfireball.net/misc/2022/12/carmack-facebook.text
Lessons Learnt
Reflecting on my journey thus far though, I can confidently say that I don't have any regrets. In fact, I've learnt a great deal along the way, and these are just some of them, in no particular order:
- Having a team of 1x engineers, but who work cohesively together, is much better than a team of 10x engineers who are all opinionated and disagree with one another.
- Judging one by their output is almost always better than judging one by what they say.
- The skills required of engineering (deciding between tradeoffs and picking the most Pareto optimal solution) are the same skills required to grow an org past Dunbar's number.
- Putting the wrong people in the wrong places is far more damaging than not having them at all.
- The Engineering Manager role is severely misunderstood, both by the people doing it, and by people who are being managed - it's not just about assigning tickets and load-balancing work, it's about architecting a team to work at close to 100% efficiency. This may mean anything from ensuring morale is high to deep diving a particular technical topic with the engineers.
- In an engineering-heavy company, a technical-first manager with good enough people management skills is almost certainly better than a pure manager.
- If you are a manager, learn to trust the people you manage and try your hardest not to break their trust in you - this is how you build a team that's loyal to you.
Future
So, what next for me? I don't really have anything concrete thought out thus far. I plan to take a short break, touch some foreign grass, and come back to cook once I'm hungry again.
But to the team I built, and the engineers I spent those late nights in the trenches with - thank you for putting your faith in me. You were the best part, and the part I'll never forget.