Venato - Blockchain Portfolio Analytics Platform (acquired by Lukka)
Role: Head of Frontend Engineering - built and led the frontend team (5, later 8 engineers) through the product's full lifecycle: startup, acquisition, and two years of post-acquisition development.
Stack: Angular → Next.js / TypeScript, D3.js, C#/.NET backend (separate team)
Context
At Kepler360 we built Venato, a platform that indexed the Ethereum blockchain and computed profit-and-loss curves for cryptocurrency portfolios - turning raw on-chain data into analytics that crypto traders and institutions used to understand their positions. I joined at the early R&D stage to build the web frontend, grew a team of five frontend developers, and led it from startup through acquisition by Lukka and for two years inside the acquirer - where the platform served effectively all of Lukka's customers, including the US government.
The problem
On-chain portfolio data is unreadable in raw form. The backend indexed the chain and computed PNL, but everything the customer actually saw, evaluated, and paid for lived in the web application: portfolio dashboards, PNL curves over time, transaction and asset histories. The frontend had to make dense financial time-series legible and fast - thousands of transactions per wallet, multiple wallets per portfolio.
What I built and the decisions behind it
Version 1.0 (Angular). I built the original web app in Angular. I was more fluent in React at the time, but the team had already built its R&D tooling around Angular - so I made the pragmatic call to build on existing momentum rather than restart the stack around my preference. The hard part was charting: D3.js is not a natural fit in the Angular ecosystem, and viewport scaling with multiple charts on a screen gave us many headaches.
Version 2.0 (Next.js). After the Lukka acquisition, I led a full rewrite of the platform to Next.js. The decisions behind it:
- Hiring pool. We needed the team to grow, and strong React engineers were both easier to find and cheaper than Angular engineers - the stack choice was a hiring and budget decision as much as a technical one.
- SSR. We wanted server-side rendering for performance and security, and Angular's SSR story at the time was weak.
- Ecosystem fit. Charting and crypto-wallet integrations were significantly smoother in the React ecosystem.
Shipping the rewrite without breaking customers. The rewrite was scoped deliberately: the C#/.NET API contract stayed frozen, so v2.0 was a clean replacement of the presentation layer on top of the existing data and endpoints. That constraint kept the project from sprawling into a backend rewrite and made the cutover low-risk - once v2.0 reached feature parity, we swapped it in wholesale. For customers, the look and feel stayed deliberately close to v1.0 (institutional users don't want surprise redesigns), just more polished and much faster. The migration itself was uneventful - which was the point.
Outcome
The product was strong enough that Lukka acquired the entire company to get it, retaining the team on a two-year deal to continue development - which we completed, shipping version 2.0 inside the acquirer. My team grew from five to eight frontend engineers, and the platform we built served effectively all of Lukka's customers, including the US government.
What I'd do differently
Keeping Angular for v1 was the right pragmatic call at the time, but we paid for it later - in hiring difficulty and in an SSR story that never got comfortable. Starting over, I'd build on React/Next.js from day one and absorb the small upfront cost of redirecting the team's tooling.