Proving before building it
Building Circula's first Sachbezug benefit — a German tax-free voucher program — validated in two days at a trade fair before we committed to building it, so Circula could match competitors already offering it, answer clients who were asking for it, and turn a strict tax rule into something employees actually redeem.
By mid of 2026 we processed 126K+ vouchers, with 70% redeemed.
Start-to-end ownership
Filling a market gap
Circula didn't offer a Sachbezug benefit yet. Competitors did, and it was starting to cost us:
Losing deals. Competitors already offered tax-free vouchers as a benefit. Clients and prospects were asking for it directly.
No settled legal shape. Sachbezug is capped, non-cash only, and restricted to a limited merchant network — but exactly how those rules would apply to our product was still being worked out as we designed.
No visibility after issuing. Vouchers were redeemed through external merchants, outside our systems — once ordered, we had no native way to know if they were used.
The root cause tied all three together: we were designing a compliance-bound product — one where the tax law itself decides what the feature is allowed to do.
What MVP success meant for us
Validate that a Sachbezug benefit was worth building before committing engineering time to it, then design an MVP simple enough to ship within the legal constraints — one that made ordering, tracking, and redeeming vouchers straightforward for employees despite the restrictions of a capped, non-cash, limited-network benefit.
Making decisions that shaped the product...
Matching the mental model, not the status quo
Vouchers were shown on the benefits page organized by month — the same structure the underlying request was already built around. It worked as a record of what had happened, but usability testing kept surfacing the same friction: people couldn't find their own vouchers. A voucher from two months ago meant scrolling back through months to locate it.
Month-by-month structure. No extra build, and it matches how the request flow already works internally. Trades off the thing users are actually trying to do on this screen.
Search or filter on top of the existing structure. Solves findability without a bigger restructure, but layers complexity onto a structure that was the problem in the first place.
Voucher Wallet. Bigger scope, but matches how people actually think about their vouchers: not "what did I order in March," but "what do I have right now."
We went with the Voucher Wallet. Testing showed people didn't think in months at all — they thought in terms of what they were currently holding and what still needed to be used. The Wallet gave them that view directly, instead of asking them to reconstruct it from a timeline.
Filling in where the data stopped
Vouchers were issued and redeemed through external merchants — once a voucher left Circula's product, we had no visibility into whether it was actually used. Real usage tracking would have meant integrating with each merchant's redemption systems, which wasn't something we controlled or could realistically build within the timeline.
No tracking at all. Simplest to build, but leaves the wallet — and our own usage data — permanently blank.
Build merchant redemption integrations. Would give real usage data, but depends on systems we don't own, across a merchant network that was still growing. Not a realistic option for an MVP.
Let users mark vouchers as used themselves. Not verified data, but gives people a way to keep their own wallet accurate, with no external dependency.
We went with manual marking. It wasn't real tracking, but it was the only option that didn't depend on partners outside our control. The data ended up validating the call: through mid-2026, 70% of 126K+ vouchers ordered have been marked as redeemed — proof this wasn't a fallback nobody touched, but a feature people actually used to manage their benefit.
Where the experience comes alive
Building both platforms to the same depth wasn't realistic for the team or the timeline, so we had to decide where to invest first. The evidence pointed one way: most benefit submissions already happened on mobile, and the assumption going in was that people would pull up their voucher at the register — on their phone, not at a desktop.
Equal investment across web and mobile. Keeps the experience consistent across platforms, but spreads a small team across two builds instead of doing one well.
Web-first, with a simplified mobile version. Matches how a benefits admin tool is traditionally built, but works against how people actually use the benefit — in the moment, in-store, on their phone.
Mobile-first, with a simpler web version. Concentrates testing and iteration where usage already was, while still covering desktop for people who preferred managing requests there.
We went mobile-first. The redemption moment mattered most: someone standing at a register needs their voucher on the device already in their hand, not a browser tab they have to log into. We put our testing and iteration time into mobile, and shipped a simpler, functional web version for desktop use.
Business impact
Launched in early 2023, the benefit has grown steadily every month since, with adoption picking up further after the merchant network expanded. A few numbers as of mid-2026: