Building Useminty —
from frustration to shipped.
A solo product design case study on how a personal frustration with invoicing in Word documents became a fully live, working SaaS product — designed and built in 6 weeks.
Role
Founding Product Designer
Timeline
6 weeks · idea → launch
Stack
Next.js · Tailwind · Prisma
Status
Live & growing
01 — The Problem
"I was invoicing in Word. Something had to change."
The story behind Useminty starts with a very common frustration. As a freelancer, I was managing invoices the way most people still do — copying a Word template, updating the number manually, saving as PDF, and sending it via email. Every time.
"After months of invoicing in Word, I realised it was impossible to maintain and track. When vibe coding and AI tools became powerful enough, I decided to try building my own solution. I built the core in hours — perfectly fit for my needs. Then I iterated more and more. And I simply couldn't stop.
The real pain points I experienced:
- No way to track which invoices were paid or overdue
- Re-typing client details on every single invoice
- Manual invoice numbering (and sometimes forgetting to increment)
- No consistent formatting — every PDF looked slightly different
- No revenue overview — had to count manually in a spreadsheet
- Zero confidence the PDF would look professional on the client's end
What I needed (but couldn't find):
- Create a professional invoice in under 60 seconds
- Automatically track payment status without a spreadsheet
- See a real-time revenue overview at a glance
- Reuse client data without re-entering it every time
- Download a polished PDF with zero formatting effort
- Something free that didn't feel like accounting software
The old workflow — before Useminty
Open Word template
Change invoice number
✕ painfulRe-type client details
✕ painfulFormat line items
✕ painfulExport as PDF
Send via email
Track in spreadsheet
✕ painfulHope nothing's missing
✕ painfulSteps 02, 03, 04, 07, 08 are error-prone, repetitive, or mentally taxing every single time.
02 — Competitive Landscape
The market has tools. None felt right.
Before writing a single line of code, I spent time researching every major invoicing tool available. The conclusion: the market is either too complex, too expensive, or designed for accountants — not freelancers.
| Tool | Free tier | Simple UI | Analytics | Fast invoicing | The problem |
|---|---|---|---|---|---|
| FreshBooks | Expensive, complex, designed for accounting teams | ||||
| Wave | Clunky UI, aggressive upsell, feels overwhelming | ||||
| QuickBooks | Enterprise-grade complexity, steep learning curve | ||||
| Bonsai | Good UX but expensive, not built for EU freelancers | ||||
| Invoice Ninja | Open source but dated interface, difficult to set up | ||||
| Zoho Invoice | Part of a huge ecosystem — feels bloated and corporate | ||||
| Useminty | None — this is exactly what was missing |
The complexity trap
Most tools are built for businesses with dedicated accounting teams. They include bank reconciliation, payroll, tax filing — features a solo freelancer will never touch, but they clutter the UI.
The pricing wall
Almost every quality tool gates core features behind paid plans starting at $15–$30/month. For a freelancer just starting out, that's a significant ask before they've even sent their first invoice.
The UX gap
Tools that are free often feel that way. Dated interfaces, unclear workflows, and no real-time feedback make the process slower than just using Word — which defeats the purpose entirely.
03 — Target User
One primary user. Designed around them completely.
Rather than trying to serve everyone, I designed Useminty for a very specific person. Staying laser-focused on this persona drove every design and scope decision.
The Independent Professional
Primary persona — core design target
Jobs to be done
Using the JTBD framework, I mapped what users are actually trying to accomplish — not just what features they want.
- When I finish a project — I want to invoice quickly so I can get paid without disrupting my flow
- When a payment is late — I want to know immediately so I can follow up professionally
- At month-end — I want to see my earnings at a glance without touching a spreadsheet
- When onboarding a new client — I want to look professional so the client trusts me from day one
What this user is NOT
They are not an accountant. They don't need double-entry bookkeeping, bank reconciliation, payroll, or tax filing. Building these features would have been scope creep that undermined the core value proposition.
04 — The Process
From idea to shipped in 6 weeks.
Because I was both designer and builder, the process was non-linear and iterative. Design decisions were made in code, and engineering constraints shaped design choices in real time.
Discovery & Research
- Documented personal pain points in detail
- Mapped the competitive landscape (6+ tools)
- Defined the target user persona
- Established the core hypothesis: 'Invoice in under 60 seconds'
- Decided on tech stack: Next.js, Tailwind, Prisma, Vercel
Architecture & Visual Design
- Defined the full information architecture
- Established color system: teal + mint
- Chose Outfit as the primary typeface
- Designed core components: invoice card, status badges, forms
- Created the invoice PDF template design
Build — MVP Core
- Built authentication (Google OAuth + email magic link)
- Invoice builder with real-time PDF preview
- Multi-currency support (30+ currencies, auto-convert)
- VAT, tax configuration and line item logic
- Multiple companies from a single account
- Complex smart analytics dashboard (revenue, DSO, pipeline)
- PDF generation pipeline (Puppeteer/Chromium on Vercel)
Polish, Launch & Stripe
- Client management with invoice filtering
- Free / Pro tier architecture and gating logic
- Stripe subscription model (Pro plan billing)
- Stripe Connect — client-side invoicing, pay via Stripe
- Landing page design and copy
- SEO-optimised pages and sitemap
- Final QA across desktop and mobile
- Vercel production deployment · useminty.app
05 — Key Design Decisions
Every decision has a reason.
These are the most significant design and product decisions made during the build of Useminty — including what was rejected, what was chosen, and why. Good design is as much about what you say no to as what you ship.
"Under 60 seconds" as the design north star
Building feature-first — start with invoice templates, custom fields, tax configurations, integrations, and add speed later.
Establishing a single measurable constraint from day one: every user must be able to create a complete, professional invoice in under 60 seconds. Every feature was evaluated against this bar.
Why this mattered
A north star metric forces brutal prioritisation. If a feature adds complexity without meaningfully helping the user get to a sent invoice faster, it doesn't ship in v1. This constraint shaped the entire product — the invoice builder layout, the client pre-fill, the auto-numbering, and even the PDF template simplicity.
Real-time PDF preview vs. form-submit-then-see flow
A standard form-based flow: user fills out all fields, hits 'Generate', and then sees the PDF on a separate page or download.
A live, split-screen invoice builder: the left side is the form, the right side is the rendered PDF preview updating in real time as the user types.
Why this mattered
Confidence is the most important feeling during invoice creation. Users need to see exactly what their client will receive before they commit. The real-time preview eliminates the 'generate and hope' anxiety and dramatically reduces mistakes. The tradeoff was technical complexity (live PDF rendering is expensive), but the UX gain was non-negotiable.
Teal + Mint color system instead of the industry default blue
Following the category convention — using blue (the color of every major invoicing tool: FreshBooks, Wave, QuickBooks, Stripe). Safe, familiar, expected.
A distinctive teal (#094347) paired with a fresh mint green (#2DD785). Deep teal as the primary brand anchor, mint green as the energetic accent — and the literal source of the name 'Minty'.
Why this mattered
In a crowded space, visual differentiation is a marketing asset. The deep teal communicates trust, seriousness, and professionalism — without the coldness of corporate blue. The mint accent injects energy and makes the product feel alive and fresh. The name 'Useminty' emerged directly from this color direction, making the brand and visual identity deeply connected.
Outfit typeface for personality over generic system fonts
Inter alone (used by Linear, Notion, Vercel) — clean and readable, but ubiquitous. Or Plus Jakarta Sans — geometric but with no distinctive personality.
Outfit as the primary display and UI typeface. Geometric, modern, slightly rounded terminals that communicate approachability without sacrificing professionalism. Inter reserved for dense data contexts where legibility is critical.
Why this mattered
Typography is the single biggest contributor to a product's perceived personality. At a time when every SaaS uses Inter or Geist, Outfit stands out immediately. It reads well at all sizes, looks beautiful in headings, and aligns with the brand's promise: professional but human, structured but not cold.
Deliberately not building: email sending, templates, and mobile app at launch
Shipping a 'complete' product with email sending directly from the app, multiple invoice templates, payment links, and a native mobile experience before launch.
Ship the smallest product that delivers the core value. Users send invoices from their own email. One clean PDF template. Web-only. Validate the core loop first, then expand.
Why this mattered
Scope creep is the #1 reason products never ship. Each cut feature represented weeks of additional build time and new failure points. The core loop — create invoice, download PDF, send it yourself — is the whole product. Everything else is optimisation. Shipping with constraints was a deliberate act of product discipline, not a limitation.
Analytics built into the MVP, not added later
Treating analytics as a Phase 2 feature — ship the invoice builder first, add a dashboard 'when there's time'.
Building a full analytics dashboard into the v1 MVP: revenue overview, payment status breakdown, top clients, unpaid pipeline, and payment speed metrics.
Why this mattered
Analytics is the difference between an invoicing tool and a business tool. Without it, Useminty would have felt like a fancier Word template. The dashboard is the reason users return to the app daily — not just when they need to create an invoice. It also elevated the perceived value significantly, making the free tier feel genuinely substantial.
No forced onboarding wizard — land on the dashboard immediately
A multi-step onboarding flow (step 1: add company, step 2: invite team, step 3: set preferences) that gates access to the main product.
Users land directly on the dashboard after sign-up. A subtle onboarding nudge prompts them to add their first company, but they can explore the interface freely from the first second.
Why this mattered
Onboarding wizards communicate distrust — 'we don't believe you can figure this out.' Useminty's core promise is simplicity. Forcing a wizard before showing the product contradicts that promise. The real test: can a user find the 'Create Invoice' button without being told? The answer should be yes. If it isn't, fix the UI — don't add a tutorial.
06 — Visual Design System
A design system built for speed and clarity.
Every element was designed to work together. Not a comprehensive component library, but a cohesive, intentional set of decisions that make the product feel like one thing — not a collection of parts.
Color System
Two brand colors, slate neutrals, and semantic status colors.
Primary — Deep Teal
50
100
200
300
400
500
600 — Brand
700
800
Secondary — Mint Green
50
100
300
400 — Accent
500
600
Status Colors
Typography
Outfit for display and UI. Inter for dense data contexts.
Outfit — Headlines & UI
Invoice in under 60 seconds.
Scale
Core Components
Consistent, reusable patterns across the entire product.
Buttons
Card variants
Default card
White bg · slate-200 border
Muted card
slate-50 bg · slate-100 border
Brand card
Primary-600 bg · used for CTAs
Radius & Shadow
rounded-xl — 12px
rounded-2xl — 16px
rounded-full — pills
shadow-md — floating cards
07 — Feature Showcase
The product, screen by screen.
Every screen was designed to do one thing well. No clutter, no second-guessing. Here's what shipped in v1.
Dashboard
The first screen users see after signing in. Designed to answer three questions instantly: How much have I earned? What's unpaid? What needs attention?
- Revenue overview with monthly trend
- Quick-access 'New invoice' button always visible
- Recent invoices with live status badges
- Unpaid pipeline amount highlighted
- Clean empty state with clear next action for new users
PDF Invoice Output
The PDF is the product's external face — it's what clients see. Significant design effort went into making every generated invoice look professional, clean, and trustworthy. It needed to look better than a Word template, not just different.
- Company branding in the header (logo, name, address)
- Clear 'Bill to' and payment details section
- Itemised line table with quantity, price, and totals
- VAT breakdown and final amount highlighted
- Consistent A4 formatting with white-space discipline
- Generated server-side via Puppeteer for pixel-perfect output
Analytics Dashboard
The feature that elevates Useminty from an invoicing tool to a business tool. Designed to give freelancers the financial clarity they'd otherwise need a spreadsheet or accountant to produce.
- Monthly revenue chart with period-over-period comparison
- Payment status breakdown (paid, pending, overdue)
- Top clients by revenue share
- Unpaid pipeline — expected this week and this month
- Days Sales Outstanding (payment speed tracker)
- Monthly breakdown table — invoices issued and total revenue
Client Management
Clients are the backbone of the invoicing workflow. Saving client details once and reusing them infinitely is one of the core time-saving features. The client list also surfaces invoice history per client.
- Unlimited clients on free and pro plans
- Client details auto-populate on new invoices
- Per-client invoice history and revenue
- Multiple companies from one account
- Clean empty state guides new users to their first action
08 — Reflection
What I'd do differently.
Honest reflection is where the best learning happens. These aren't failures — they're decisions that made sense at the time but I'd approach differently with the benefit of hindsight.
User testing before build, not after
I validated the concept mostly through personal experience and competitive research. Even 5 informal user interviews with fellow freelancers before writing a line of code would have surfaced edge cases and unexpected needs earlier. I compensated with fast iteration after launch, but earlier feedback would have been valuable.
Design system documentation from day one
Because I was both designer and developer, design decisions lived in my head rather than in a documented system. This worked fine solo, but as soon as a second person touches this codebase (or as my own memory fades), the reasoning behind component decisions is lost. A living Figma file tracking the system would fix this.
Mobile-first from the start, not mobile-adapted
Useminty was designed desktop-first. The mobile experience works, but it was adapted rather than designed. Given that many freelancers check their invoice status on their phone, a mobile-first approach to at least the dashboard and status views would have produced a better experience on small screens.
Earlier focus on the 'aha moment' funnel
The product's aha moment — the first time a user creates and downloads a beautiful PDF in under 60 seconds — is powerful. But I didn't design the sign-up → first invoice funnel as deliberately as I should have. Reducing friction on that specific path would have been the highest-leverage design work in the early days.
What's Next
The roadmap.
Useminty shipped as an MVP, not a finished product. The roadmap is driven by user feedback, business model requirements, and the north star of making independent professionals genuinely better at running their business.
- Pro plan launch with pricing
- Custom invoice branding (logo, colors)
- AI-powered invoice generation
- XML invoice export (EU compliance)
- Recurring invoice automation
- Batch invoice download
- Client payment portal
- Email invoices from Useminty
- Mobile app (iOS / Android)
- Accounting integrations (Xero, QuickBooks)
- Team accounts and collaboration
- Launch on Product Hunt
- Publish this case study
- Share on design & dev forums
- LinkedIn public launch
- First 50 beta testers 🤞
Takeaways
What building Useminty taught me.
Ship beats perfect
A live, imperfect product gives you more information in a week than months of planning. The decision to ship the MVP — with known limitations — was the best one made.
Constraints clarify thinking
The '60 seconds' constraint acted like a filter. Every proposed feature had to pass through it. Without a constraint, scope expands indefinitely.
Design and engineering are one loop
Being both designer and developer meant that technical constraints shaped design in real time — and design decisions were immediately testable. The feedback loop was hours, not weeks.
The name should come from the brand
'Useminty' emerged from the color direction — the mint green accent. When the name and the visual identity are genuinely connected, the brand feels coherent from the inside out.
Analytics is not a feature — it's retention
The analytics dashboard is why users come back to Useminty even when they're not invoicing. It's the stickiest part of the product, and it almost didn't ship in v1.
Solve your own problem first
Building for a frustration you personally live with gives you an unfair advantage: you already know what 'done' feels like. You can't fake that clarity.
Before we go live — an honest note
The real concerns about vibe coding as a designer.
Vibe coding changed how I build. But it also introduced a set of concerns that I don't think get talked about enough — especially for non-technical creators shipping real products with real users and real money involved.
Security & data safety
As a designer with no deep backend background, I genuinely don't fully know how secure the platform is at every layer. Data encryption, session handling, token storage — I've relied on AI to implement these correctly. That's a lot of trust to place in a generated codebase you can't fully audit yourself.
Payment provider trust
Integrating Stripe is one thing. Understanding every edge case around failed payments, webhook security, refund logic, and subscription state management is another. I implemented it, it works — but I'm not 100% confident I know exactly what could go wrong. That uncertainty is uncomfortable when real money is involved.
Losing design thinking to coding mode
The biggest surprise: vibe coding pulled me out of my design mindset entirely. Instead of thinking about user flows, edge cases, and experience quality — I found myself thinking about bug fixes, compiler errors, and deployment configs. The two modes are fundamentally different, and switching between them constantly is exhausting and costly.
Missing states & edge cases
When you build with AI at speed, it's easy to cover the happy path and miss everything else. Empty states, loading states, error states, partially-filled forms, session timeouts — these don't always get built unless you explicitly ask for them. I caught several gaps only after using the product myself.
Responsive design as an afterthought
Vibe coding tends to produce desktop-first layouts by default. Handling different viewport sizes — mobile, tablet, large screens — requires deliberate attention that's easy to skip when you're moving fast. Several components needed revisiting specifically for smaller screens.
You ship code you don't fully own
Most vibe coders don't fully understand every line in their codebase. That creates a dependency: when something breaks in an unexpected way, you're back in the AI chat trying to diagnose something you didn't write. It's a different relationship with your product than building from scratch — and it has real maintenance implications.
The bottom line
Vibe coding is genuinely powerful. But it's not a replacement for engineering rigour or design thinking — it's a tool that amplifies your pace while compressing your visibility into what's actually happening.
If you're a designer or non-technical founder building with AI: ship fast, yes — but take the time to audit your security model, test every state, and never assume the AI got the edge cases right.
See the product
Useminty is live. Try it yourself.
Everything described in this case study is live and working at useminty.app. Free to use — no credit card required.
Tools used to build Useminty
Design · Engineering · AI · Infrastructure
Claude Code
AI coding assistant
Figma
Branding & UI design
Gemini
User research & insights
Next.js
React framework
Tailwind CSS
Styling & UI system
Node.js
Backend runtime
Supabase
Database & storage
Prisma
ORM & schema
NextAuth
Authentication
Resend
Email delivery
Puppeteer
PDF generation
Vercel
Deployment & hosting
Stripe
Payments infrastructure