Lifecycle first
Draft, sent, viewed, overdue, paid, and void states define what the user can do next.
Back to Work
InvoiceBirds
A production billing workspace for freelancers and small businesses—covering document creation, invoice lifecycle, client management, expenses, payments, reporting, and the operational details between them.
Next.jsTailwind CSSNestJSNext.js API RoutesSupabaseStripe
Overview
Turning financial admin into one workflow
Small businesses often split invoices, payments, client records, expenses, and reporting across several tools. Every handoff adds another place for a document state, balance, or customer detail to drift out of sync.
InvoiceBirds brings those jobs into a single operating model. A document can move from draft to delivery and payment while the surrounding client and expense context remains close at hand.
My work focused on making that depth feel calm: reusable document controls, clear lifecycle states, consistent navigation, and responsive surfaces that preserve the same workflow away from the desktop.
Timeline
Feb — Sep 2025
Role
Full-Stack Contractor
Tech Stack
- • Next.js + API Routes
- • NestJS Backend
- • Tailwind CSS
- • Supabase (Database)
- • Stripe (Payments)
Deliverables
- • SaaS Web Application
- • RESTful API
- • Payment Integration
- • Client Dashboard
Product model
One financial thread, not six disconnected tools
The interface is organised around three connected jobs. Each can stand alone, but the product becomes more useful when information moves cleanly between them.
01
Compose
Build invoices and business documents through modular controls with a live visual preview.
02
Operate
Track document status, clients, expenses, and payment activity without losing the surrounding context.
03
Understand
Bring billing and spending into a shared reporting model designed for fast operational decisions.
Product surfaces
One system, multiple financial jobs
These are current product screens, not presentation mockups. The captions follow the work visible in each surface and explain how the product is structured.
Document workspace / 01
Compose the invoice and its visual system in one place
Modular controls sit beside a live document preview, keeping content, styling, payment options, and export actions inside one focused workspace.
Invoice lifecycle / 02
Every document state remains actionable
Search, filters, status groups, exports, and document actions turn the list into a working queue rather than a passive archive.
Expense operations / 03
Spending is organised around how the business works
Expense profiles group activity by team, person, department, or project, making the operational model visible without burying it in settings.
Billing workflow
A financial product is a state machine.
The interface stays calm because document, money, and operational states are explicit underneath it.
Totals stay reproducible
Currency, tax, discount, and payment metadata remain attached to the document that created them.
Clients and expenses connect
Billing activity sits beside the customer and spending context needed to understand the business.
Workflows harden together
Validation, permissions, reconciliation, and failure handling ship with the visible product surface.
Responsive product
The workflow survives the small screen
Mobile is not a scaled-down poster of the desktop app. Navigation, document controls, and list actions are reflowed around the task that matters in the moment.
Public product
A clear route into the platform
Document builder
Creation controls reflow for touch
Invoice lifecycle
Status and actions stay within reach
System architecture
Clear boundaries behind connected billing.
The stack separates experience, application rules, durable data, and payment providers without fragmenting the user journey.
Next.js workspace
Responsive document, client, expense, and reporting surfaces share reusable interaction patterns.
NestJS domain API
Billing rules, document transitions, permissions, and integrations live behind explicit modules.
Supabase foundations
Relational records preserve customers, documents, line items, expenses, and historical state.
Stripe reconciliation
Checkout, webhooks, manual payments, and invoice state converge on one auditable payment record.
Engineering Challenges
The hard parts I solved
Multi-currency billing without rounding drift
Solution · Standardised on integer-cents internally, FX conversion at write-time only, snapshotted to invoice metadata so the historical record never re-quotes. UI formatting via Intl.NumberFormat per locale.
Outcome · An issued document retains the totals and exchange context it had at issue time instead of changing with a later rate.
Stripe checkout + payment-status reconciliation
Solution · Idempotency keys on every webhook, payment events appended to a per-invoice ledger (not overwritten), with manual mark-paid for off-Stripe payments. Background reconciler reconciles Stripe + manual + invoice state every N minutes.
Outcome · Single source of truth on invoice status — no conflicting paid/unpaid displays across screens.
Reusable form patterns across 6+ document types
Solution · Extracted a primitives layer (line-item table, client picker, tax/discount calculator, signature block) that each document type composes. Validation via Zod schema per document type.
Outcome · Document types share the same line-item, client, tax, discount, and signature behaviours instead of drifting into separate form systems.
Building a SaaS billing layer?
I take on senior contract work across modern full-stack stacks with payment, multi-currency, and integration depth.