UMA

One-line impact#

Built a production-ready expense automation platform that turned restaurant paper receipts into structured financial data, eliminating manual tracking friction and creating daily visibility into costs.

UMA — product overview

Snapshot#

• Role: Founding Product Design Engineer
• Timeline: 3 months (discovery, MVP, product refinement)
• Company / Client: UMA (startup)
• Platform: Web (mobile-first) + WhatsApp
• Team: CEO/COO, CTO/CPO, Product Design Engineer (me)
• Scope: Product strategy, UX architecture, design system, production frontend implementation
• Status: Production-ready, unfunded (not launched)

Executive summary#

UMA was a SaaS platform designed to help restaurant and bar owners automate expense tracking by photographing receipts. Instead of managing paper invoices and manual entry, users could upload receipts via WhatsApp or the web app, and AI agents would extract data, categorize expenses, and provide real-time financial visibility through KPI dashboards and detailed reports.

My role was founding product design engineer. I owned product definition and UX strategy alongside the CTO, designed the complete design system, and wrote production-ready frontend code using React, Tailwind, and AI-assisted workflows. The product shipped with end-to-end functionality across both interfaces, but the company could not secure funding to launch.

Dual-interface concept

Context#

In mid-2025, restaurant owners still relied heavily on paper receipts and manual expense tracking. This created friction in daily operations and made it nearly impossible to have real-time visibility into costs, cash flow, or profitability. Accountants and financial advisors struggled to get clean data from their restaurant clients for tax filings and financial planning.

The opportunity was clear: automate the most painful part of expense management — data capture — using technology that fit into existing workflows. Most restaurant owners already used WhatsApp for business communication. By meeting them there, we could eliminate the friction of switching to a new app or visiting a web portal for routine uploads.

The company was attempting to establish a new category in the expense-management space. Unlike general accounting software (which required extensive setup and were designed for accountants, not operators), UMA was built specifically for the restaurant vertical, with a focus on speed and accessibility.

Problem statement#

User problem#

Restaurant owners faced three core pain points:

1. Friction in capture: Remembering to scan or photograph receipts, then manually entering data into a system was time-consuming and error-prone.
2. No real-time visibility: Most owners only reconciled expenses monthly or quarterly, missing opportunities to control costs as they happened.
3. Difficulty sharing with advisors: When tax time came, getting organized financial data to accountants or financial advisors required manual compilation, spreadsheets, and back-and-forth clarification.

Business problem#

The business needed to:

1. Establish product-market fit in a new vertical: Prove that a WhatsApp-first, AI-powered expense platform could acquire and retain restaurant owners.
2. Differentiate in a crowded space: General expense-tracking apps existed, but none were specifically built for restaurants with AI extraction + WhatsApp accessibility.
3. Create a defensible moat: The combination of WhatsApp distribution + proprietary AI extraction logic + mobile-first UX could create network and switching costs.
4. Enable B2B expansion: Clean expense data and standardized reporting could unlock partnerships with accountants, financial advisors, and eventually POS systems.

Product problem#

The core product challenge was not simply automating receipt capture. It was translating a broad business vision — "help restaurant owners track expenses" — into a coherent product structure that:

• Made uploading receipts frictionless (WhatsApp, not another app)
• Turned unstructured image data into reliable, categorized financial information
• Gave owners meaningful insights without overwhelming them with complexity
• Supported multiple workflows (casual daily uploads via WhatsApp, deeper analysis via web)
• Provided data clean enough for external stakeholders (accountants, advisors) to use directly

Problem space — three intertwined challenges

My role#

I joined as founding product design engineer with 10% equity. I owned product definition and UX strategy in close collaboration with the CTO, designed the complete design system from scratch, and wrote production-ready frontend code.

Responsibilities:

• Defined core product flows and UX architecture (dual-interface strategy, dashboard structure, data export logic)
• Worked with CEO and restaurant owner advisors to validate which financial metrics mattered most
• Designed the complete design system (components, tokens, semantic colors, responsive behavior)
• Wrote 100% of production frontend code in React + Tailwind using Cursor with Figma MCP integration
• Collaborated with CTO on product logic clarification, implementation constraints, and data API integration
• Advised on subscription strategy and post-launch product roadmap

Constraints#

Real constraints shaped every decision:

• Team size: Three people across product, engineering, and operations. I handled design, frontend, and partial branding work. No dedicated QA, no design reviews from peers.
• Timeline pressure: 1 month to discovery + MVP, 2 additional months to launch-ready product. This meant ruthless prioritization — what shipped, what was cut.
• No user research infrastructure: We validated metrics through conversations with the CEO (a restaurant owner himself) and his peers, but no formal user testing or surveys.
• Technology learning curve: This was my first time using AI-assisted code generation (Cursor + Claude Opus/Sonnet). The workflow was productive but required iterative refinement.
• Processing latency: AI extraction took 5–10 seconds per image. This had to be designed for — users needed clear feedback that their upload was being processed.
• Funding uncertainty: The product was built toward a launch that never materialized due to inability to secure angel investment.

• Team of three

  Design + frontend + ops on one person

• 1 month to MVP

  Then 2 months to launch-ready

• No research infra

  Validated through founder + peer chats

• AI-assisted dev, first time

  Cursor + Claude, learned on the job

• 5–10s extraction latency

  Had to design for asynchronous feedback

• Funding uncertain

  Built toward a launch that never closed

Product strategy#

The strategy was guided by three core principles:

1. Accessibility over comprehensiveness. Remove barriers to adoption. A restaurant owner should not need to learn a new app or change their behavior. Meet them on WhatsApp.

2. Depth on demand. WhatsApp handles routine uploads and quick questions. The web app is where owners go when they want to dig into data, understand trends, and export for advisors. Two interfaces, one product.

3. Build what restaurants actually need. Reject document-management views, processing queues, and approval workflows. Restaurants care about one thing: Am I making money? Show that clearly and let them drill down.

1. 01

   Accessibility over comprehensiveness

   Remove every barrier to adoption. A restaurant owner should not learn a new app or change their behaviour — meet them where they already are: WhatsApp.

2. 02

   Depth on demand

   WhatsApp handles the daily upload and quick questions. The web app is where owners go to dig into data, understand trends, and export for advisors. Two interfaces, one product.

3. 03

   Build what restaurants actually need

   Reject document-management views, processing queues, and approval workflows. Restaurants care about one thing — am I making money? — so show that first and let everything else drill from it.

Key decisions#

Process#

Before finalizing the product direction, we considered several approaches:

Option A: Mobile app (iOS + Android)#

Pros:

• Native experience, faster performance
• Push notifications for processing updates
• Offline capability

Cons:

• App store friction (approval, versioning, updates)
• Split codebase (iOS/Android/Web)
• Restaurant owners don't download apps for niche tools
• Higher build and maintenance cost

Option B: Web-only, no WhatsApp#

Pros:

• Single codebase, simpler to maintain
• Full control over UI and data flow
• Easier to build complex features

Cons:

• High friction for daily uploads (open browser, navigate, upload)
• Restaurant owners already on WhatsApp; requires behavior change
• Loses the accessibility advantage

Option C: WhatsApp-only, no web interface#

Pros:

• Maximum accessibility and distribution
• Simpler product scope
• No need to build complex dashboards

Cons:

• Limits depth of analysis and data exploration
• Financial advisors need structured, exportable data
• Can't show trends, comparisons, or custom reports
• Becomes a data collection tool, not a platform

Final direction#

We chose WhatsApp + Web because it solved the asymmetric problem:

• Upload is frictionless (WhatsApp, where they already are)
• Analysis is rich (Web dashboard, when they have time to think about it)
• Data is exportable (For advisors, for compliance, for growth)

This combination gave us the accessibility of WhatsApp with the power of a real platform. No other expense platform in the restaurant space offered this in mid-2025.

Option comparison — A / B / C vs final direction

UX architecture#

The product was structured around two complementary journeys:

Core user journeys:

1. Daily upload via WhatsApp: Owner photographs receipt → sends to UMA → AI extracts data → owner gets summary + link to invoice table. Async, no friction.

2. Weekly/monthly review via Web: Owner opens dashboard → sees KPIs (revenue, expenses, net profit, profitability) → drills into breakdown by category → reviews individual invoices → edits/corrects categorization → asks questions via chat.

3. Month-end analysis: Owner reviews spending trends over time → identifies cost spikes → exports data to share with accountant or financial advisor.

4. Categorization training: When AI misclassifies an expense, owner corrects it in the invoice table. This trains the model for future uploads.

Important states:

• Processing: Receipt uploaded, AI is extracting data. User sees "we're processing your receipt" message in WhatsApp.
• Processed: Data extracted and categorized. User sees summary in WhatsApp + link to table.
• Needs review: AI confidence was low, or categorization seems off. Invoice is flagged for user attention.
• Paid / Pending / Overdue: Payment status of each invoice (from due date logic).
• Empty state: New user, no expenses uploaded yet. Onboarding prompt in web app.
• Loading: Dashboard is fetching data from Supabase. Skeleton screens for KPI cards and charts.

Final solution#

Flow 1: Receipt Upload via WhatsApp#

Problem: Most expense data starts as a physical or digital receipt. Manually entering it into a system is slow and error-prone. Owners need this to be as easy as taking a photo.

Solution: Owner sends receipt photo to UMA's WhatsApp number. The image goes to an extraction service. An AI agent processes it, categorizes the expense, and sends back a confirmation message with a summary and a link to the full invoice table in the web app.

Why it works:

• Zero friction. The phone is already in their hand.
• Immediate feedback. They know the system received it.
• Async processing. They don't wait for extraction. The system works in the background.
• Unified action. One WhatsApp conversation handles both capture and Q&A.

WhatsApp upload flow

Flow 2: Dashboard + KPI Overview#

Problem: Owners need a quick answer: Is my business making money? They need this daily. But they also need to understand where money is being spent.

Solution: The dashboard shows four KPI cards (Total Revenue, Total Expenses, Net Profit, Profitability) at the top. Below, an Expenses Breakdown visualizes the top five cost categories with color-coded bars. A Spending Trends chart shows expense trajectory over the last six months.

Why it works:

• Immediate clarity. Three numbers (revenue, expenses, profit) answer the core question in seconds.
• Semantic color coding. Green = good, red = risk, yellow = warning. No cognitive load.
• Drill-down path. From KPIs to breakdown to historical trends. Complexity is layered, not overwhelming.
• Mobile-first layout. Each section stacks vertically. Easy to scan on a phone.

Dashboard — KPIs, expense breakdown, spending trends

Flow 3: Invoice Table + Categorization Control#

Problem: Owners need to see all uploaded receipts in one place, verify extraction accuracy, correct mistakes, and track payment status. They also need to train the AI by overriding incorrect categories.

Solution: A searchable, filterable table shows all invoices with columns: Supplier, Amount, Type (Invoice, Receipt, Delivery Note, Statement, etc.), Issue Date, Due Date, Status (Processed, Needs Review), Payment (Paid, Pending), and Actions. Users can click any row to view details, edit category, or mark as paid.

Why it works:

• Complete audit trail. Every expense is visible, traceable, timestamped.
• User control. Mistakes are corrected immediately. AI learns from corrections.
• Status visibility. Payment tracking reduces confusion about cash flow.
• Bulk actions. Filter by supplier or category to manage related expenses together.
• Export-ready. Clean data structure makes exporting for advisors straightforward.

Invoice table

• Uploaded

  Waiting for the extraction worker

• Processing

  AI is reading the receipt

• Needs review

  Low confidence — user verifies

• Processed

  Extracted and categorized

• Pending

  Due date in the future

• Paid

  Marked as settled

• Overdue

  Past due, still unpaid

Flow 4: Conversational Q&A via Chat#

Problem: Owners have specific questions ("What were my expenses last month?" or "How much did I spend on labor?"). Dashboards show aggregates; chat allows natural-language queries.

Solution: A chat interface in the Reports section lets owners ask questions. The AI processes the query against the expense database and responds with a summary and relevant data.

Why it works:

• Natural interaction. No need to navigate filters or run reports. Just ask.
• Contextual answers. The AI can reference specific suppliers, categories, or time periods.
• Training opportunity. Unanswered or poorly answered questions signal gaps in the product.
• Light feature. Added delight without core complexity. Users default to the dashboard, but power users love this.

Chat — natural-language reports

Design system / Design engineering#

The design system was built ground-up to support production scale:

Components:

• KPI Cards: Title, large metric, trend indicator (% change, direction arrow), subtext. Used for Revenue, Expenses, Net Profit, Profitability.
• Expense Breakdown Bar Chart: Category label, colored bar, amount, percentage, trend arrow. Five categories visible by default.
• Spending Trends Line Chart: Time-series with interactive points, dual-view toggle (6 months / 12 months).
• Invoice Table: Headers, sortable columns, row highlighting on hover, status/payment badges, row menu (edit, delete, details).
• Status Badges: Processed (green), Pending (yellow), Needs Review (orange), Overdue (red), Paid (green outline), etc.
• Navigation Sidebar: Logo, menu items (Dashboard, Documents, Reports, Chat, Settings), active state indicator.
• Buttons: Primary (lime green, full-width or inline), Secondary (outline), Danger (red), Icon buttons.
• Modals/Dialogs: Invoice detail view, category editor, confirmation dialogs.
• Form inputs: Text, number, select (for categories), date pickers. Label + input + error state.
• Empty states: Illustration + headline + CTA button.
• Loading states: Skeleton screens for cards, tables, charts.

Tokens:

• Colors: Semantic (Primary lime-green, Danger red, Warning yellow, Info blue, Neutral grays). Category colors (Food, Labor, Marketing, Operations, Admin — each with a distinct hue for visual recognition).
• Typography: System font stack, sizes (12px to 32px), weights (400, 600, 700).
• Spacing: 4px base unit (4, 8, 12, 16, 24, 32, 48px).
• Breakpoints: 320px (mobile), 768px (tablet), 1024px (desktop).
• Shadows, borders, radius: Defined globally for consistency.

Variants and responsive behavior:

• All components had mobile, tablet, and desktop variants.
• Tables collapsed to card view on mobile.
• KPI cards stacked vertically on mobile, three-column grid on desktop.
• Charts became single-metric summaries on very small screens.
• All interactive elements (buttons, inputs, badges) had hover, active, disabled, and focus states.

Engineering handoff:

• I exported Figma variables as JSON and fed them into Tailwind config, ensuring design tokens matched code tokens exactly.
• Component specs included all states, interactive behaviors, and accessibility requirements (focus states, ARIA labels).
• The CTO and I aligned on component APIs (React prop names, data structures) so implementation matched design intent.

Production considerations:

• Figma components mapped directly to React components. No visual drift.
• Cursor + Figma MCP allowed me to generate code from design, review output, and iterate rapidly.
• Manual testing focused on responsive behavior across real devices (not just browser dev tools).
• No automated component testing due to timeline, but design system was stable enough that manual regression testing caught issues.

Component inventory — 20+ components

Frontend / implementation layer#

This was the first time I used AI-assisted code generation at production scale, and it became a defining moment in my career shift from Product Designer to Product Design Engineer.

Build involvement: 100% of production frontend code (React, Tailwind, API integration, state management).

Tools and workflow:

• Figma: Complete design system, components, responsive variants.
• Cursor: Code generation and iteration using Claude Opus and Sonnet.
• Figma MCP integration: Cursor could read Figma files directly, understand component structure, and generate matching React code.
• Tailwind CSS: All styling, tokens from Figma exported to Tailwind config.
• React: Component library, hooks for state, integration with Supabase.
• Supabase: Backend database and auth. I integrated API calls into components.

Workflow:

1. Design a component or screen in Figma with all states and variants visible.
2. Use Cursor to generate React code from the design, using Figma MCP to read the file.
3. Review the output. Prompt for changes (adjust spacing, add states, fix interaction logic).
4. Iterate until the code matches the design pixel-perfectly.
5. Integrate API endpoints. Wire components to real data.
6. Test on mobile, tablet, desktop.

This was iterative and productive. Cursor's output was high-quality because I could be specific in prompts and review each iteration. I learned how to structure prompts to get buildable, clean code — not just visually correct output.

Product logic clarified:

• Dashboard data flow: Which metrics pull from which database tables? How are trends calculated? What's the time-zone handling?
• Invoice upload states: When does an invoice show "Needs Review"? What confidence threshold triggers this? How are duplicates handled?
• Category logic: How does the AI assign categories? What if the user creates a new category mid-month? Does it backfill old expenses?
• Export format: What fields are required in the export file for accountants? What order, what currency, what date format?
• Real-time sync: When a user uploads via WhatsApp, how long before it appears in the web app? Is it polled or websocket-based?

The CTO owned the backend logic, but I needed to understand it deeply to design UX that matched implementation reality. We aligned on these details to avoid building UI that couldn't be built.

Design-to-code bridge:

• Figma components → React components with exact prop names, storybook-ready.
• Color tokens, spacing, typography all synchronized between Figma and code.
• Responsive behavior tested on real devices, not assumed from breakpoints.
• No design regressions between Figma and production because every iteration was code-reviewed against the design.

Quality control:

• Manual testing on iOS Safari, Android Chrome, desktop Chrome.
• Focused on responsive layout, form input behavior, modal interactions, table scrolling on mobile.
• No automated testing, but the design system was stable and components were reused across screens, limiting regression risk.

Collaboration#

The team was small, which meant close alignment and fast iteration.

With the CTO (Adam):

• Defined which product flows the AI agent needed to handle (receipt extraction, categorization, Q&A).
• Aligned on what data the API should return so UI could display it correctly.
• Reviewed builds in staging to ensure design intent was preserved.
• Discussed edge cases (ambiguous receipts, duplicate uploads, category conflicts) and how to surface them to the user.

With the CEO (Gonzo):

• Validated product strategy with him (he was a restaurant owner, our primary user).
• Tested metric selections with his peer network. Which KPIs mattered? Which were noise?
• Understood business constraints (feature cuts, timeline pressure, roadmap priorities).
• Aligned on positioning and tone of the product.

With restaurant owner advisors (Gonzo's peers):

• Validated that the core problem (manual expense tracking) was actually painful.
• Tested dashboard metrics. Did they want to see revenue? Net profit? Profitability percentage? All three?
• Understood workflows. When do owners use the product? Morning? End of shift? Weekly?
• This was lightweight validation, not formal user research, but it shaped key decisions.

The absence of a larger team meant I owned more surface area. There was no separate QA team, no design review process, no product manager to argue with. This created speed but also risk. Decisions had to be sound because there was no safety net.

Results and impact#

The product was production-ready in 3 months. All features worked end-to-end. The codebase was clean, the design system was complete, and the experience was polished.

But the product never launched.

Results:

• Product: Fully functional, launch-ready web app + WhatsApp integration with AI-powered expense extraction and categorization.
• Design system: Complete component library (20+ components), tokens, responsive variants, documented in Figma.
• Frontend code: 100% of production React codebase, ~5,000 lines of clean, Tailwind-styled components and utilities.
• Team alignment: Product strategy, UX, and implementation were aligned. Engineering knew what to build and why.
• Validation: Metrics and workflows were validated with target users (restaurant owners). Dashboard showed the right KPIs.

Why it didn't launch:

• Unable to secure angel investment to fund the business.
• A potential business deal did not close as expected.
• The team was three people with limited runway.

The work was not a failure of product or design. It was a failure of business/fundraising. This is important to state clearly.

What the work proved:

• The product filled a real gap in the market. By mid-2026, competitors had launched similar features (WhatsApp + expense tracking) within 2–3 months of when we stopped work.
• The design system and frontend architecture were production-grade. No technical debt, no corners cut.
• The AI-assisted code workflow worked. I shipped production-ready code for the first time by combining Figma design precision with Claude's code generation and iterative refinement.
• Small teams can move fast. Three people built a differentiated, multi-interface SaaS product in 3 months.

Final state — production-ready, unfunded

What I would improve#

With more time and resources, these would be the priorities:

Performance optimization:

• The 5–10 second processing time on receipt upload was acceptable but noticeable. Optimizing extraction speed would improve perceived product quality.
• Dashboard load time on slow connections needed testing and optimization.

Instrumentation and analytics:

• We had no event tracking to understand how users actually used the product. What percentage upload via WhatsApp vs. web? How often do they review the dashboard? How many use the chat feature?
• Without this data, roadmap decisions were educated guesses.

Onboarding flow:

• We built the product for owners who understood their own expense structure. A new user with 50 expenses from day one would be lost.
• A proper onboarding flow with guided uploads, category suggestions, and early aha moments would improve retention.

Integration roadmap:

• The post-MVP plan included POS integration and inventory tracking. Without launching, we never validated whether these were must-haves or nice-to-haves.
• Testing these integrations would clarify the product direction.

Subscription model clarity:

• We planned a token-based pricing model (extract more receipts, use more tokens). We never tested price sensitivity or feature bundling with actual customers.

Final reflection#

UMA proved that I can operate as a Product Design Engineer — someone who owns product strategy, UX architecture, and production implementation in one person.

The project forced me to think across multiple layers: What does the restaurant owner actually need? How does WhatsApp change the UX compared to a web-only app? How do we structure the data so it's both useful for analysis and clean enough to export to accountants? What components do we need to build once and reuse across screens? How do we write React code from Figma designs using AI without losing quality?

Most importantly, this was the project where I learned that design and code don't live in separate worlds. By using Cursor + Figma MCP, I could design in Figma, generate code from that design, iterate on both simultaneously, and ship production-ready UI that matched the design exactly. No handoff gap. No "it looked better in Figma." No missed states or responsive breakpoint regressions.

This shift — from Designer who hands off to Code, to Design Engineer who owns the continuum from product thinking through shipped pixels — changed how I see my role. UMA was the proof of concept that this way of working actually works at production scale.

The product didn't launch for business reasons, not product reasons. But the work created the foundation — product clarity, design system, production code, team alignment — that would have made rapid iteration possible if the business had gotten the chance.

From Product Designer to Product Design Engineer