How I Built ViaNova

The problem I kept running into

ViaNova didn't start as a product idea. It started as an annoyance.

While applying to jobs remotely, I noticed the same pattern over and over: I'd apply somewhere, move on, apply somewhere else, and then — sometimes days or weeks later — an interview invite would land in my inbox. And every single time, I'd have to stop and reconstruct everything. Which resume version did I send? What did the job posting actually say? What had I already prepared to talk about?

The actual interview prep was never the hard part. Rebuilding the context around it was.

That's the moment the idea clicked for me: the problem people have with job hunting isn't getting interviews. It's remembering everything around them once they arrive.

Why "just track applications" wasn't the right frame

My first instinct — like most people's — was to build a tracker. A table: company, role, status, date applied. I sat with that idea for a while and realized it was solving the wrong problem. A spreadsheet row tells you where you applied. It doesn't tell you why you applied, what the role actually asked for, what you were planning to say in the interview, or what happened the last time you talked to this company.

So I set a rule for myself before writing any code: every application deserves its own workspace, not a row. That single decision changed the entire shape of the product — instead of a table with a status column, ViaNova treats each opportunity as its own evolving project, with job intelligence, interview prep, documents, and a timeline all living together.

Starting with architecture, not features

Here's the part I almost skipped, and I'm glad I didn't: before I built a single visible feature, I spent the first sprints entirely on architecture.

ViaNova is built around Clean Architecture and Domain-Driven Design, with a fairly strict layering:

This felt slow at first. It's tempting, especially early on, to just wire a form straight to a database call and call it done. But I knew two things were coming that would punish that shortcut: I was going to add AI features later (job summaries, risk analysis, interview prep generation), and I was going to want automation via n8n hooked into the same data. If the domain logic is tangled up with the UI or the database client, both of those become painful rewrites instead of additions.

Getting the boundaries right up front meant that when I got to the point of planning AI features, I wasn't restructuring anything — I was just adding a new layer that talks to the same services everything else already talks to.

The stack, and why each piece

I didn't pick these tools because they're trendy. Each one solved a specific constraint:

• Next.js 15 with Server Actions — lets me keep application logic close to the UI without standing up a separate API layer for a product this size, while still leaving room to expose a real REST/GraphQL API later if ViaNova needs one.
• Prisma ORM — gives me a typed, predictable interface to the database and makes the repository layer easy to swap or mock in tests.
• Supabase PostgreSQL — relational data is the right fit here (applications, documents, timelines all have real structure and relationships), and Supabase gets me auth and Postgres without standing up my own infrastructure.
• Zod — validates everything crossing a boundary, so bad data gets caught at the edge instead of surfacing as a weird bug three layers deep.
• Docker, GitHub, Vercel — standard, boring, reliable. I don't want infrastructure decisions competing for attention with product decisions this early.

What shipped first, and why

Sprints 0 through 2 were foundation, workspace UI, architecture, and persistence — no AI, no automation, nothing flashy. Just: can a user create a workspace for an application, and does the data model hold up under real use.

That's a deliberate ordering. AI features are the part everyone wants to see first, but they're also the easiest part to bolt onto a solid foundation later — and the hardest part to retrofit onto a shaky one. Sprint 3 is the job import engine (pulling structured data from a URL instead of manual entry), which is the first feature that actually removes work from the user rather than just organizing work they already did manually.

What's next

The roadmap from here follows the same logic — get the mechanical parts solid, then layer intelligence on top:

1. Sprint 3B — AI Job Intelligence: automatic summaries, extracted skills, salary signals, and risk flags pulled from a job posting.
2. Sprint 3C — Interview Workspace: STAR-story prep and research notes attached directly to the opportunity, not scattered across notes apps.
3. Sprint 4 — n8n Automation: reports and reminders that run without me (or the user) having to remember to trigger them.

What I'd tell myself at the start

A few things held up better than I expected, and a few things I'd only fully believe once I'd lived through them:

• Real, personally-felt problems make for stronger products than feature lists. I never had to convince myself ViaNova was worth building — I was the first frustrated user.
• Architecture-first feels slow in week one and feels like the only reason things aren't on fire by week eight.
• Designing around a workflow ("what does someone actually do the day an interview email arrives?") produces a more intuitive product than designing around pages ("what screens do we need?").
• Separating concerns early is what makes it possible to add AI and automation later without destabilizing everything that already works.

ViaNova is still in active development, and the full architecture and roadmap are documented on its project page if you want the more structured version of this same story.