A savings app built around the way people actually get paid
Putting money aside for a holiday or a large bill is straightforward in theory. Automating it through a mobile app is harder because paydays, deposits and spending aren’t always predictable. A savings app has to recognize real bank transactions, avoid counting the same deposit twice and give people a clear picture of where their money has been allocated.
Christmas Club was developing a consumer app around this idea. Users could connect their bank accounts, identify recurring income and set money aside for savings goals and upcoming expenses. When SLIDEFACTORY joined in September 2022, the product was already in development and being tested, but important bank-data and scheduled-contribution functions needed further work before a public release.
A 30-second promo for the app: payday categories, Christmas savings and savings goals.
We joined the client’s wider development effort to help get the React Native app across the finish line. Our work covered Plaid integration, savings logic, mobile screens, testing and releases. Christmas Club subsequently launched publicly in the App Store, and we continued providing development and support after launch through May 2024.
Finding payday in the transaction history
The savings experience depended on getting one calculation right: determining when money had actually arrived. People can receive multiple deposits, transfers and irregular income, so the largest transaction isn’t always a reliable indicator by itself. Using Plaid’s recurring transaction data, we built a way to identify income streams and suggest the payday associated with the largest average deposit. Users could confirm that suggestion during onboarding.
We then rebuilt the scheduled contribution job. Each run refreshed the user’s transactions, checked for a payday that occurred after signup and contributed only if that payday hadn’t already been counted. We linked each contribution to the bank transaction that triggered it, so the app could show how a deposit became money allocated to a savings goal.
Keeping allocations accurate as people spend
Payday detection was one side of the product. Users also needed to direct those contributions into goals and bill buckets and see how their spending affected what remained. We added multiple separately tracked savings goals, one-time contributions and the ability to archive a completed goal without losing its history.
We extended transaction assignment to goals, trackers and bill buckets, restricted assignment where a bucket didn’t have sufficient funds and accounted for overspending so bucket balances stayed consistent. Users could also move money among buckets and a buffer account. Those same transfer controls later supported a reserve for credit-card spending.
Adding credit cards
In late 2022 the client expanded the plan to include credit cards. Linking a card through Plaid wasn’t identical to linking a checking account: the flow changed depending on whether both accounts were at the same institution, and some banks behaved differently from the published documentation. We tested those cases, worked with Plaid support and changed the linking flow so reconnecting an account reused its existing connection.
With those paths in place, we added the credit-card reserve and updated the main screen and transfer tools so users could account for card spending alongside their other allocations.
Making sure the numbers stayed consistent
Behind the features people used every day, the transaction records needed to remain dependable. We found transactions being imported more than once, wrote a cleanup query and changed imports to reject duplicate transaction IDs. We moved to Plaid transaction sync where supported, limited manual refreshes to one a day and made sure a failure on one user’s connection didn’t stop the refresh job for everyone else.
We also corrected stale-document save errors by rereading records before updates. When a major bank changed its Plaid connection in 2023, we upgraded the integration. Sentry monitoring, logging around bank connections and prompts to update out-of-date app versions made these problems easier to detect and diagnose.
Taking the app through launch and beyond
We worked with the founder and other contractors rather than replacing the wider team. Our responsibilities included pull request review and merging, testing on devices, TestFlight builds and iOS releases. The product launched publicly in the App Store, and our work continued afterward.
As the app evolved, releases also included Firebase Cloud Messaging notifications, Facebook SDK deep links, subscription screens and onboarding emails. We removed endpoints identified as exposing unnecessary user data. By mid-2023, the work had moved toward ongoing support: improving onboarding and navigation, correcting layout and font scaling on different iPhone sizes, updating email-domain configuration and moving the app to React Native 0.74 in spring 2024.
From a working concept to an App Store release
When we joined Christmas Club, the savings concept was already in development, but dependable bank synchronization, payday detection and contribution logic still needed work. Those behind-the-scenes systems became the focus of our involvement because they determined whether the app could consistently represent a user’s money.
Christmas Club went on to launch publicly in the App Store, with our team supporting mobile releases, integrations and ongoing fixes after launch. The engagement lasted roughly 20 months, through May 2024, and included about 620 hours of development. What began as helping a startup complete its product became a longer relationship supporting the app as it moved from testing into public use.
