Case study
AltitudeAltitude brought me in to improve their HyperEVM trading terminal and build the features it was missing. I connected it to the trading bot and rebuilt the chart and live data for speed. Five months later, the team had a fast, complete trading terminal to show investors, with market and limit orders live.
A fully functional trading terminal
Context
Altitude is a web terminal for trading tokens on HyperEVM. You find a token, read its chart, and buy or sell it in one click. A trading bot executes the trades in the background.
When I joined, most of the product was already built. But the experience wasn’t yet at the level traders expect: charts and live data were slow to load, some flows were unreliable, and key features were still missing, starting with trading itself, as the buy/sell panel wasn’t yet connected to the bot.
Altitude brought me in to improve the product and take on the new features. The goal: a truly functional, optimised trading terminal, with an experience that meets the standard of the best tools traders already use.
What I did
I worked in two phases: make trading real, then make the whole terminal feel fast. Along the way I took on the new features, then integrated the engineers who joined in the autumn.
Altitude had a trading terminal it could demo and put in users’ hands. It supported the company’s fundraising.
The realtime layer, the chart stack and the auth store, rewritten leaner and faster.
Market orders, swap simulation, live quotes and limit orders.
Phase 1
A NestJS backend that talks to the trading bot over gRPC with mutual TLS, covering swaps, wallets, approvals and balances. On top of it came the first real trading panel: wallet selection, slippage, priority fee and amount presets.
One shared stream per token, sent to browsers over Server-Sent Events. It reconnects automatically and closes connections nobody is watching. The client code went from about 1,200 lines to under 100.
Fixed the production pipeline, pinned the app and backend dependencies, cleaned up pages that blocked the build, and simplified the auth flow.
Phase 2
Traders don’t wait. A chart that loads slowly or a login that hangs means they leave. So I put the time where users feel it most.
Rewrote the chart (about −2,500 lines, with the chart store going from 609 to 82 lines). Pool history preloads before the chart opens, older candles load as you scroll back, and mobile gets fewer candles and a lighter layout.
New trades flow into the chart, the transactions table and your positions as they happen. Your own trades appear as buy/sell markers on the chart.
Split the auth logic into small, separate flows for Telegram and wallet sign-in, and fetched the user’s status right after login so the redirect is instant. The token header loads faster too.
Every swap is simulated first and priced by a dedicated quoter service, so you see what you’ll get before you trade.
Trigger an order at a price or a market cap, with an expiry. Status updates arrive live when it fills, fails or expires.
I also set up a steady release process, with hotfix branches and migrations that are safe to re-run. Then I became the integrator for the engineers who joined in the autumn.
Decisions and trade-offs
I prioritised the trading view, loading time and sign-in. Those are the moments where a user stays or leaves, and the ones investors see in a demo.
Market data only flows one way, so Server-Sent Events were simpler and more robust than browser WebSockets. The cost was managing shared upstream connections, so I added viewer counting and automatic cleanup.
With a fundraising deadline ahead, I chose a working product over automated tests. It was the right call for that moment. It’s also the first thing I would add next: tests on order execution and limit orders, plus alerting.
Stack
Result
In five months, the terminal was connected to the bot, fast where traders feel it, and live with market and limit orders.
Tell me about it on a free 20-minute call. I make it fast, reliable and complete, then keep it shipping.