Appearance
Crest — Business Requirements Document (BRD)
| Product | Crest — Personal Finance App |
| Document version | 0.23 (Draft) — NFR-17 corrected: DNS is hosted at Biznet Gio, not Cloudflare. Crest is local-first: the app works for anyone on their own device with no login (local mode); sync, sharing, and server backup are for invited people (connected mode) |
| Date | 2026-10-06 |
| Status | Draft — pending review |
| Owner | Reizkian Y. Radityatama |
Unresolved decisions are listed in §14 Open Questions.
Terminology — read this first. This document never uses the word "account" on its own.
User: a person who can log in to Crest (identity, email, password, status). Managed by the Super Admin.
Financial account: a place where money is held or owed: cash wallet, bank, e-wallet / online payment, or credit card.
Space: a container that holds financial accounts, categories, budgets, and savings goals, plus the list of users who can see it (its members). Every user has a private Personal space; users can also create and join shared spaces.
Local mode and connected mode: Crest works in two ways. In local mode anyone uses the app on their own device with no login, and the data stays on that device. In connected mode a user who has been given access logs in, and the data is also kept on Crest's server so it can sync between devices and be shared. See §8.0.
A user can be a member of many spaces, and a space can have many members. Every financial account belongs to exactly one space. See §8.4 and §15 Glossary.
1. Executive Summary
Crest is a personal finance app that helps individuals understand where their money goes, plan budgets, and build better financial habits. Users record income and expenses across all their financial accounts (cash wallet, bank, e-wallet, credit card), see clear spending insights, and set budgets and savings goals.
The first release (MVP) focuses on fast manual tracking, budgeting, and insights. Automatic bank syncing is planned for a later phase.
Crest is local-first. For users, Crest is an app that runs in the browser (a Progressive Web App, PWA): people open it from a link and can add it to their phone's home screen, so it looks and works like an app without any app store. It is built with Flutter, so the same code can later be published as Android and iPhone apps if there is demand.
Anyone can use the app on their own device with no sign-up (local mode): the data stays on the device and Crest's servers never see it, so this costs nothing to run no matter how many people use it. The cloud part of Crest (sync between devices, shared spaces, a server backup, and email) is for the owner and the people they know (friends, family, colleagues), not a mass-market service. Those people are invited and use the app in connected mode. Around the app are two small websites: a public site (what Crest is, the access-request form, activation, install guide, and the privacy policy) and the Super Admin portal. The portal and the connected features talk to one separate backend.
Money is often shared. A couple runs a joint bank account; a small business owner gives staff a fund for groceries or supplies. Crest supports this with Spaces: a shared space holds the financial accounts, categories, and budgets that a group uses together, and every member sees every transaction in it, including who added it. Everything outside a shared space stays private.
Crest is free. If the number of users grows, users may later be asked for a small yearly contribution that only covers running costs. Payment would happen outside Crest, and the Super Admin records it manually.
The cloud part of Crest is invite-only. People cannot register themselves for it. They submit an access request, and the Super Admin reviews it and approves or rejects it from a web-based Super Admin portal. The portal is also used to manage all users. Using the app on your own device needs no request and no approval.
2. Problem Statement
- People keep money in many places (cash, several bank accounts, e-wallets, credit cards) and lack one consolidated view.
- Spending is hard to track consistently; most users give up on spreadsheets or apps that are slow to log into.
- Users don't know whether they are on track for their monthly budget until it is too late.
- Existing apps are often cluttered, ad-heavy, or not tailored to users' local currency, language, and payment habits.
- People who share money (couples, families, a boss and staff) can't easily see how the shared money is being used, and by whom, without also exposing their private finances.
- Many people don't want to hand their money data, or their email, to yet another service just to start tracking.
3. Business Objectives
| ID | Objective | Measure of success |
|---|---|---|
| BO-1 | Help users build a consistent tracking habit | ≥ 40% of new users still log a transaction in week 4 |
| BO-2 | Make recording a transaction effortless | Median time to add a transaction ≤ 10 seconds |
| BO-3 | Give users confidence about their money | ≥ 50% of active users create at least one budget |
| BO-4 | Be trusted with real financial data by the people who use it | Zero data-breach incidents; ≥ 80% of activated users still active after 3 months |
| BO-5 | Keep Crest cheap to run and, if needed, self-funding | Running costs stay within the target in NFR-13; once contributions start (Phase 4), they cover ≥ 100% of yearly running costs |
| BO-6 | Make getting started easy for invited people | ≥ 70% of approved users activate their login and connect within 7 days; ≥ 50% add Crest to their home screen |
| BO-7 | Let anyone start recording with no sign-up | A new person can add their first transaction within 2 minutes of opening the app, with no login (checked by the owner with new people, since Crest uses no analytics) |
4. Scope
4.1 In scope (MVP)
Local mode (Phase 1a, ships first and needs no server)
- The Crest app as a Progressive Web App (PWA): opens in the browser on phones, tablets, and computers; can be added to the home screen; works fully without internet. Built with Flutter, one codebase
- No login: a first-launch welcome (Privacy Policy, Terms of Use, 18+), then the person starts recording
- Unlimited financial accounts of every type: cash wallet, bank, e-wallet / online payment, credit card
- A Personal space on the device
- Manual income, expense, and transfer transactions
- Categories (default set plus custom)
- Monthly budgets per category
- Dashboard with balances and spending insights
- Transaction search and filters
- CSV export
- Backup file: save all data to a file and restore it, on the same or another device
- Optional app lock (PIN) on the device
- Update notice when a new version is published
- Public website: landing page, install instructions, Privacy Policy and Terms of Use (English and Bahasa Indonesia, published before the first release)
Connected mode (Phase 1b, invite-only)
- Invite-only access: public access-request page (also linked from the app's Connect screen), admin approval, user activation
- Connect to Crest: login, upload of the device's data, and sync between devices
- Server backup of connected users' data
- Spaces: shared spaces with invited members, Owner/Member roles, and transfers between spaces
- Email: activation, password reset, invitations
- Super Admin portal (a separate web app) for access requests and user management
- Backend API used by the app, the portal, and the public site
4.2 Out of scope (MVP)
- Native Android and iPhone apps and app-store distribution (later, from the same codebase, if there is demand)
- Contributions / subscriptions (planned for Phase 4, recorded manually; see §8.14)
- Payment processing of any kind: Crest never takes card or online payments
- Self-service registration for connected mode (anyone can use local mode with no login, but sync and sharing need an invitation)
- Cloud backup for people who use local mode only (they save a backup file instead)
- Encrypting the data stored on the device, or the backup file, with a password (to be decided, see §14)
- External authentication of any kind: Google, Apple, Facebook, other social login, OAuth, SSO
- Different admin permission levels (there is one Super Admin role; several users can have it)
- Admin access to users' financial data
- Automatic bank/e-wallet syncing (Phase 3)
- Investment portfolio tracking
- In-app money requests between members (they happen outside Crest; Crest records the resulting transfer)
- Moving an existing financial account from one space to another
- Bill payment or money transfer (Crest never moves money)
- Recurring transactions and CSV import (Phase 2)
- Tax reporting
- Financial advice
5. Stakeholders
| Stakeholder | Role / interest |
|---|---|
| Product owner | Defines vision and priorities; approves scope |
| Super Admin | Product owner acting as operator, plus any other users given the Super Admin role; approves access requests and manages users |
| Engineering & design | Currently the owner; builds, designs, and runs Crest, including maintaining the server |
| End users | Anyone, on their own device (local mode); the owner and people they know for sync and shared spaces (connected mode) |
| Legal / compliance | Data protection laws of the countries where users live (e.g. Indonesia's PDP Law — UU No. 27/2022, EU/UK GDPR) |
6. Target Users & Personas
Crest's local-mode users can be anyone. Its connected users are the owner and people they know personally. They may live in different countries and use different currencies. The personas below are typical examples. Each of them can start in local mode; Andi and Rina, and Boss with Jojo and Maria, need connected mode for shared spaces.
Persona 1 — Young professional ("Dina", 26) First job, salary into a bank account, pays daily with e-wallets. Wants to know why money runs out before payday and to start saving for a goal.
Persona 2 — Family manager ("Budi", 38) Handles household spending across cash and several financial accounts. Wants monthly budgets per category and to spot overspending early.
Persona 3 — Freelancer ("Sari", 30) Irregular income. Wants to separate income sources, track expenses, and see month-over-month trends.
Persona 4 — Couple ("Andi", 34, and "Rina", 32) Share a joint bank account for household costs, and each keeps private financial accounts. Both add and use money from the joint account and want to see how the other uses it, without seeing each other's private finances.
Persona 5 — Small business owner ("Boss", 45) and staff ("Jojo" and "Maria") Boss gives each staff member a fund to manage. Jojo buys groceries, office food, and cooking ingredients from the kitchen fund. Maria pays for equipment, tools, couriers, and packaging from the operations fund. When a fund runs low, staff ask Boss in person or by chat; if Boss agrees, Boss tops up the fund. Jojo can't see Maria's fund and Maria can't see Jojo's; Boss sees both.
Persona 6 — Super Admin (the app owner) Controls who can use Crest. Also uses Crest as a normal user, with their own spaces. Reviews access requests, approves or rejects them, manages users (deactivate, reactivate, delete), and later records yearly contributions, all from the Super Admin portal. Does not need to, and should not, see users' financial data.
7. User Access Flow
Anyone can use Crest in local mode with no login. Connected mode (sync, shared spaces, server backup) is for invited people, who cannot sign up themselves. Access to connected mode works like this:
User statuses
| Status | Meaning | Can log in? |
|---|---|---|
| Pending | Access request submitted, awaiting review | No |
| Rejected | Request declined by Super Admin | No |
| Invited | Approved; activation link sent, password not yet set | No |
| Active | User activated their login | Yes |
| Deactivated | Access suspended by Super Admin; data retained | No |
| Deleted | User and all their data permanently removed | No |
8. Functional Requirements
Priority uses MoSCoW: M = Must, S = Should, C = Could, W = Won't (this release).
8.0 Local mode and connected mode
Crest has two ways of being used, in the same app:
| Local mode | Connected mode | |
|---|---|---|
| Who | Anyone | A user who has been given access |
| Login | None | Email and password |
| Where the data lives | Only on the device | On the device and on Crest's server |
| Shared spaces, several devices, server backup, email | No | Yes |
| Costs the server anything | No (only the download of the app's files) | Yes |
In local mode Crest has no copy of the person's data and cannot recover it. Phase 1a delivers local mode; Phase 1b adds connected mode.
| ID | Requirement | Priority |
|---|---|---|
| FR-MOD-1 | Anyone can open the Crest app and use it without a login or any personal details (local mode) | M |
| FR-MOD-2 | In local mode all data (financial accounts, transactions, categories, budgets, settings) is stored on the device and never sent to Crest's servers. The app contacts Crest only to download its own files and to check for a new version (FR-APP-5) | M |
| FR-MOD-3 | Local mode has one Personal space, on the device. It has no shared spaces, invitations, or members. Everything else in §8.5 to §8.12 that does not need a server works the same as in connected mode | M |
| FR-MOD-4 | On first launch the app shows a short welcome. The person accepts the Privacy Policy and Terms of Use and confirms they are 18 or older (BR-44). The answer is kept on the device | M |
| FR-MOD-5 | Backup file. The person can save all their data to a backup file, and restore from one, on the same or another device. Restoring replaces the data on the device only after a clear warning and a chance to save the current data first | M |
| FR-MOD-6 | Before the person enters data, and later in Settings, the app says plainly that in local mode the data lives only on this device and can be lost if the browser clears it, the device is lost, or the app is removed. On iPhone and iPad it first asks the person to add Crest to the home screen (UJ-38), because Safari can clear the storage of sites it was not used on for about a week, and the home-screen app keeps its data separately from Safari | M |
| FR-MOD-7 | The app asks the browser to keep its data (persistent storage) and shows whether the browser agreed | S |
| FR-MOD-8 | The app reminds the person to save a backup file when the last one is more than 30 days old and data has changed since | S |
| FR-MOD-9 | Connect. A person who has been given access (an Active user) can connect from the app (More → Connect to Crest) by logging in. Connecting turns on sync and the features that need a server: shared spaces, use on several devices, server backup, and email. People without access see Request access on the same screen | M |
| FR-MOD-10 | When connecting on a device that has local data, the app asks Upload this device's data (the default) or Start fresh. Upload is allowed only if the user's Personal space on the server is empty (BR-47). Otherwise the app offers Use my Crest data (the local data is first offered as a backup file) or Keep this device's data local only | M |
| FR-MOD-11 | Log out asks whether to keep a local copy of their Personal space on the device (Crest continues in local mode and no longer syncs; shared spaces are never kept) or to remove the data from the device. After a forced logout, the synced data is removed from the device (BR-50) | M |
| FR-MOD-12 | In connected mode the server is the source of truth. The device keeps a local copy so Crest works offline, and changes made on one device appear on the user's other devices after they sync | M |
8.1 Access Requests
| ID | Requirement | Priority |
|---|---|---|
| FR-REQ-1 | Anyone can submit an access request with full name, email, country, and optional reason/message | M |
| FR-REQ-1a | The request form is a page on the public website with its own link (to share with friends), also reachable from the app's Connect screen (More → Connect to Crest) | M |
| FR-REQ-2 | The request form is protected against spam (rate limiting and bot protection) | M |
| FR-REQ-3 | The requester sees a confirmation that the request was received; no user is created at this point | M |
| FR-REQ-4 | A duplicate request for an email that is already pending or active is not created; the requester sees a neutral message that does not reveal whether the email exists | M |
| FR-REQ-5 | The requester receives an email when their request is approved (with activation link). If it is rejected, they receive a short, polite email saying it wasn't approved, without a reason | S |
| FR-REQ-6 | The request form links to the Privacy Policy and Terms of Use (in the visitor's language); submitting requires accepting both and confirming the visitor is 18 or older | M |
8.2 Authentication & Security
| ID | Requirement | Priority |
|---|---|---|
| FR-AUTH-1 | There is no public sign-up for connected mode. Only users approved by the Super Admin can log in. Local mode needs no login (FR-MOD-1) | M |
| FR-AUTH-2 | An approved user activates their login through a single-use activation link and sets a password | M |
| FR-AUTH-3 | Activation links expire after 72 hours; the Super Admin can resend a new link | M |
| FR-AUTH-4 | Users log in with email and password | M |
| FR-AUTH-5 | No external authentication. Users log in only with their Crest email and password. There is no sign-in with Google, Apple, Facebook, or any other identity provider (no OAuth / SSO / social login) | M |
| FR-AUTH-6 | Users can lock Crest with a PIN. In connected mode the PIN is one per user and works on all their devices. In local mode the PIN is stored on the device only and is optional; a wrong PIN there only slows down further attempts and never erases data (BR-49). When native Android and iPhone apps exist, the device's biometrics (Face ID or fingerprint) can unlock them as well; biometrics never leave the device and are not external authentication | M |
| FR-AUTH-7 | Users can reset their password | M |
| FR-AUTH-8 | Users can delete themselves (their login) and all their data. Their Personal space is deleted; transactions they added in shared spaces stay there, labelled "Former member" (BR-34) | M |
| FR-AUTH-9 | A deactivated or deleted user is logged out of all devices immediately | M |
8.3 Super Admin Portal
A separate web app at its own address, used only by Super Admins. It is designed for desktop but usable on a phone.
| ID | Requirement | Priority |
|---|---|---|
| FR-ADM-1 | Only users with the Super Admin role can access the portal | M |
| FR-ADM-2 | Super Admin login requires two-factor authentication (authenticator app) | M |
| FR-ADM-2a | When setting up 2FA, the Super Admin receives one-time backup codes to log in if the authenticator device is lost | M |
| FR-ADM-3 | The first Super Admin is created during setup (seed script), not through the app | M |
| FR-ADM-3a | As a last resort, the setup script can reset a Super Admin's 2FA (requires server access); the reset is recorded in the audit log | M |
| FR-ADM-4 | Super Admin sees a list of access requests, filterable by status (Pending, Approved, Rejected) | M |
| FR-ADM-5 | Super Admin can approve a request, which creates the user and sends the activation link | M |
| FR-ADM-6 | Super Admin can reject a request, with an optional reason | M |
| FR-ADM-6a | Super Admin can approve a request that was previously rejected (to reverse a rejection); this works like a normal approval | M |
| FR-ADM-7 | Super Admin can create a user directly (without a request), which sends an activation link | M |
| FR-ADM-7a | If the email in FR-ADM-7 already has a Pending request, that request is approved instead of creating a separate user | M |
| FR-ADM-8 | Super Admin sees a list of all users with name, email, status, created date, and last login; searchable and sortable | M |
| FR-ADM-9 | Super Admin can deactivate and reactivate a user | M |
| FR-ADM-10 | Super Admin can resend an activation link or trigger a password-reset email for a user | M |
| FR-ADM-11 | Super Admin can permanently delete a user and all their data, after typed confirmation. Shared spaces follow the same rules as FR-AUTH-8 | M |
| FR-ADM-12 | Super Admin can edit a user's name and email. An email change notifies both the old and the new address, and takes effect only after the user confirms it from a link sent to the new address | S |
| FR-ADM-13 | Super Admin is notified (email) when a new access request arrives | S |
| FR-ADM-14 | Every admin action is recorded in an audit log (who, what, which user, when), viewable in the portal | M |
| FR-ADM-15 | Overview page shows counts: pending requests, active users, deactivated users, new users this month | S |
| FR-ADM-16 | Super Admin can give the Super Admin role to any Active user, or remove it (never from the last Super Admin). A user who receives the role must set up 2FA before opening the portal | S |
| FR-ADM-17 | Super Admin cannot view users' financial data (financial accounts, transactions, budgets) or anything about their spaces, including space names and member lists | M |
| FR-ADM-18 | Super Admin can select several access requests and approve or reject them together | C |
8.4 Spaces & Sharing
A space holds financial accounts, categories, budgets, and savings goals, plus its members. Everything inside a space is visible to all its members; nothing outside it is.
Example
Each green box is a shared space, and the people with an arrow into it are its members. Everyone also has a private Personal space that only they can see (not drawn here).
Roles and permissions
| Action | Owner | Member |
|---|---|---|
| See all financial accounts, transactions, categories, budgets, goals, and members in the space | ✓ | ✓ |
| Add expenses, income, refunds, and transfers | ✓ | ✓ |
| Edit or delete transactions they added | ✓ | ✓ |
| Edit or delete transactions added by others | ✓ | — |
| Add, edit, archive, or delete financial accounts | ✓ | — |
| Manage categories | ✓ | — |
| Set budgets and savings goals | ✓ | — |
| Invite and remove members, change roles | ✓ | — |
| Rename or delete the space, change its currency or budget start day | ✓ | — |
| Leave the space | ✓ (not the last Owner) | ✓ |
In a Personal space the user is the only member and is its Owner.
| ID | Requirement | Priority |
|---|---|---|
| FR-SPC-1 | Every user gets a Personal space automatically when their login is activated (connected mode; in local mode the Personal space is created on the device, FR-MOD-3, and is uploaded into this one, FR-MOD-10). Only they can see it. It can't be shared, and it can't be deleted except by deleting the user | M |
| FR-SPC-2 | Any Active user can create a shared space with a name, currency, and budget start day, and becomes its Owner | M |
| FR-SPC-3 | Every financial account, category, budget, and savings goal belongs to exactly one space. A new space starts with the default categories | M |
| FR-SPC-4 | Owners can invite other people by email. If the email belongs to an Active user, the invitation appears in Crest and by email; the person accepts or declines. The Owner always sees the same neutral message: "If this email belongs to a Crest user, they'll receive an invitation" | M |
| FR-SPC-5 | Invitations expire after 14 days. Owners can see and cancel pending invitations | M |
| FR-SPC-6 | Members have the role Owner or Member, with the permissions in the table above. Any Owner can change the role of, or remove, any other member, including other Owners, as long as at least one Owner remains. A shared space can have several Owners (e.g. both partners of a couple) | M |
| FR-SPC-7 | Every transaction shows who added it and, if changed, who last edited it | M |
| FR-SPC-8 | A member can leave a shared space, and Owners can remove members (including other Owners, FR-SPC-6). Access ends immediately. Transactions they added stay and keep their name | M |
| FR-SPC-9 | The last Owner can't leave until they make someone else Owner or delete the space | M |
| FR-SPC-10 | Owners can delete a shared space after typed confirmation. All its financial accounts, transactions, categories, budgets, and goals are deleted, and members are notified | M |
| FR-SPC-11 | A space switcher at the top of Crest moves between spaces. Each space has its own dashboard, financial accounts, transactions, categories, and budgets. The switcher is hidden while a user has only their Personal space | M |
| FR-SPC-12 | Each space has a currency used for its budgets and reports. For a Personal space it is the user's base currency; for a shared space an Owner sets it | M |
| FR-SPC-13 | Each member has an Include in my totals setting per shared space: on by default for Owners, off by default for Members. The Personal dashboard's net worth adds up the Personal space and every included shared space, converted into the user's base currency with their own saved rates | S |
| FR-SPC-14 | A user can transfer money between financial accounts in any spaces they belong to (e.g. Boss's BCA in Personal → Kitchen fund in Kitchen). Each side of the transfer is visible only to the members of its own space, and shows the person who made it instead of the other financial account, e.g. "+500,000 from Boss" | M |
| FR-SPC-15 | A shared space's dashboard can show spending by member as well as by category | S |
| FR-SPC-16 | Each member can turn on Notify me when someone adds a transaction for a shared space (off by default). Invitations always notify | C |
| FR-SPC-17 | Financial accounts can't be moved between spaces. To share money that is in a private financial account, the Owner creates a new financial account in the shared space with an opening balance | M |
8.5 Financial Accounts
A financial account is any place where money is held or owed. It belongs to one space (§8.4); in a shared space, only Owners manage financial accounts, and all members can use them. A user can have any number of financial accounts of every type, for example 3 banks, GoPay, OVO, and PayPal, 2 credit cards, and a cash wallet, all tracked side by side.
| Financial account type | Examples | Balance meaning |
|---|---|---|
| Cash | Wallet, piggy bank, petty cash | Money on hand (asset) |
| Bank | BCA, Mandiri, Chase, Wise | Money in the bank (asset) |
| E-wallet / online payment | GoPay, OVO, DANA, ShopeePay, PayPal | Stored balance (asset) |
| Credit card | Visa, Mastercard, JCB cards | Amount owed (liability) |
| ID | Requirement | Priority |
|---|---|---|
| FR-FIN-1 | Users can create any number of financial accounts, each with a name, type (cash, bank, e-wallet / online payment, credit card), currency, and opening balance | M |
| FR-FIN-2 | Users can edit, archive, and reorder financial accounts | M |
| FR-FIN-3 | The app shows each financial account's current balance, derived from its transactions | M |
| FR-FIN-4 | Each space shows its net worth: assets (cash, bank, e-wallet) minus liabilities (credit cards). The Personal dashboard also shows the user's total net worth across spaces (FR-SPC-13) | S |
| FR-FIN-5 | Users can hold financial accounts in different currencies | S |
| FR-FIN-6 | Users can maintain their own exchange rates (one rate per currency to their base currency) in settings, with the date each rate was last updated. A user's rates are private and are used for every space they view | C |
| FR-FIN-7 | Totals across currencies (net worth, dashboard) are converted into the base currency using the user's saved rates; the app shows the rate date and prompts for a rate if one is missing | C |
| FR-FIN-8 | Users can optionally add the provider name (e.g. "BCA", "GoPay"), a color/icon, and the last 4 digits of a card or bank account number to tell similar financial accounts apart | S |
| FR-FIN-9 | Financial accounts are grouped by type on the Financial Accounts screen, with a subtotal per group | S |
| FR-FIN-10 | Credit card financial accounts show the amount owed; users can optionally set a credit limit and see available credit | S |
| FR-FIN-10a | Unusual balances are allowed but highlighted: a cash / bank / e-wallet balance below zero, a credit card over its limit, and a credit card paid more than owed (shown as a "credit balance") | S |
| FR-FIN-11 | Credit card financial accounts can optionally have a statement day and payment due day, with a reminder to the space's Owners before the due date | C |
| FR-FIN-12 | Paying a credit card bill is recorded as a transfer from a bank / e-wallet / cash financial account to the credit card financial account | M |
| FR-FIN-13 | A top-up (e.g. bank → GoPay) or a cash withdrawal (e.g. bank → cash wallet) is recorded as a transfer | M |
| FR-FIN-14 | A financial account's currency can be changed only while it has no transactions; after that the field is locked | M |
| FR-FIN-15 | Before a financial account is deleted, the warning lists the other financial accounts it has transfers with, and explains that those transfers become ordinary income or expense there (BR-6) | M |
8.6 Transactions
| ID | Requirement | Priority |
|---|---|---|
| FR-TRX-1 | Users can add an expense or income with amount, financial account, category, date and time (defaults to now; can be set to a past date for entries logged late, or a future date for planned payments), and optional note | M |
| FR-TRX-2 | Users can record a transfer between financial accounts they can access, in the same space or in different spaces (FR-SPC-14). Transfers are not counted as income or expense | M |
| FR-TRX-2a | Users can transfer between financial accounts in different currencies (e.g. USD PayPal → IDR BCA) using a manually entered exchange rate | S |
| FR-TRX-2b | In a cross-currency transfer the user enters the amount sent plus either the exchange rate or the amount received; the app calculates the missing value | S |
| FR-TRX-2c | The user can edit the calculated amount received to match what actually arrived (e.g. after fees or a different bank rate); the app then recalculates the effective rate | S |
| FR-TRX-2d | The rate field is pre-filled with the user's saved rate for that currency pair (FR-FIN-6), if one exists; the user can override it for this transfer only, or choose to save it as the new rate | C |
| FR-TRX-2e | On any transfer (same or different currency) the user can optionally record a fee, e.g. an e-wallet top-up admin fee. The fee is saved as a separate expense in the "Fees" category from the sending financial account | S |
| FR-TRX-3 | Users can edit and delete transactions, within their role in the space (§8.4): Members only their own, Owners any | M |
| FR-TRX-3a | Editing a cross-currency transfer uses the same form as creating one: changing any of amount sent, rate, or amount received recalculates the third. Only that transfer changes | S |
| FR-TRX-4 | Users can search and filter transactions in the current space by date, financial account, category, amount, and text | M |
| FR-TRX-5 | Users can set up recurring transactions (daily, weekly, monthly, yearly) | S |
| FR-TRX-5a | When editing or deleting a transaction created by a recurrence, the user chooses Only this one or This and all future ones | S |
| FR-TRX-5b | Recurring transactions are created by the server on their due date in connected mode, so occurrences are never missed while the phone is off or offline. In local mode the app creates any missed occurrences, dated on their due dates, the next time it is opened | S |
| FR-TRX-5c | A recurring transaction in a shared space belongs to the member who set it up; it stops if that member leaves the space | S |
| FR-TRX-6 | Users can attach a receipt photo | C |
| FR-TRX-7 | Users can always add, edit, and delete transactions without internet. In connected mode the changes sync when the device is back online | M |
| FR-TRX-8 | Users can record a refund: money returned for an earlier purchase, into any financial account, with an expense category (normally the one the original purchase used). It can optionally be linked to the original expense | M |
| FR-TRX-9 | Future-dated transactions are shown in an Upcoming section of the transaction list. Balances and net worth show the amount as of now, with a second figure "after upcoming". Future transactions count toward the budget of the period their date falls in, and become normal transactions automatically when their date arrives | S |
Example: cross-currency transfer with manual rate
| Field | Value |
|---|---|
| From | PayPal (USD) |
| To | BCA (IDR) |
| Amount sent | 100.00 USD |
| Exchange rate (entered by user) | 1 USD = 16,250 IDR |
| Amount received (calculated, editable) | 1,625,000 IDR |
Result: PayPal balance −100.00 USD, BCA balance +1,625,000 IDR. The transfer stores both amounts and the rate. It is not counted as income or expense.
8.7 Categories
| ID | Requirement | Priority |
|---|---|---|
| FR-CAT-1 | Every space starts with a default set of income and expense categories, named in the language of the person who created the space. Category names are normal text and are not translated for other members | M |
| FR-CAT-2 | The space's Owners can create, rename, recolor, and archive its categories | M |
| FR-CAT-3 | Categories can have sub-categories | C |
| FR-CAT-4 | A transaction's category always comes from the space of its financial account: when adding a transaction, the category picker shows that space's categories | M |
8.8 Budgets & Goals
| ID | Requirement | Priority |
|---|---|---|
| FR-BUD-1 | The space's Owners can set a monthly budget per category, in the space's currency. All members see the budgets | M |
| FR-BUD-2 | Users see progress against each budget (spent / remaining) | M |
| FR-BUD-3 | Members of the space get notified at 80% and 100% of a budget | S |
| FR-BUD-4 | The space's Owners can create savings goals with name, target amount, and target date | S |
| FR-BUD-5 | A savings goal is linked to one financial account in the same space (e.g. a savings bank); progress = that financial account's balance. Money moved there by transfer counts automatically | S |
| FR-BUD-6 | If no financial account is linked, the user records contributions to the goal manually | C |
| FR-BUD-7 | Expenses in currencies other than the space's currency count toward budgets after conversion with the viewing user's saved rate; if the rate is missing they are left out and the budget shows a warning | C |
| FR-BUD-8 | A budget on a category with sub-categories includes the spending in its sub-categories | C |
8.9 Dashboard & Insights
| ID | Requirement | Priority |
|---|---|---|
| FR-DSH-1 | Each space's dashboard shows its total balance, this month's income, expenses, and net. The Personal dashboard also shows total net worth across included spaces (FR-SPC-13) | M |
| FR-DSH-2 | Spending breakdown by category (chart) | M |
| FR-DSH-3 | Month-over-month spending trend | S |
| FR-DSH-4 | Top merchants / largest expenses | C |
| FR-DSH-5 | A Stats screen (its own tab) shows analytics for the current space. It shows one chart at a time, chosen with tabs: Categories, Calendar, Trend, and Accounts (in a shared space the last tab is Members, FR-SPC-15) | M |
| FR-DSH-6 | A period selector (Week / Month / Year) applies to every Stats chart. Periods follow the space's budget start day (BR-4). The user can step back to earlier periods | M |
| FR-DSH-7 | Categories: a donut chart of spending by category, with the period total in the middle. Tapping a slice or its label selects that category and shows its amount and share of spending | M |
| FR-DSH-8 | Calendar: a month heatmap where each day's shade shows how much was spent that day. Tapping a day selects it | S |
| FR-DSH-9 | Trend: a bar per period (e.g. the last 6 months). Tapping a bar selects that period and shows the change against the previous one (FR-DSH-3) | S |
| FR-DSH-10 | Accounts: spending per financial account as bars; tapping one selects it | C |
| FR-DSH-11 | Below the chart, Stats always lists the transactions behind the current selection (the category, day, period, account, or member), grouped by day, with a count and total. The list updates as soon as the selection changes. An Open in Activity link opens the transaction list with the same filter (FR-TRX-4). Refunds reduce the amounts (BR-24), transfers are left out (BR-2), and amounts in other currencies are converted with the viewer's saved rates, marked as estimates (FR-FIN-7) | M |
8.9a App Navigation
| ID | Requirement | Priority |
|---|---|---|
| FR-NAV-1 | On phones the main screens sit in a bottom tab bar: Home, Activity (transactions), Budgets, Stats, More (financial accounts, categories, recurring, goals, spaces, settings). A + button on the main screens opens the add-transaction sheet (NFR-7). The space switcher sits at the top of every main screen (FR-SPC-11) | M |
8.10 Data Import & Export
| ID | Requirement | Priority |
|---|---|---|
| FR-DAT-1 | Users can export to CSV the transactions of any space they belong to (one space or all), shared through the device's share menu or downloaded. The export includes who added each transaction | M |
| FR-DAT-2 | Users can import transactions from CSV with column mapping | S |
8.11 Notifications
| ID | Requirement | Priority |
|---|---|---|
| FR-NOT-1 | Optional daily reminder to log transactions | S |
| FR-NOT-2 | Budget threshold alerts (see FR-BUD-3) | S |
| FR-NOT-3 | Notifications need connected mode. At launch they appear in a notification list inside Crest and, where it matters, by email; in local mode the app shows reminders only while it is open. Browser push notifications (Phase 2) need the user's permission and, on iPhone and iPad, Crest added to the home screen | S |
| FR-NOT-4 | Users are notified of invitations to a shared space, of being removed from one, and of a shared space being deleted | M |
8.12 Settings
| ID | Requirement | Priority |
|---|---|---|
| FR-SET-1 | Users can choose their base currency (any ISO 4217 currency; also the currency of their Personal space) and language (English, Bahasa Indonesia at launch) | M |
| FR-SET-2 | Users can choose light/dark theme | S |
| FR-SET-3 | Users can set the start day of the budget month for their Personal space (e.g. payday); Owners set it for a shared space | S |
| FR-SET-4 | Changing the base currency (or a shared space's currency) shows a warning, then asks the user (or Owner) to review that space's budgets, pre-converted with saved rates where available | S |
8.13 The Crest App and Websites
| ID | Requirement | Priority |
|---|---|---|
| FR-APP-1 | Users use Crest through the Crest app, a Progressive Web App at its own web address. It works in the browser on phones, tablets, and computers. The first release is web only | M |
| FR-APP-2 | The app can be added to the home screen and then opens full-screen with its own icon and name, like an app. The public website has an install page with the steps for the visitor's device (iPhone and iPad: Safari → Share → Add to Home Screen; Android and computers: the browser's Install option). The activation page and the activation email link to it | M |
| FR-APP-3 | When browser push notifications are introduced, the app asks once for permission, explaining what they are for | S |
| FR-APP-4 | Without internet, the app still opens, unlocks, and works fully in local mode. In connected mode it shows the data it last synced and accepts changes, with an Offline indicator | M |
| FR-APP-5 | When a new version is published, users get it automatically. The app finds out from a small public file on its own web address, so this works in local mode too. If the app is open, it shows "A new version is available" with a Reload button. If the open version is too old to work safely, it shows "Update required" and reloads before the user can continue | M |
| FR-APP-6 | The app is designed for phones. On tablets and computers it keeps its phone-width layout. The Super Admin portal and the public website are designed for web browsers | M |
| FR-APP-7 | Activating a login and resetting a password happen on the public website, so they work before the user has ever opened the app | M |
| FR-APP-8 | Native Android and iPhone apps, built from the same code and distributed through Google Play and the App Store, may follow when there is demand | W |
8.14 Contributions (future — Phase 4)
Only built if running costs need to be shared, and announced to users at least 30 days before it starts (BR-45). Crest never processes payments: users pay the owner directly (e.g. bank transfer or e-wallet), and the Super Admin records it.
| ID | Requirement | Priority |
|---|---|---|
| FR-SUB-1 | Super Admin can set a paid-until date for each user, and see who is paid, due soon, or lapsed | W |
| FR-SUB-2 | Super Admin can mark a user as exempt (e.g. family), so they never need to contribute | W |
| FR-SUB-3 | Users see their paid-until date and the payment instructions set by the Super Admin in Settings | W |
| FR-SUB-4 | Users get a reminder 30 days and 7 days before their paid-until date | W |
| FR-SUB-5 | After the paid-until date there is a 30-day grace period with full access | W |
| FR-SUB-6 | After the grace period the user is read-only in every space they belong to: they can view and export but cannot add or edit anything, until the Super Admin records a new payment. Other members of shared spaces are not affected | W |
| FR-SUB-7 | Every change to paid-until or exempt status is recorded in the audit log | W |
9. Non-Functional Requirements
| ID | Category | Requirement |
|---|---|---|
| NFR-1 | Accuracy | Money is stored as exact integers in minor units (never floating point). Balances are always derived from transactions. |
| NFR-2 | Security | Data encrypted in transit (TLS 1.2+) and at rest. A user can access only the spaces they are a member of, and only with the permissions of their role; this is enforced by the database (row-level security), not only by the app. No financial data in logs. In local mode the data lives in the browser's private storage on the person's device; the PIN lock hides it in the app but does not encrypt it. |
| NFR-3 | Privacy | Complies with data protection laws of the markets served (GDPR, Indonesia PDP Law, etc.); consent captured on the first launch of the app and on the request form; in local mode Crest collects no personal data; clear Privacy Policy explaining what shared-space members can see, what stays after deletion, how long deleted data remains in backups (at most 90 days), and that the operator has technical access to the server but commits never to look at users' financial data except to fix a problem the user reports; user can export and delete their data. No selling of user data. |
| NFR-4 | Performance | First visit: the app is usable within 5 s on a 4G connection (about 3 MB to download once). Later visits: ≤ 2 s (cached). Screens show data in ≤ 1 s; adding a transaction feels instant (optimistic update). |
| NFR-5 | Availability | Backend uptime ≥ 99.5%. Local mode does not depend on the backend, and core logging works offline in both modes. |
| NFR-6 | Scalability | Supports at least 500 connected users, 10k transactions per user, and 20 members per shared space without slowing down. There is no limit on the number of financial accounts or spaces per user. Larger scale is not a goal, but the design should not prevent it. People using local mode only download the app's static files, so their number is not limited by the server; if that traffic ever grows, the files can move to free static hosting. |
| NFR-7 | Usability | Add a transaction in ≤ 3 taps from the Home screen. Accessible font scaling and contrast. |
| NFR-8 | Localization | English and Bahasa Indonesia at launch; architecture supports adding languages without code changes. Locale-aware number, date, and currency formatting. Correct minor units per currency (e.g. JPY 0, USD 2, KWD 3). All timestamps stored in UTC and shown in the user's time zone. |
| NFR-9 | Platforms | The Crest app is a Progressive Web App built with Flutter. Supported: Safari on iPhone and iPad with iOS/iPadOS 16.4+, Chrome on Android 10+, and the latest two versions of Chrome, Safari, Edge, and Firefox on computers. The Super Admin portal and public website support the same browsers. The backend is a separate API used by all of them. Native Android and iPhone apps are not part of the first release (FR-APP-8). |
| NFR-10 | Backup | Daily automated, encrypted database backups: the last 30 daily copies and 3 monthly copies, so deleted data is gone from all backups within 90 days. Stored outside the Crest server (e.g. Biznet Gio NEO Object Storage). A restore is tested at least every 3 months. Point-in-time recovery is not required. |
| NFR-11 | Admin security | Admin portal enforces 2FA, session timeout after 30 minutes idle, and rate-limited login. Admin actions are authorized server-side, never only in the UI. |
| NFR-12 | Audit | Admin audit log entries cannot be edited or deleted and are kept for at least 1 year. |
| NFR-13 | Running cost | Running costs stay very low: target ≤ IDR 150,000 per month for the server, backup storage, domain, and email, for up to 500 connected users. Local-mode users add no cost beyond downloading the app's static files. Free tiers are used wherever they are enough. There are no app-store fees at launch; if native apps are published later, Google Play (USD 25 once) and the Apple Developer Program (USD 99 per year) are added. |
| NFR-14 | Data durability on devices | In connected mode the server is the source of truth: data the app keeps in the browser may be cleared by the browser at any time, or lost with the device, without losing anything already synced. In local mode the device holds the only copy, so it can be lost for the same reasons. The app reduces this risk by asking the browser to keep its data (FR-MOD-7), by asking iPhone users to install the app first (FR-MOD-6), and by backup files and reminders (FR-MOD-5, FR-MOD-8). |
| NFR-15 | Hosting | Crest runs on a self-managed VPS at Biznet Gio (NEO Lite) in Indonesia, so user data is stored in Indonesia. The server is hardened: automatic security updates, firewall open only for web traffic and key-based SSH, HTTPS certificates renewed automatically, database not reachable from the internet, and uptime monitoring with alerts to the owner. |
| NFR-16 | Recoverability | The whole server can be rebuilt from the repository and the latest backup by following a written runbook, within 4 hours. |
| NFR-17 | Web addresses | The public website is at crest.radityatama.web.id, the Crest app at app.crest.radityatama.web.id, the backend API at api.crest.radityatama.web.id, and the Super Admin portal at admin.crest.radityatama.web.id, all over HTTPS only. Emails are sent from no-reply@radityatama.web.id; the public contact address is contact@radityatama.web.id (forwarded to the owner). The domain is registered at Biznet Gio, and its DNS is hosted there too (Biznet NEO DNS, no proxy). The domain is a configuration setting, so it can change later without code changes. |
| NFR-18 | Data retention | Rejected access requests are deleted after 6 months. Server logs are kept for 14 days. The admin audit log is kept for at least 1 year (NFR-12). Backups follow NFR-10. |
10. Business Rules
| ID | Rule |
|---|---|
| BR-1 | Each financial account has exactly one currency; transactions inherit the financial account's currency. |
| BR-2 | Transfers between financial accounts, in the same space or across spaces, do not count as income or expense. |
| BR-3 | Financial account balance = opening balance + sum of all its transactions. |
| BR-4 | Budget periods start on the space's configured start day (default: 1st of month). |
| BR-5 | Deleting a category does not delete its transactions; they become "Uncategorized". |
| BR-6 | Deleting a financial account requires confirmation and deletes its transactions; archiving keeps them. Transfers to or from other financial accounts are not deleted on the other side: each becomes an ordinary expense or income there (e.g. "Transfer to deleted financial account"), so the other financial accounts' balances do not change. |
| BR-7 | Crest never initiates payments or moves money. |
| BR-8 | A user can only be created by the Super Admin, either by approving an access request or by creating it directly. |
| BR-9 | One email address maps to at most one user. |
| BR-10 | Activation links are single-use and expire after 72 hours. |
| BR-11 | Deactivating a user keeps their data; only deletion removes it. Deletion cannot be undone. The only data that remains after deletion is transactions they added in shared spaces (BR-34). |
| BR-12 | The Super Admin role manages access only; it grants no access to users' financial data. |
| BR-13 | There must always be at least one active Super Admin; the last one cannot be deactivated, deleted, or demoted. |
| BR-14 | A rejected requester may submit a new request after 30 days. Within those 30 days, a new request from that email gets the same neutral confirmation, and nothing is created or emailed. |
| BR-15 | Exchange rates are always entered manually by the user; Crest does not fetch rates from external services. |
| BR-16 | A cross-currency transfer stores the amount sent, the amount received, and the rate used. Later rate changes never alter past transactions. |
| BR-17 | Converted totals are estimates for display only; financial account balances always stay in that financial account's own currency. |
| BR-18 | Spending with a credit card is an expense when the purchase is made; paying the card bill is a transfer, so the same spending is not counted twice. |
| BR-19 | Crest stores at most the last 4 digits of any card or bank account number, never the full number, CVV, PIN, or login details. |
| BR-20 | Crest is its own and only identity provider. Users and the Super Admin authenticate only with Crest-managed credentials (email + password; a PIN for unlocking; 2FA for the Super Admin); no third-party identity provider is used. |
| BR-21 | Sync conflicts in connected mode: for each transaction, the last change received by the server wins, and a delete wins over an edit. Unsynced changes from a user who has been deactivated are discarded. |
| BR-22 | Budgets are always set in the space's currency. |
| BR-23 | Crest records what really happened: negative balances, spending over a credit limit, and overpaid credit cards are allowed, never blocked. |
| BR-24 | A refund reduces spending in its category (and the related budget). It is never counted as income. |
| BR-25 | A recurrence on day 29, 30, or 31 falls on the last day of shorter months. |
| BR-26 | A financial account's currency is fixed once it has any transaction. |
| BR-27 | Crest never processes payments. Contributions are paid outside Crest and recorded by the Super Admin. |
| BR-28 | A user whose contribution has lapsed always keeps read and export access to their own data and their spaces. Their data is never deleted because of non-payment. |
| BR-29 | The contribution amount is set only to cover Crest's running costs, not to make a profit. |
| BR-30 | Every financial account, category, budget, and savings goal belongs to exactly one space. A user can see and use them only if they are a member of that space. |
| BR-31 | A transaction's category must belong to the same space as its financial account. |
| BR-32 | A Personal space always has exactly one member, its user. |
| BR-33 | Every shared space has at least one Owner. If the last Owner is deleted, the longest-standing member becomes Owner; if there are no other members, the space and all its data are deleted. |
| BR-34 | When a member leaves or is removed, transactions they added stay in the space with their name. When a user is deleted, those transactions stay and are labelled "Former member". |
| BR-35 | In a transfer between spaces, members see only the side in their own space. The other side is shown as the person who made the transfer, never as the other financial account or its balance. |
| BR-36 | Members can edit or delete only transactions they added; Owners can edit or delete any transaction in their space. |
| BR-37 | Financial accounts can't be moved between spaces. |
| BR-38 | Requests for money between members (e.g. staff asking the Boss for more) happen outside Crest. Crest records only the resulting transfer. |
| BR-39 | Only Active users can join a shared space, and only by accepting an invitation, which expires after 14 days. |
| BR-40 | A recurring transaction in a shared space belongs to the member who set it up and stops when that member leaves the space. |
| BR-41 | Super Admin is a role held by a user. A Super Admin also uses Crest as a normal user, with their own Personal space and shared spaces; the role only adds access to the portal. There can be several Super Admins. |
| BR-42 | Balances and net worth are always shown as of now. A future-dated transaction affects them only once its date arrives, except in the "after upcoming" figure and in the budget of its own period. |
| BR-43 | Deactivating a user does not change their space memberships. Their shared spaces keep working for the other members. If they were a space's only Owner, nobody can manage that space until they are reactivated, or deleted (then BR-33 applies). |
| BR-44 | Crest users must be 18 or older, confirmed on the first launch of the app (local mode) and again on the access-request form. |
| BR-45 | Users are told in Crest and by email at least 14 days before important changes to the Privacy Policy or Terms of Use take effect, and at least 30 days before contributions start or Crest shuts down. |
| BR-46 | In local mode Crest receives no personal or financial data, has no copy of what the person records, and cannot recover or reset it. |
| BR-47 | A device's local data is uploaded into a user's Personal space only when that space is empty on the server. Otherwise the person chooses to use the server's data (after being offered a backup file of the local data) or to keep the device's data local only. Local data is never merged into existing server data automatically. |
| BR-48 | Every record is identified by an ID created on the device, so uploading or restoring the same record twice never creates a duplicate. |
| BR-49 | In local mode a wrong PIN only slows down further attempts; it never erases data, because the device holds the only copy. If the PIN is forgotten, the way back in is to erase the app's data on that device and restore a backup file. (In connected mode five wrong attempts log the user out and clear the local copy, because the server has the data.) |
| BR-50 | After a forced logout (the user was deactivated or deleted), the app removes the synced data from the device and continues in local mode with an empty start. |
11. Release Roadmap
| Phase | Scope | Target |
|---|---|---|
| Phase 1a — Local app (ships first, no server needed) | The Crest app (PWA) in local mode: first-launch welcome, financial accounts, transactions, categories, budgets, Home and Stats, search, CSV export, backup file, optional PIN, update notice; public website (landing, install, privacy, terms) | TBD |
| Phase 1b — Connected | Backend API, Super Admin portal, access requests, login, connect and upload of local data, sync between devices, server backup, spaces and sharing, email | TBD |
| Phase 2 — Engagement | Recurring transactions, savings goals, notifications, CSV import, cross-currency transfers, manual exchange rates (these work in both modes, except notifications) | TBD |
| Phase 3 — Automation | Auto-categorization; bank/e-wallet sync via aggregator only if affordable | TBD |
| Phase 4 — Contributions | Manual yearly contributions (§8.14), only when running costs need to be shared | When needed |
| Phase 5 — Expansion | Investments, more languages | TBD |
| Native apps | Android and iPhone apps from the same Flutter code, with device biometrics and store distribution (FR-APP-8) | When there is demand |
12. Assumptions & Constraints
Assumptions
- Local-mode users can be anyone and cost nothing to serve. Connected users are the owner and people they know; expected size is tens of users, possibly growing to a few hundred.
- Users may live in different countries and choose their own base currency.
- Users use Crest on their phones; the Super Admin mostly uses a computer.
- All user data is hosted in Indonesia (Biznet Gio).
- Users are comfortable entering transactions manually and adding a web app to their home screen with a short guide.
- Crest is free now. A yearly contribution to cover running costs may be introduced later (Phase 4).
- Access to connected mode is invite-only; connected user numbers grow at the pace the Super Admin approves requests.
- A single person (the owner) acts as Super Admin at launch; other users may be given the role later.
- People who share a space trust each other (couples, families, a boss and staff); every member of a space can see everything in it.
Constraints
- Built and run by one person (the owner) on a single self-managed VPS; the stack must stay small and simple enough for one person to maintain, update, and restore.
- Must comply with the data protection laws of the countries where users live before inviting them.
- iPhone and iPad limits for web apps: no automatic install prompt, push notifications only after adding to the home screen, and stored data may be cleared if Crest is not used for a while. Safari clears the storage of websites it was not used on for about a week, and a home-screen app keeps its data separately from Safari, so local-mode data on iPhone is safe only in the home-screen app (UJ-38).
- A Flutter web app downloads about 3 MB on the first visit, more than an ordinary website.
- One person maintains four parts (backend, the Crest app, admin portal, public site), so each must stay small.
- Bank syncing depends on third-party aggregator availability, cost, and licensing.
13. Risks
| Risk | Impact | Likelihood | Mitigation |
|---|---|---|---|
| Users stop logging after a few days | High | High | Very fast entry, reminders, recurring transactions |
| Data breach erodes trust | High | Low | Row-level security, encryption, security review before launch |
| Bank aggregator cost or coverage is poor | Medium | Medium | Keep bank sync out of MVP; design data model to support it later |
| Regulatory change | Medium | Low | Legal review; avoid moving money or giving advice |
| iPhone and iPad limits for web apps (manual install, push only after install, on-device data may be cleared) | High | Medium | Install page (FR-APP-2); iPhone users install first (FR-MOD-6); server as source of truth for connected users (NFR-14); backup file and reminders for local users; in-app notification list and email |
| Local-mode users lose their only copy (browser clears data, device lost or reset) | High | Medium | Persistent-storage request (FR-MOD-7), plain warning before data is entered (FR-MOD-6), backup file with reminders (FR-MOD-5, FR-MOD-8), easy invitation to connect for people the owner knows |
| Data stored in local mode is not encrypted, so someone with access to the unlocked device's browser data could read it | Medium | Low | The PIN stops casual access; the phone's own screen lock is the real protection; say so in the Privacy Policy; consider encrypting with the PIN later (§14) |
| Money rules in the app and in the API differ, so uploaded local data is rejected or counted differently | Medium | Low | Both run the same test vectors (shared money-test-vectors); the API validates every uploaded record |
| The first visit feels slow because the app is a large download | Low | Medium | Loading screen with the Crest logo, caching so later visits are fast (NFR-4), public pages kept separate and light |
| Maintaining four separate parts is too much for one person | Medium | Medium | Generated API clients from one contract, shared money test cases, small admin portal and static public site |
| The owner holds friends' and family's financial data | High | Low | Super Admin cannot see financial data, encryption, easy export and delete, clear privacy policy |
| Super Admin login is compromised | High | Low | Mandatory 2FA, audit log, no admin access to financial data |
| Access requests pile up and requesters lose interest | Medium | Medium | New-request email alerts, pending count on portal overview |
| Spam or bot access requests | Low | Medium | Rate limiting and bot protection on request form |
| Users live in countries with different privacy laws | Medium | Medium | Design to GDPR standard (strictest common baseline); check the rules of a new country before inviting people there |
| A user adds a private expense to a shared space by mistake, or members misunderstand what others can see | Medium | Medium | Current space always visible at the top; the entry form shows which space a financial account belongs to; clear explanation when joining a space; members can delete their own entries |
| Keeping a deleted user's shared-space transactions conflicts with "delete all my data" | Medium | Low | Only transactions they added in shared spaces stay, labelled "Former member"; explained in the privacy policy and in the delete warning |
| Running costs grow with no revenue | Medium | Medium | Low fixed-cost stack (NFR-13); local mode costs nothing per user; invite-only access controls the part that costs money; optional yearly contribution (Phase 4) |
| The self-managed server is hacked or misconfigured | High | Low | Hardening and automatic updates (NFR-15), database not exposed to the internet, encryption, row-level security, off-server backups |
| The server fails or data is lost | High | Low | Daily off-server backups (NFR-10), tested restores, written rebuild runbook (NFR-16) |
| Server maintenance takes too much of the owner's time | Medium | Medium | Small stack, automatic updates and certificate renewal, container-based deployment, monitoring with alerts |
14. Open Questions
- Target launch date?
- Contribution amount, payment methods, and when to start (decide when running costs need sharing).
- Whether Crest will later be owned by an organisation instead of the owner personally.
- Whether the backup file should be protected with a password, and whether data on the device should be encrypted with the PIN (local mode).
- How a local user who is later invited and has data on several devices should merge them (for now: one device uploads, the others use the server's data, BR-47).
15. Glossary
| Term | Definition |
|---|---|
| User | A person who can log in to Crest (connected mode). Has an email, password, and status (Pending, Invited, Active, …). Created and managed by the Super Admin. Never called an "account". |
| Financial account | Any place where money is held or owed: cash wallet, bank, e-wallet / online payment, or credit card. Belongs to one space and is managed by that space's Owners. |
| Liability | Money owed, such as a credit card balance. Subtracted when calculating net worth. |
| Access request | A person's request to be given access to connected mode and become a Crest user. |
| Super Admin | A role that a user can have, allowing them to approve access requests and manage users through the admin portal. Several users can have it. |
| Activation link | Single-use, time-limited link emailed to an approved user to set their password. |
| Audit log | Permanent record of every admin action. |
| Transaction | A single income, expense, refund, or transfer entry. |
| Refund | Money returned for an earlier purchase. Reduces spending in its category instead of counting as income. |
| Transfer | Movement of money between two financial accounts, in the same space or in different spaces. |
| Space | A container for financial accounts, categories, budgets, and savings goals, with a list of members who can see it. |
| Personal space | The private space every user gets automatically. Only that user is a member. |
| Shared space | A space with more than one possible member, created by a user, who becomes its first Owner. |
| Owner | A member of a space who can manage its setup (financial accounts, categories, budgets, members) and edit any of its transactions. |
| Member | A member of a space who can see everything in it and add transactions, but edit or delete only their own. |
| Invitation | An Owner's request for an Active user to join a shared space. Must be accepted; expires after 14 days. |
| Budget | A spending limit for a category in a space over a period. |
| Minor unit | Smallest unit of a currency (e.g. cents for USD). The number of decimal places differs by currency (JPY and IDR 0, USD 2, KWD 3). |
| Aggregator | Third-party service that connects to banks to retrieve transaction data. |
| Exchange rate | How much one unit of a currency is worth in another. In Crest, entered manually by the user. |
| Base currency | The currency a user chooses for their Personal space and for their total net worth across spaces. |
| Crest app | The app people use. In the first release it is a Progressive Web App; the same Flutter code can later be published as Android and iPhone apps. |
| Local mode | Using the Crest app with no login. The data stays on the device and is never sent to Crest's servers. Open to anyone. |
| Connected mode | Using the Crest app while logged in as a user. The data syncs with Crest's server, which allows several devices, shared spaces, and a server backup. Only for people who have been given access. |
| Connect | Logging in from the app so that a device moves from local mode to connected mode (More → Connect to Crest). |
| Backup file | A file the person saves from the app that holds all their data, and that can be restored on the same or another device. |
| PWA (Progressive Web App) | A web app that can be added to the home screen and then opens and works like an app, including without internet. |
| Public website | The pages at crest.radityatama.web.id: what Crest is, request access, activate, reset password, install, privacy, and terms. |
| API | The backend that the Crest app, the Super Admin portal, and the public website all talk to. |
| App lock | Protection that asks for the Crest PIN before showing any data. |
| Contribution | A future, optional yearly payment from a user to cover Crest's running costs, paid outside Crest and recorded by the Super Admin. |
| Paid-until date | The date a user's contribution covers them until. |
| VPS (Virtual Private Server) | A rented virtual server. Crest runs on one at Biznet Gio, maintained by the owner. |
16. Approval
| Name | Role | Signature | Date |
|---|---|---|---|
| Product owner | |||
| Engineering lead |