Oracle’s First Agentic Expense Experience
2022–2025 · Enterprise SaaS · Financial Operations · Oracle
Shipped Oracle's first Redwood mobile experience after a multi-year design impasse
I built the decision framework that reset this product's direction: audited design-system constraints, weighed tradeoffs with engineering, and defined what to preserve, simplify, or cut so the product could actually ship.
↪ Impact
✓ Shipped to first enterprise customers within 9 months
✓ Scaled from 26-user pilot to 450 cardholders within 6 months — 1,200 within 2 years
✓ First Redwood mobile product in production + integrated telemetry
✓ Rebuilt platform-product trust while delivering targeted innovation
↪ The Problem
Three years. Multiple explorations. One product vision still looking for a shippable path.
The product sat at the intersection of two valid priorities: a platform team committed to Redwood compliance and a product vision pushing toward a more mobile-native, touchless experience. The PWA architecture was already set when I joined, and much of the existing vision work had been created under a different set of assumptions. My job was to figure out what to preserve, what to adapt, and how to get the product into production without losing the ambition behind it.
Three years of vision work. None of it shippable within platform constraints.↪ The Pivot
Long Live Chat
The long-time vision had users interfacing with expenses through mobile notifications and an enhanced chat UI. Just after I joined the team, that vision hit a wall: design leadership cancelled all work on chat components, leaving us to quickly reimagine the experience. Without chat, the responsive app had to take center stage.
Only months away from the planned pilot launch, my task was to bring as much of the polished “touchless” experience to the PWA — quickly.
Sacrifices had to be made. That was fine. Shipping meant we'd finally have real data to map an actual route to the product vision, instead of another round of decks.
The chat vision that hit a wall. Without it, the responsive app had to carry the entire "touchless" promise.↪ My Approach
♠︎ Diagnosed
Mapped six non-compliant patterns across hundreds of instances to understand exactly where the real friction was.
♣︎ Rebuilt
Restored cross-functional trust by demonstrating compliance and adopting the platform team’s own established process.
♦︎ Negotiated
Showing the vision alongside real constraints persuaded people faster than pure aspiration ever had.
♥︎ Delivered
Shipped the core touchless flow first. Delivery earned far more credibility than any vision deck or mock ever could have.
Example blocker — expense receipt attachment↪ The Design
1. Phone screen density
The core interaction surface is the expense card — the thing users see most and tap most. It needed to carry merchant name, amount, date, category, receipt status, and policy flags without feeling like a data table shrunk onto a 375px screen.
I used a clear visual hierarchy: merchant and amount dominate, since that's what the user cares about first. Status sits in a chip component that changes color and label based on state. Policy information stays hidden until it's actually relevant.
The goal was a card you could glance at and immediately know, "this one needs attention" or "this one's fine," without reading anything.
The expense card and list of expenses at a glance2. Making enterprise feel mobile-native
One of the central tensions in this product was that it ran on Oracle’s Redwood design system, which at the time was still evolving its mobile support. For launch, we worked within the available component model while also identifying the enhancements needed to better support mobile usage over time. That work helped clarify where Redwood could expand, where the product needed stronger native support, and how enterprise mobile patterns could mature going forward.
The card idea itself was contentious. We believed the pattern would get us to a consumer-grade experience, but Redwood had no such component. To get across the finish line, I devised a short-term workaround, one with real usability tradeoffs.
Usability issues identified and prioritized to determine what needed to be resolved for launch and what could be scheduled for future design and releasePhased release plan for design improvements aligned with availability of features and Redwood enhancements3. What "touchless" actually means in practice
The product's name — Touchless Expenses — makes a promise: minimal manual effort. The reality of expense management is messier than that. Receipts come in different formats, OCR isn't perfect, and policy rules vary by expense type, currency, and geography. The design challenge was making the system feel effortless when automation succeeds while providing clear, non-punitive paths when it doesn't.
When a receipt is automatically matched to a credit card transaction, the user sees a clean, resolved card and takes no action. When there's a mismatch or a missing receipt, the card surfaces a gentle prompt with a clear next step. I was careful not to let error states feel like the user did something wrong. In most cases, the system was the one that failed. The tone of every status message reflects that.
When automation succeeds, the card is clean. When it doesn't, the prompt stays gentle, because the system failed, not the person.4. Telling users they might be in trouble — without making the app feel punitive
Expense policy is the third rail of this product. Employees need to know when their spending might not be approved, but nobody wants to use an app that feels like a compliance officer looking over their shoulder.
I partnered closely with our own policy team to understand where we had room to smooth the process and where we were limited by regulation. We also surveyed customers to understand their policy considerations.
I used progressive disclosure to layer policy information: the card shows a simple status indicator, and only if the user needs to take action does the interface present an edit or justification flow with the related policy info. That keeps the happy path clean, since most expenses are fine and nobody should have to wade through policy language for a coffee receipt. When something does need attention, the information is right there, clearly written, with an obvious next step.
Exception handling had to be as touchless as possible, while remaining fully compliant with corporate policy and government regulations↪ The Outcome
From Stuck to Flagship
What began as a difficult delivery challenge became a working model for how Redwood-compliant mobile work could move forward. The product launched, telemetry got integrated, mobile patterns pushed further inside Redwood, and the work left behind reusable learnings for other teams facing similar constraints.
The pilot launched in April 2023 with 26 users, grew to 450 within six months, and passed 1,200 by the two-year mark. Redwood adopted new mobile patterns and other teams leaned on our work for their own mobile initiatives.
↪ The Takeaway
This work sat at the intersection of platform discipline, product ambition, and delivery reality.
My job was to find the version that could actually ship, generate real learning, and still preserve the larger intent behind the original vision.
One vision for the next evolution of the mobile app↪ Coda
Mobile or not, the product was a success
The mobile product generated an important kind of value beyond adoption. It gave the team a live environment to validate the touchless model, test AI-assisted flows, reduce technical variation, and gather real usage data instead of relying on assumptions.
What we learned mattered: employees didn't consistently want to manage expenses away from their desks, but they did benefit from stronger automation, clearer status communication, and more accurate handling of expense data.
Those insights strengthened the desktop direction on the new Fusion platform, improved the underlying product and AI capabilities, and helped expand Redwood’s ability to support more sophisticated enterprise workflows in the future.
The mobile effort wasn't a dead end. It was a proving ground, one that clarified where the product actually created value, where usage naturally belonged, and which platform and design-system investments would matter most next.
Data visualization or usage chart showing the consistent decline in mobile expense app usage over time — the evidence that proved the core assumption wrong