Back
Product Design · Product Lead

Invoices: billing built into the field-service workflow

I led the design and product definition of Menaia's first-party invoicing system, letting service businesses bill clients, take payments, and track balances without ever leaving the platform.

Invoices list page with financial summary cards: Project Value, Not Invoiced, Collected, Due, and Overdue
Project Statement

Menaia takes a service business from first lead to finished job (estimates, scheduling, the works) but stopped short at the one step that actually pays the bills: getting paid.

Menaia is an operations platform for home- and field-service companies. On it, teams win a lead, build an estimate, get a proposal signed, and run the job without leaving the platform. But to invoice the client and chase payment, they had to drop out to a separate tool — a break that cost time, forced manual re-entry, and scattered financial data across systems that never quite agreed.

Phase 1 set out to close that gap. The goals:

Process

I treated this as a systems problem before a screens problem. Before designing a single invoice, I needed to understand how these businesses actually bill — and where the manual work was hiding.

01

Discovery & Research

The project kicked off with qualitative research. I ran multiple user-testing sessions to learn how field-service businesses handle invoicing today inside their existing software — what worked, what didn't, and which frustrations surfaced again and again.

The goal wasn't to rebuild functionality they already had elsewhere. It was to understand the core problems admins face day to day, so we could lay down the foundational billing tools and solve pain points they'd been living with for years.

02

Ideation & Iteration

Research pointed clearly to two paths. Smaller organizations needed the flexibility to spin up a quick, custom invoice on the fly. Enterprise teams needed to pull invoices straight from signed proposals — cutting manual re-entry and the risk of the same numbers living differently in two places.

I designed both flows from low to high fidelity, running user-testing sessions at every stage to gather feedback and confirm I was heading in the right direction before committing to the build.

03

Technical partnership

Throughout, I partnered closely with my engineering counterpart. As I designed, we were jointly shaping the backend infrastructure and data models the system would sit on.

That early collaboration meant the foundations were laid deliberately — built to integrate with Stripe for payment processing and QuickBooks for accounting down the line, rather than bolted on after the fact.

test, learn, loop back post-launch learnings feed the next cycle Research Ideation Iteration Launch Improvements
The process was never a straight line — research, ideation, and iteration looped on each other as feedback came in, and even after launch, what we learned fed straight back into the next cycle.
Shipped Design

Phase 1 shipped the full core invoicing surface (creation, payments, and financial visibility) plus a settings area that lets each organization tailor how billing works for them.

Feature Screen Highlights. Zoom in and pan to see figma frames :)
Post Launch Improvements

Phase 1 was designed as the foundation for a deliberately phased roadmap. What we learned shaping the core directly set up what came next.

Stuff I'm low-key proud of
Systems thinking Chose a ledger and derived-status architecture over hand-set states, eliminating a whole category of financial bugs.
Product + design ownership Authored the PRD, ran technical discovery (Stripe, QuickBooks), and designed the experience end to end.
Designing for the roadmap Made explicit, documented trade-offs so Phase 1 could stand alone yet extend cleanly into payments and accounting.
Craft under constraint Balanced financial integrity (locked line items, void restrictions, audit trail) with a flow that still feels light.