Designing two very different apps that had to feel like one product.

Dockit needed two products that behaved nothing alike, built on the same platform: a consumer app for people capturing and managing their own receipts, and a merchant admin console for retailers issuing them at scale. Same data, same backend, completely different jobs to be done.

Consumer and merchant users don’t just have different needs—they have opposite relationships with frequency and attention. Design the consumer app like a lightweight utility, and it fails the merchant, who needs density, filtering, and control. Design it like an admin tool, and you lose the consumer, who wants speed and gets none of the mental effort back.

There was also a technical layer to work through: early feasibility research into NFC and point-of-sale integration, and Apple PassKit and Google Wallet support, so receipts could be captured automatically at the point of purchase rather than relying on the user to remember. That research shaped what the product could realistically promise versus what stayed a “someday” feature.

The core insight: nobody wants to think about receipt management. The app’s entire job is to get out of the way.

• Capture-first flows. Scanning or auto-adding a receipt needed to be the fastest path in the app fewer taps than it takes to lose the paper one.
• Passive organization. Rather than asking users to categorize or tag receipts manually, the information architecture leaned on automatic grouping by merchant, date, and category, with manual edits available but never required.
• Warranty and returns surfaced proactively. Instead of a static archive, the app was designed to resurface a receipt when it mattered near a return-window deadline or a warranty expiry turning a passive record into a useful nudge.
• Wallet integration as a first-class flow, not a bolt-on building on the PassKit and Google Wallet feasibility work so receipts could live where users already expect proof of purchase to live.
• Account and data flows handled with care including designing the account-deletion flow around Firebase, since a product holding financial records needs an exit as trustworthy as its entry.

The merchant side flips every assumption. This is a tool retail staff open dozens of times a day, so density, speed of scanning information, and error-proofing mattered more than delight.

• Table-first information architecture receipts, refunds, and warranty claims needed to be scannable in bulk, filterable, and exportable, closer to a lightweight operations dashboard than a consumer app.
• Issuing flows built for volume, not one-off use designed so a staff member issuing dozens of digital receipts a day could do it with minimal friction per transaction.
• Shopify integration architecture designing how receipt issuance plugged into a merchant’s existing commerce stack, rather than asking retailers to adopt a parallel workflow.
• Permissions and account structures designed for teams, not individuals since a merchant console is rarely used by just one person.