Hazy

I built SODAX Terminal across three sessions over about a month. It's a professional trading terminal with cross-network swaps, tokenized equities, limit orders, lending and borrowing, staking, leverage-yield vaults, a cross-network portfolio, and live protocol analytics. 3,648 lines of app code, 38 SDK hooks, 21 chains in config, 28 money-market reserves live.

The goal was specific: a viewer thinks "this looks like a real product I'd deposit into" and a builder thinks "I could ship this."

Session one was 37 minutes. Scaffold to working product with analytics, trading, earn, and portfolio tabs. About five minutes per major feature area. The ordering mattered: analytics came first because it needs no wallet. The app is useful and demonstrable before a single connection exists. Every tab after that layered onto something that already worked.

Session two is the better story because it starts with the build being thrown out. The first version had 2,500 lines of hand-written CSS, a DIY dropdown/modal/token-picker, and a hand-drawn SVG chart. The feedback was blunt: it looks cheap. The diagnosis: the design decisions were fine, the problem was hand-rolling things that have well-built libraries. Bespoke primitives miss the details that read as quality: focus traps, portalling, keyboard semantics, tooltip engines. No amount of restyling fixes that. So it got rebuilt on Tailwind v4, shadcn/ui on Base UI, TanStack Table, and ECharts. Same afternoon.

I built SodaxPay over a weekend on the SODAX SDK. Payment link generator pick a token and amount, get a link, whoever opens it pays from whatever network they're on.

The wallet SDK did most of the heavy lifting. EVM, Solana, Sui, and Stellar all behind one component. That alone turned what would've been weeks of adapter work into an afternoon. Chain and token data loads live from the SDK at runtime so nothing is hardcoded, and if a new network gets added the app just picks it up.

I ran into an interesting edge case with invoice-style pricing where the output amount is fixed instead of the input. The SDK quotes exact_input only so I had to write convergence logic to land on the right amount. Took some figuring out but once I understood the shape of the API it made sense.

Recovery is solid too. If something fails mid-transaction, funds sit under the payer's control at the hub and the SDK has tools to pull them back directly. No support tickets involved.