Skip to content
Decide on frontend tech stackDecide on backend tech stackAscertain full list of requirementsCreate mock-upsBuild out backendBuild out frontend and connect to backendThorough test through all major user journeysLive for beta users
App Development
Abstract product description
Socii Money is a new way for couples to manage their shared finances (like bills, groceries, meals out etc).
The app links with your banks to automatically get a feed of your expenses (or, you can enter expenses manually). These are private to you, but you can simply swipe right to split the expense with your partner and swipe left to remove transactions/delete from list (for ones that are just for you).
Splitting can be done by a pre-set default percentage, or customised for each individual expense. You can also set it up to ‘learn’ to automatically split specific expenses each month (first with manual user generated rules, later with ML).
You have a shared space page which shows a summary of the current state of your expenses e.g. who owes whom and how much and what are the expenses. You can press a button to ‘mark as settled up’ resetting the balance owed to zero.
In V2 of the app, we will integrate a way to transfer funds with PayPal, and/or some form of notification (Twilio texts would be easy to integrate), so space should be included in the design for this.
High level to do list
Front end
Tech stack
Reason: My understanding is that our priority is to launch as quickly as possible with an MVP. By using what seems to be the market leader, we benefit from a larger ecosystem. This can be very useful for speed of execution, because often many of the challenges we will face have already been completed and shared as either plug and play components, or tutorials on YouTube etc. This significantly decreases development time by not having to ‘re-invent the wheel’.
Furthermore, it’s worth noting that the majority of the speed of an app (especially a ‘data centric’ app) typically comes from the backend tech. Also, in the unlikely event that we do encounter an issue, since we have structured the app in a way that prioritises the workload on the backend, it will be easy for us to switch and rebuild with another system.
App specs based on the product description
User types
This specifies who will be using the app, and divides them into ‘cohorts’, so that we can think through individual journeys for each user type.
User Type
Description
Primary User
Manages shared expenses with their partner.
There are no rows in this table
Interactable elements
These are the ‘things’ that the users can interact with.
Interactable elements
Description
Transactions
Expenses linked with bank account.
Split expenses
Expenses that can be split between partners.
Mark as settled up
Resetting the balance owed to zero.
There are no rows in this table
Actions
Actions a user can take
Actions
Description
Swipe right to split an expense
Expense split between partners.
Swipe left to remove transaction
Transaction removed from list.
Set default or custom split percentage
Split percentage set as default or customized for each expense.
Automatically split expenses
Set rule to split expense every month
Manually add expenses
Ability to manually add expenses to the list.
There are no rows in this table
Third-Party Service Integrations
Third-Party Service
Description
Bank integration
Expense feed linked with bank account(s).
PayPal integration
Integration with PayPal for V2 to settle up expenses.
Integration to manage bill provider
V2
Integration to email sending
Sending welcome and password emails
There are no rows in this table
Page layout
Amalgamating the above, this list details all the pages that the app will require, and what features will be included on each one
Page Name
Features Included
Welcome Screen
Introduction to the app and its features, call to action to create an account or log in, or forgot password workflow
Account Creation
Create an account by signing up with email and password (V2 for Gmail, Facebook login?)
Bank Account Linking
Link bank accounts and grant access to transactions
Split Percentage Set-Up
Set default split percentage for shared expenses. Let them know they can customise for each individual expense
Inviting partner to app
Send request to partner to join the app
Personal transactions Feed
Automatically imported transactions, swipe to split expenses, manually add expenses, automate splitting of expense. Query - do we want any sort of search/filter functionality here?
Settings
Manage/link bank accounts, set split percentages, manage PayPal integration, manage notification settings, change password, links to T’s and C’s, invite partner to join app (only displays if they skipped this step on sign up)
Shared Space
Summary of current state of expenses, who owes whom and how much, mark as settled up button, allocated gap in design to add ‘send money’ button later and send reminder notification (V2)
There are no rows in this table
Back end
Tech stack
Reason: No-code, meaning drastically reduced setup and dev time, also means incredibly quick for us to iterate through ideas, and add features. Dedicated resource allocation powered by Google Cloud, meaning secure, scalable and fast.
My understanding is that we are prioritising quick build and learn/iterative development cycles, this allows us to do exactly that, and is more than robust enough to scale as we do. Also, no complex lock-in of data either.
Setup
Description
Overview
Relationships between tables
Database Schema as a diagram
Database schema as tables, and with dummy data
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.