CoupleFi: Exploring Estimate Creation
Role: Design & Engineering
Overview
“Build to think” is core to my approach as a designer. Creating small functional prototypes enables me to uncover flaws, hidden requirements, and explore new technologies quickly to inform product requirements. While I love to explore designs, sometimes the question that needs an answer is “which libraries actually do what you need?” and “how well they play together in practice?”
This prototype explored a single flow: creating a recurring expense estimate in CoupleFi. On the surface it’s a simple form. In reality it’s a sheet with multiple sub-views: a date picker, a custom frequency configurator, and a repeat-end screen. Each one needs to animate in and out as the user navigates while speaking to the larger view context to ensure its states are correctly displayed. Getting that right before writing production code was critical.
Goals
I set out to answer a few specific questions. Which approach for animating between views inside a sheet works cleanly with Motion? Is React Select still a viable option for custom dropdowns? What’s the best calendar component for our use case? And how does DayJS hold up for date display?
I deliberately skipped form validation, full state management, and the complex edge cases around recurring schedule rules. I already have established patterns for those and keeping the scope tight let me focus on the decisions that actually mattered.
Findings
Animation
This was the most important finding. React’s <Activity> primitive keeps
components mounted in the DOM, which is useful for preserving state, but it
doesn’t trigger exit animations. Motion’s <AnimateActivity> wrapper has the
same limitation. Running multiple separate <AnimatePresence> wrappers
technically works, but each view animates independently and can creates visual
chaos when two are in transition at the same time if not managed carefully.
<AnimatePresence mode="wait"> was the clear winner. It ensures only one view
is mounted at a time, so exit animations complete before the next view enters.
It’s clean, predictable, and exactly what a sheet navigation pattern needs.
Libraries
React Select doesn’t seem to be actively maintained, which is a real concern for
a component I’d rely on heavily. I tested @headlessui/react’s Listbox as an
alternative. It has a solid API and works with Motion when you use a Fragment
as the item wrapper instead of a DOM element. That combination isn’t
well-documented anywhere, but it gives you animated dropdowns with full
accessibility baked in.
React Day Picker handled every requirement I had: single selection, outside
days, custom navigation components, and animated month transitions via its
built-in animate prop. The CSS override system is difficult but robust enough
to wrangle the layout into anything you’d like.
DayJS remained solid for date display and formatting. I found myself curious about the Temporal API as a potential improvement for server-side date storage. A polyfill exists, though I haven’t tested it against our actual use cases yet.
What’s still open
Managing date recurrence (RRules) was one area I didn’t resolve. Recurring schedules like “every third Wednesday, ending after 12 occurrences” are deceptively complex to model in a clean state machine. Thankfully, the spec covers every edge case thoroughly. I’m still working out the right path forward before building that part of the form.
I also noticed a visual issue I’ll fix during production implementation, the placeholder text color in the form inputs is too dark. For users, it could read as filled-in data rather than a hint, a well known UX issue when using placeholders in text fields.
Final Thoughts
Using a build to think approach reduced a lot of the time that would have been used by creating theoritical requirements, only to revise them when the tooling didn’t match. Having a working code sample with detailed notes makes it much easier to plan the implementation.
I should also note that Claude was really helpful here. During this phase, I intentionally idn’t use it to build, because I wanted a better feeling for how the tools worked together. However, using it to explain new APIs that I was unfamiliar with was invaluable. That greatly increased my productivity and confidence in the third party libraries. After all if Claude couldn’t understand the API, the library wouldn’t be worth integrating.
This project is in the prelaunch phase. If you’re interested in being notified when it launches, sign up at CoupleFi.