Bilnex

I led Bilnex from zero to a live product — from the first sketch and customer conversations to the first invoice sent and a platform now used by 2,000+ companies across the Baltics.

My role went beyond product design. I worked across product strategy, discovery, UX, business logic, technical decisions, prioritization, delivery, and QA — turning an ambitious idea into something a small team could actually build and ship.

In practice, that meant I wasn’t there simply to design the product. I was there to help figure out what the product should be — and then make sure we actually built it.

Team

A lean core team of 2–3 developers, with support from marketing and commercial teams.

Scope

Building a new FinTech platform from zero — combining AI/OCR digitization, PDF and e-invoicing, national and Peppol infrastructure, ERP integrations, and cross-border onboarding across multiple European markets.

Bilnex wasn’t created because Finbite needed a newer interface. Three forces were converging at once: legacy technology, regulatory change, and a business model that no longer made sense for the smallest customers.

Together, they created an opening to rethink the product from the ground up.

1 — Aging technology, rising cost of change

Finbite’s existing platform was 15 years old and built on legacy technology. Years of accumulated complexity made even small improvements increasingly expensive to implement and difficult to scale.

At some point, improving the old system becomes more expensive than asking a different question:

What should we build if we started again?

2 — Regulation was changing the market

E-invoicing was moving from a specialist workflow toward standard business infrastructure.

From July 2025, registered businesses in Estonia gained the right to require structured EN 16931-compliant e-invoices from suppliers. At the European level, the EU’s ViDA reforms are pushing cross-border B2B invoicing toward structured digital reporting and e-invoicing.

What looked like a compliance requirement was also a product opportunity: make something businesses increasingly had to do significantly easier to adopt.

3 — The economics required self-service

Finbite’s smallest business customers generated little or no direct revenue, while onboarding, questions, and churn created disproportionate support costs.

Bilnex couldn’t inherit that operating model.

Onboarding, e-invoicing activation, invoice creation, integrations, and everyday use need to work with minimal human intervention.

Self-service wasn’t a UX preference. It was part of the business model.

The first two months were deliberately spent understanding the problem before committing to the product.

I interviewed accountants, small-business owners, and Finbite’s sales and support teams to understand where existing workflows broke down, what drove support requests, what blocked sales, and what users actually expected from a modern invoicing product.

That loop didn’t end when development started. After launch, Bilnex’s own support channel became a continuous source of product discovery — exposing friction, missing cases, and new opportunities as real businesses began using the platform.

Looking beyond the existing product

Starting from zero also meant resisting the temptation to simply rebuild Finbite with a newer interface.

I benchmarked invoicing and accounting products across the Baltics, Europe, and the US — looking not only at features, but at how different products handled complexity, onboarding, trust, automation, and the transition from first use to everyday workflow.

The goal wasn’t to copy the best competitor.

It was to understand the category well enough to decide where Bilnex should follow convention, where it should simplify it, and where we had an opportunity to do something better.

The opportunity wasn’t to build another accounting system. It was to make invoicing infrastructure disappear into a product that small businesses could understand without becoming invoicing experts.

That direction eventually shaped everything from product structure and interaction patterns to tone, visual language, and the feeling each screen needed to create before a user read a single word.

Starting from zero meant defining not only how Bilnex worked, but how it should feel.

I developed the visual system alongside the product itself — typography, color, hierarchy, components, spacing, and the interaction language that would eventually become the foundation for every screen.

I studied some of the strongest financial products around us, including Wise and LHV, not to reproduce their aesthetic but to understand what made them feel clear, contemporary, and trustworthy.

Green became the defining color for Bilnex. It gave the product energy and forward movement while still feeling at home in financial software — a deliberate contrast to the heavier, more institutional language common in the category.

Paired with a darker secondary palette, generous light space, and carefully chosen typography, it created the character we wanted Bilnex to have:

financial infrastructure underneath, a modern product on the surface.

The system was designed to scale from a simple onboarding screen to dense invoice workflows without losing that clarity.

1 — Make it feel like the future, not the system it replaced

Bilnex needed to feel distinctly separate from the legacy product it would eventually replace.

I built the visual language around an energetic, forward-moving green, balanced by a darker secondary palette for depth and light neutrals for clarity and space.

The intention wasn’t simply to make Bilnex look modern. It needed to signal something before the user read a word: this is simpler, lighter, and built for what comes next.

2 — Ship the right compromise

The original vision was a single intelligent invoice generator that could determine the right invoice type automatically.

It was also too expensive to build within the MVP timeline.

Instead of delaying the product, we separated PDF, e-invoice, and Peppol into explicit paths. It wasn’t the ideal end-state, but it respected an important reality: each path had different activation and verification requirements, ranging from almost none to digital confirmation by a company board member.

The decision protected the larger vision while giving us something understandable, technically achievable, and useful enough to ship.

The goal wasn’t to build the final product. It was to avoid building an MVP that would trap us in the wrong direction.

3 — Turn activation into progress, not paperwork

E-invoicing and Peppol introduce concepts most small-business owners shouldn’t need to become experts in.

So instead of exposing the entire setup process as one long form, I designed onboarding as a progressive checklist: one understandable decision at a time, with clear feedback on what was active, what remained, and what could safely be postponed.

Users could activate e-invoicing and Peppol, start with PDF invoicing, or add capabilities later as they needed them.

This reduced a technically complex infrastructure setup into a sequence of manageable decisions — while keeping the product genuinely self-service.

The result: roughly 80% of new registrations activate e-invoicing, while 10–15% start with PDF invoicing alone.

Designed Beyond Estonia

Bilnex was designed for expansion from the start, not retrofitted for it later.

The product architecture and onboarding were built to support businesses across markets, with Estonia, Latvia, and Lithuania first and Finland next.

This wasn’t expansion for expansion’s sake. Existing invoice flows already showed meaningful cross-border activity across the Baltics and Nordics — giving us real evidence for where the product needed to go next.

The principle was simple: build locally enough to solve the problem well, but structurally ready to travel.

A product bet, not an obvious feature

Digitization was one of the most debated decisions in Bilnex.

The argument against it was reasonable: as structured e-invoicing becomes standard, the need to extract data from PDFs and scanned documents should eventually decline.

My view was that “eventually” mattered.

That transition will take years, and businesses still operate in a mixed reality of e-invoices, PDFs, supplier documents, and receipts. Removing digitization because the future is structured would have made the product less useful during the transition required to get there.

So we treated digitization as a bridge between the invoicing world businesses have today and the one they’re moving toward.

OCR wasn’t enough

Traditional OCR could reliably identify invoice basics — issuer, total, dates — but struggled with the part that often matters most: line items, especially on inconsistent documents and scanned receipts.

The solution was architectural rather than simply choosing a better OCR engine.

We built a multi-layer extraction system using Gemini. When extraction gets something wrong, the user corrects it, and Bilnex retains both the original interpretation and the correction. When a sufficiently similar document appears again — for example, from the same supplier with the same structure — that previous correction can help resolve it more accurately.

Separate intelligence from memory

The system deliberately separates two layers.

Gemini handles extraction, while Bilnex owns the correction memory.

That distinction matters. The product’s accumulated knowledge isn’t tied entirely to one external model — giving us more control if models change, availability becomes unreliable, or inference costs shift over time.

The LLM can change.
The product’s memory remains ours.

Trust through correction

For financial data, automation without accountability isn’t enough.

Extracted fields remain visible for user confirmation rather than disappearing behind an automated decision. Low-confidence values are highlighted, directing attention to exactly where human judgment is needed.

The goal isn’t to remove the user from the process.

It’s to turn minutes of manual entry into seconds of informed verification — while keeping the user certain about what will actually enter the system.

Designing the End-to-End System

Bilnex wasn’t designed as a collection of separate invoice features. I mapped the product as one continuous flow — from an incoming document to structured financial data ready for accounting.

A paper receipt or PDF is entered through AI/OCR extraction, where its contents are identified and structured.

The user then verifies or corrects the extracted data. This is the critical human checkpoint in the flow, so the interaction is deliberately designed to take seconds rather than turn into another data-entry task.

Once confirmed, the invoice becomes structured data that can continue through the wider workflow — whether it originated as a PDF, was sent or received as an e-invoice or Peppol document, or needs to move into the customer’s accounting system through an ERP integration.

Each stage is designed to hand clean, confirmed data to the next instead of requiring the user to repeatedly enter, copy, or reconcile the same information across systems.

The bigger idea was simple:

Don’t optimize each step in isolation. Remove the handoffs between them.

That’s what makes the ambition of “minutes to the first invoice, seconds after that” possible. Bilnex isn’t simply digitizing documents — it’s reducing the manual chain between a document, a business, its accountant, and the systems around them.