Selected work
SheetDriver
A platform that sells Excel-based business dashboards to small business operators, restaurant owners, salon managers, contractors, who need to understand their data but don't have a data team. The design problem: how do you get someone skeptical of software to trust you with their business data, pay for something they can't fully try, and then actually use it?
Key decisions
- Free "Test Drive" tier with real tools, reduces friction without devaluing the paid product
- Zero dark patterns, explicit opt-in at every step, no surprise upsells, honest copy throughout
- Token-based download delivery, feels trustworthy and deliberate rather than like a file dump
- Tools designed around the operator's workflow, not around what's convenient to build
- No fabricated social proof, trust built through transparency, not manufactured signals
SheetDriver, lead harvesting pipeline
SheetDriver needs customers. Rather than buying a list, I built a lead generation workflow directly into the admin, integrating with the Hunter.io API to discover, domain-search, and verify business email contacts by type and location. The design problem: a multi-step async process (discover → search → verify → import) that needs to feel simple and trustworthy, surface quota usage clearly, and not lose the user in the middle of a 3-step API chain.
Key decisions
- Quota display at the top of the modal, users see what they have before they commit to spending it
- Numbered step preview sets expectations before the process starts, no surprise wait states
- Business type and headcount filters surface only the parameters that matter for SheetDriver's target market
- Single CTA at the bottom, no ambiguity about what happens when you click it
SheetDriver Admin, the other side of the product
Every customer-facing product has a back room. This is SheetDriver's, a full admin dashboard for managing the platform's catalog, clients, projects, leads, billing, and analytics. Designing both sides of the product meant thinking about two completely different users with completely different needs: a small business owner buying a tool, and an operator (me) running the business that sells it. Same codebase, different contexts, different design problems.
Key decisions
- Sidebar navigation grouped by function (Operations, Finance, Sales, Catalog), mirrors how the business actually thinks, not how the database is structured
- Tools table with inline status management, tag filtering, and homepage toggle, the most frequent tasks surface at a glance without drilling into individual records
- Drag-handle reordering on catalog items, direct manipulation beats form fields for positional data
- Same design language as the customer-facing site, one visual system, two audiences, consistent component vocabulary throughout