Vetution — founding & frontend foundation

Context

I co-founded Vetution, a B2B e-commerce platform where veterinary clinics order supplies online. There was no existing product, frontend stack, or delivery workflow — I built it from zero.

For the first phase of the company, I was solely responsible for the entire frontend: every screen, route, component, state pattern, and release. I also contributed to product decisions — stack choices, key user flows, and how we staged releases — alongside the wider founding team.

Later I hired two frontend engineers and led them through a full client-side → server-side rendering migration on Nuxt, while the product kept shipping.

Vetution ↗ is still live, but the site has been redesigned since I left — it no longer reflects the frontend I built. This write-up covers my tenure (2020–2022) rather than the current product.

What shipped

Solo phase — full frontend ownership

• Complete Nuxt/Vue application: catalog browsing, cart, checkout, account areas, and clinic admin surfaces
• Frontend architecture from scratch — routing, Vuex state, module boundaries, and a reusable component and styling layer (Sass/Less)
• Review, environment, and release workflow the rest of the team could depend on while I was the only frontend engineer

Team phase — hire, lead, migrate

• Two frontend hires onboarded into the codebase and review habits I had established
• CSR → SSR migration across the Nuxt app — product and catalog pages server-rendered so content was indexable and first load no longer depended on a client-side boot
• Migration run incrementally so feature work did not stop while the rendering model changed

Challenge

• Greenfield with no rails — no design system, no conventions, no one else to share frontend load
• CSR-first trade-off — fast to ship initially, but product and catalog pages were a poor fit for SEO and slow on first paint
• Solo → team transition — patterns had to be stable enough for two new engineers to contribute without rework
• Migration under delivery pressure — SSR could not mean a feature freeze while the clinic-facing product still had to move

Approach

• Architecture before volume — module boundaries and state patterns chosen for a long-lived product, not demo speed
• Owned product calls where frontend was affected — which flows to build first, how checkout and catalog behaved, when to cut scope vs ship
• Hired for the migration phase — engineers who could own SSR cutover and ongoing delivery, not just ticket throughput

Outcome

• Entire Vetution frontend built and shipped by one engineer before the team scaled
• Two frontend engineers hired, onboarded, and contributing within the structure already in place
• CSR → SSR completed — product and catalog pages crawlable and served as HTML on first request instead of waiting for client JS to boot
• Frontend stopped being a bottleneck for backend and product teammates during the scale-up