Personal · Weekend build
Build your own Splitwise
Who owes whom, minus the group-chat forensics. Splitwise charges $3.33–$4.99 per month — that’s $40–$60 a year — for something you can replace with focused software of your own. Here is the honest scope, the honest timeline, and the exact prompt to hand your coding agent.
Who this replacement is for
This build targets housemates and trip groups splitting shared costs. The goal: track who paid what and settle up with the fewest possible transfers. If you need more than that, keep paying — the point of building it yourself is owning a tool shaped exactly like your workflow, not re-implementing a venture-funded roadmap.
Same build, different logo: this v1 also replaces Tricount and Settle Up — they all solve the same core job.
How long it actually takes
One number would be a lie, so here are three. Each tier is a real, usable product — pick the one that matches how much of Splitwise you actually use.
| Estimate | What you get |
|---|---|
| 8 hours | groups, unequal splits, balances, simplified debts |
| 2 days | receipt uploads, recurring expenses, comments, email reminders |
| 1 month+ | mobile apps, payment integrations, currencies, receipt scanning — the part you should probably skip |
What a minimal Splitwise alternative needs
- groups with invite links and member balances
- expenses with equal, percentage, share, and exact-amount splits
- running balances derived from the expense ledger
- debt simplification that minimizes who pays whom
- settle-up recording with an append-only activity history
Data model
Group, Member, Expense, ExpenseShare, Settlement
Integrations
transactional email
Capability context
Astro, HTMX, D1
The guardrail
Store amounts as integer minor units, require splits to sum exactly to the expense total, and never move real money.
Deliberate non-goals
Do not integrate payment providers, sync bank accounts, convert currencies, scan receipts, or build mobile apps.
The complete build prompt
Copy this into your coding agent of choice. It is scoped for a useful v1 — journeys, screens, business rules, data model, security, tests, and acceptance scenarios included. Pick your stack:
You are building a production-ready software product named “Evensteven”, a deliberately focused alternative to Splitwise. Build a complete, usable vertical slice—not a landing page, static mockup, or disconnected collection of components. WORKING AGREEMENT Before writing implementation code, produce a short technical plan that names the routes or pages, server actions or endpoints, data tables, important state transitions, authorization boundaries, background jobs, and external adapters. Resolve contradictions in favor of the narrow audience and non-goals below. Prefer a small, legible architecture over speculative abstraction, but do not omit persistence, validation, error handling, or tests. PRODUCT BRIEF Primary user: housemates and trip groups splitting shared costs. Primary outcome: track who paid what and settle up with the fewest possible transfers. Product principle: optimize the exact workflow below instead of copying the full breadth of Splitwise. A first-time user should understand what to do from the interface itself, without a tour or documentation. END-TO-END USER JOURNEYS Implement all of these flows through the real interface and persistent data layer: 1. A member creates a group, invites housemates by link, adds a grocery expense split unevenly, and everyone sees updated balances. 2. A member opens the balances view, follows the simplified who-pays-whom plan, records a settle-up payment, and the debt disappears. 3. A member corrects a mis-entered expense amount, the activity log records the change, and all balances recompute from the ledger. SCREENS AND INFORMATION ARCHITECTURE Build these as coherent responsive views. Each screen must specify its primary action, secondary actions, visible status, validation feedback, empty state, loading or pending state, success confirmation, and recoverable failure state. 1. Group overview: member balances at a glance, who-pays-whom suggestions, recent expenses, and add-expense and settle-up actions. 2. Expense form: amount, payer, description, date, and equal, percentage, share, or exact-amount split modes with a live remainder check. 3. Balances: each member’s net position, the minimized settlement plan, and a record-payment action beside every suggested transfer. 4. Activity: an append-only feed of expenses added, edited, deleted, and settlements recorded, with who did what and when. CORE CAPABILITIES 1. groups with invite links and member balances 2. expenses with equal, percentage, share, and exact-amount splits 3. running balances derived from the expense ledger 4. debt simplification that minimizes who pays whom 5. settle-up recording with an append-only activity history DETAILED BEHAVIOR AND BUSINESS RULES Treat these as server-enforced product requirements, not interface suggestions: 1. Store every amount as integer minor units in one group currency; splits must sum exactly to the total, with remainder cents assigned deterministically. 2. Derive all balances from the ledger of expenses and settlements rather than storing mutable running totals. 3. Compute the settlement plan by minimizing the number of transfers between members, and present it as a suggestion that never moves money. 4. Authorize every action by group membership, use unguessable invite links, and record edits and deletions in the activity log instead of erasing history. DATA MODEL AND LIFECYCLE Design a small relational schema centered on Group, Member, Expense, ExpenseShare, Settlement. Before implementing it, document: 1. Each table’s purpose, primary key, ownership or tenant boundary, timestamps, status fields, and important attributes. 2. Foreign keys, uniqueness constraints, check constraints, indexes needed by the named screens, and transaction boundaries for multi-record changes. 3. The allowed lifecycle or state transitions, who may trigger each transition, which transitions are terminal or reversible, and what audit history must remain immutable. 4. Archive, retention, and deletion behavior, including what happens to dependent records and external files. 5. Idempotency strategy for submissions, jobs, imports, notifications, webhooks, or retries where applicable. Use migrations rather than ad-hoc schema creation. Store time instants consistently and retain named timezone context whenever local schedules or dates matter. Never rely on a counter, disabled button, or client-side check to preserve a business invariant. USERS, AUTHENTICATION, AND PERMISSIONS Implement only the roles required by the stated audience. Make the ownership and visibility model explicit before coding. Enforce authorization in every server-side query and mutation, including search, exports, attachments, live updates, and guessed URLs—not merely by hiding controls. Use secure session defaults, protect state-changing requests, and provide an understandable signed-out, expired-session, and forbidden state. Seed distinct users when multiple roles are required so permissions can be demonstrated and tested. INTERACTION AND VISUAL DIRECTION The product should feel fast, calm, focused, and credible rather than like a generic admin template. Use a clear visual hierarchy, restrained color, readable typography, generous hit targets, and consistent placement for primary actions. Start with server-rendered HTML and progressively enhance only the interactions that benefit from it. The core workflow must remain understandable if enhancement fails. Start with server-rendered Astro pages and ordinary HTML forms. Use HTMX for form submissions, partial navigation, and server-driven updates, then Alpine.js only for small local browser state. The core workflow must remain understandable if either enhancement layer fails. Design mobile layouts intentionally instead of simply stacking desktop panels. Support keyboard navigation, visible focus, semantic landmarks, explicit labels, useful page titles, reduced-motion preferences, and screen-reader announcements for asynchronous results. Never use color alone to communicate state. Destructive actions require clear scope and confirmation; safe repeated actions should be idempotent. TECHNICAL DIRECTION Build this version with the AHA stack: Astro for routing, layouts, and server-rendered pages; HTMX for interactions that benefit from HTML fragment responses; and Alpine.js for small, local interface state. Prefer Cloudflare D1 for relational persistence, R2 for object storage, Workers for server endpoints and scheduled work, Durable Objects only for coordinated real-time state, and Workflows or Queues for durable background jobs—but only when the product requirements call for them. Keep domain rules in testable server-side modules instead of route handlers or UI components. Separate persistence, external providers, and background work behind small interfaces without building a framework. Prefer ordinary HTML forms and URLs for durable navigation; use optimistic interaction only when failure can be reconciled clearly. The product brief currently identifies Astro, HTMX, D1 as capability context. Preserve any required native, browser-only, edge, storage, real-time, or background-processing capability through a narrow adapter appropriate to the selected framework. If the core workflow genuinely requires native or browser APIs, keep that runtime as the primary execution surface rather than simulating inaccessible capabilities or inventing an unnecessary web surface. Integrate with transactional email. For every integration: - List required environment variables in an .env.example without real secrets. - Add a small adapter with timeouts, normalized errors, and a deterministic local fake or development path. - Verify inbound signatures and deduplicate provider events where supported. - Keep credentials server-side, encrypt long-lived provider tokens at rest, and redact secrets and sensitive payloads from logs. - Define retry, backoff, and idempotency behavior for any side effect that can be repeated. SECURITY AND PRIVACY Store amounts as integer minor units, require splits to sum exactly to the expense total, and never move real money. Validate, normalize, and length-limit all untrusted input on the server. Escape rendered content by default, sanitize any intentionally accepted markup, rate-limit public or abuse-prone actions, and use private object storage plus short-lived authorized URLs for sensitive files. Collect the minimum personal data necessary for the named workflow. Document retention and deletion behavior. Add specific protections for the riskier surfaces in this app, such as uploads, redirects, outbound requests, email delivery, OAuth, webhooks, CSV import or export, and real-time connections. ACCEPTANCE SCENARIOS Automate these app-specific scenarios at the most appropriate level: 1. Given a 100.00 expense split three ways, the shares sum to exactly 10000 minor units with the extra cent assigned predictably. 2. Given settlements recorded to match the plan, every member’s balance reaches zero and the group shows all settled up. 3. Given a deleted expense, balances recompute, the activity log keeps the deletion visible, and no orphaned shares remain. TESTING Add focused unit tests for state transitions, authorization predicates, normalization, date or money calculations, and other risky domain rules. Add integration tests for persistence constraints and each external adapter’s success, timeout, retry, and rejection paths. Add at least one browser-level test for every end-to-end journey above, including one small-screen viewport. Tests must use isolated data and run through a documented single command. OPERATIONS AND FAILURE RECOVERY Add structured server logs with request, job, or event correlation IDs but no secrets or unnecessarily sensitive data. Make failures actionable in both the interface and logs. Background work must expose pending, succeeded, failed, and retrying states where relevant; do not silently swallow errors. Include safe database migration and rollback guidance, seed data, backup and restore notes, external-data cleanup behavior, and a basic health or diagnostic path appropriate to the stack. DELIVERABLES Ship the working application, migrations, representative seed data, tests, .env.example, and a concise README. The README must cover prerequisites, local setup, environment variables, migrations, seed and test commands, deployment, integration setup, backup and restore, security decisions, and known limitations. Seed data should exercise the happy path plus at least one empty, failed, overdue, expired, archived, or permission-restricted state relevant to the product. DEFINITION OF DONE The app is complete when a fresh developer can follow the README, create and migrate the database, run the app, sign in as each relevant role, complete every named journey using real persisted data, refresh without losing state, recover from common failures, and use the core interface on phone and desktop. All acceptance scenarios pass, permission boundaries are covered by tests, and no core screen is left as a placeholder. NON-GOALS Do not integrate payment providers, sync bank accounts, convert currencies, scan receipts, or build mobile apps.
You are building a production-ready software product named “Evensteven”, a deliberately focused alternative to Splitwise. Build a complete, usable vertical slice—not a landing page, static mockup, or disconnected collection of components. WORKING AGREEMENT Before writing implementation code, produce a short technical plan that names the routes or pages, server actions or endpoints, data tables, important state transitions, authorization boundaries, background jobs, and external adapters. Resolve contradictions in favor of the narrow audience and non-goals below. Prefer a small, legible architecture over speculative abstraction, but do not omit persistence, validation, error handling, or tests. PRODUCT BRIEF Primary user: housemates and trip groups splitting shared costs. Primary outcome: track who paid what and settle up with the fewest possible transfers. Product principle: optimize the exact workflow below instead of copying the full breadth of Splitwise. A first-time user should understand what to do from the interface itself, without a tour or documentation. END-TO-END USER JOURNEYS Implement all of these flows through the real interface and persistent data layer: 1. A member creates a group, invites housemates by link, adds a grocery expense split unevenly, and everyone sees updated balances. 2. A member opens the balances view, follows the simplified who-pays-whom plan, records a settle-up payment, and the debt disappears. 3. A member corrects a mis-entered expense amount, the activity log records the change, and all balances recompute from the ledger. SCREENS AND INFORMATION ARCHITECTURE Build these as coherent responsive views. Each screen must specify its primary action, secondary actions, visible status, validation feedback, empty state, loading or pending state, success confirmation, and recoverable failure state. 1. Group overview: member balances at a glance, who-pays-whom suggestions, recent expenses, and add-expense and settle-up actions. 2. Expense form: amount, payer, description, date, and equal, percentage, share, or exact-amount split modes with a live remainder check. 3. Balances: each member’s net position, the minimized settlement plan, and a record-payment action beside every suggested transfer. 4. Activity: an append-only feed of expenses added, edited, deleted, and settlements recorded, with who did what and when. CORE CAPABILITIES 1. groups with invite links and member balances 2. expenses with equal, percentage, share, and exact-amount splits 3. running balances derived from the expense ledger 4. debt simplification that minimizes who pays whom 5. settle-up recording with an append-only activity history DETAILED BEHAVIOR AND BUSINESS RULES Treat these as server-enforced product requirements, not interface suggestions: 1. Store every amount as integer minor units in one group currency; splits must sum exactly to the total, with remainder cents assigned deterministically. 2. Derive all balances from the ledger of expenses and settlements rather than storing mutable running totals. 3. Compute the settlement plan by minimizing the number of transfers between members, and present it as a suggestion that never moves money. 4. Authorize every action by group membership, use unguessable invite links, and record edits and deletions in the activity log instead of erasing history. DATA MODEL AND LIFECYCLE Design a small relational schema centered on Group, Member, Expense, ExpenseShare, Settlement. Before implementing it, document: 1. Each table’s purpose, primary key, ownership or tenant boundary, timestamps, status fields, and important attributes. 2. Foreign keys, uniqueness constraints, check constraints, indexes needed by the named screens, and transaction boundaries for multi-record changes. 3. The allowed lifecycle or state transitions, who may trigger each transition, which transitions are terminal or reversible, and what audit history must remain immutable. 4. Archive, retention, and deletion behavior, including what happens to dependent records and external files. 5. Idempotency strategy for submissions, jobs, imports, notifications, webhooks, or retries where applicable. Use migrations rather than ad-hoc schema creation. Store time instants consistently and retain named timezone context whenever local schedules or dates matter. Never rely on a counter, disabled button, or client-side check to preserve a business invariant. USERS, AUTHENTICATION, AND PERMISSIONS Implement only the roles required by the stated audience. Make the ownership and visibility model explicit before coding. Enforce authorization in every server-side query and mutation, including search, exports, attachments, live updates, and guessed URLs—not merely by hiding controls. Use secure session defaults, protect state-changing requests, and provide an understandable signed-out, expired-session, and forbidden state. Seed distinct users when multiple roles are required so permissions can be demonstrated and tested. INTERACTION AND VISUAL DIRECTION The product should feel fast, calm, focused, and credible rather than like a generic admin template. Use a clear visual hierarchy, restrained color, readable typography, generous hit targets, and consistent placement for primary actions. Start with server-rendered HTML and progressively enhance only the interactions that benefit from it. The core workflow must remain understandable if enhancement fails. Render with React Server Components by default. Use Server Actions for authenticated form mutations and add Client Components only for interactions that genuinely require browser state, browser APIs, drag-and-drop, or live updates. The core workflow must remain understandable before client-side JavaScript finishes loading. Design mobile layouts intentionally instead of simply stacking desktop panels. Support keyboard navigation, visible focus, semantic landmarks, explicit labels, useful page titles, reduced-motion preferences, and screen-reader announcements for asynchronous results. Never use color alone to communicate state. Destructive actions require clear scope and confirmation; safe repeated actions should be idempotent. TECHNICAL DIRECTION Build this version with Next.js, the App Router, and TypeScript. Use Server Components by default, Server Actions for authenticated mutations, and Route Handlers for public APIs, OAuth callbacks, webhooks, feeds, uploads, and downloads. Use PostgreSQL through Drizzle ORM with versioned migrations and an isolated test database. Access S3-compatible object storage through a server-only adapter, and run slow or retryable work in a real job or workflow system instead of the request lifecycle. Keep domain rules in testable server-side modules instead of route handlers or UI components. Separate persistence, external providers, and background work behind small interfaces without building a framework. Prefer ordinary HTML forms and URLs for durable navigation; use optimistic interaction only when failure can be reconciled clearly. The product brief currently identifies Astro, HTMX, D1 as capability context. Preserve any required native, browser-only, edge, storage, real-time, or background-processing capability through a narrow adapter appropriate to the selected framework. If the core workflow genuinely requires native or browser APIs, keep that runtime as the primary execution surface rather than simulating inaccessible capabilities or inventing an unnecessary web surface. Integrate with transactional email. For every integration: - List required environment variables in an .env.example without real secrets. - Add a small adapter with timeouts, normalized errors, and a deterministic local fake or development path. - Verify inbound signatures and deduplicate provider events where supported. - Keep credentials server-side, encrypt long-lived provider tokens at rest, and redact secrets and sensitive payloads from logs. - Define retry, backoff, and idempotency behavior for any side effect that can be repeated. SECURITY AND PRIVACY Store amounts as integer minor units, require splits to sum exactly to the expense total, and never move real money. Validate, normalize, and length-limit all untrusted input on the server. Escape rendered content by default, sanitize any intentionally accepted markup, rate-limit public or abuse-prone actions, and use private object storage plus short-lived authorized URLs for sensitive files. Collect the minimum personal data necessary for the named workflow. Document retention and deletion behavior. Add specific protections for the riskier surfaces in this app, such as uploads, redirects, outbound requests, email delivery, OAuth, webhooks, CSV import or export, and real-time connections. ACCEPTANCE SCENARIOS Automate these app-specific scenarios at the most appropriate level: 1. Given a 100.00 expense split three ways, the shares sum to exactly 10000 minor units with the extra cent assigned predictably. 2. Given settlements recorded to match the plan, every member’s balance reaches zero and the group shows all settled up. 3. Given a deleted expense, balances recompute, the activity log keeps the deletion visible, and no orphaned shares remain. TESTING Add focused unit tests for state transitions, authorization predicates, normalization, date or money calculations, and other risky domain rules. Add integration tests for persistence constraints and each external adapter’s success, timeout, retry, and rejection paths. Add at least one browser-level test for every end-to-end journey above, including one small-screen viewport. Tests must use isolated data and run through a documented single command. OPERATIONS AND FAILURE RECOVERY Add structured server logs with request, job, or event correlation IDs but no secrets or unnecessarily sensitive data. Make failures actionable in both the interface and logs. Background work must expose pending, succeeded, failed, and retrying states where relevant; do not silently swallow errors. Include safe database migration and rollback guidance, seed data, backup and restore notes, external-data cleanup behavior, and a basic health or diagnostic path appropriate to the stack. DELIVERABLES Ship the working application, migrations, representative seed data, tests, .env.example, and a concise README. The README must cover prerequisites, local setup, environment variables, migrations, seed and test commands, deployment, integration setup, backup and restore, security decisions, and known limitations. Seed data should exercise the happy path plus at least one empty, failed, overdue, expired, archived, or permission-restricted state relevant to the product. DEFINITION OF DONE The app is complete when a fresh developer can follow the README, create and migrate the database, run the app, sign in as each relevant role, complete every named journey using real persisted data, refresh without losing state, recover from common failures, and use the core interface on phone and desktop. All acceptance scenarios pass, permission boundaries are covered by tests, and no core screen is left as a placeholder. NON-GOALS Do not integrate payment providers, sync bank accounts, convert currencies, scan receipts, or build mobile apps.
You are building a production-ready software product named “Evensteven”, a deliberately focused alternative to Splitwise. Build a complete, usable vertical slice—not a landing page, static mockup, or disconnected collection of components. WORKING AGREEMENT Before writing implementation code, produce a short technical plan that names the routes or pages, server actions or endpoints, data tables, important state transitions, authorization boundaries, background jobs, and external adapters. Resolve contradictions in favor of the narrow audience and non-goals below. Prefer a small, legible architecture over speculative abstraction, but do not omit persistence, validation, error handling, or tests. PRODUCT BRIEF Primary user: housemates and trip groups splitting shared costs. Primary outcome: track who paid what and settle up with the fewest possible transfers. Product principle: optimize the exact workflow below instead of copying the full breadth of Splitwise. A first-time user should understand what to do from the interface itself, without a tour or documentation. END-TO-END USER JOURNEYS Implement all of these flows through the real interface and persistent data layer: 1. A member creates a group, invites housemates by link, adds a grocery expense split unevenly, and everyone sees updated balances. 2. A member opens the balances view, follows the simplified who-pays-whom plan, records a settle-up payment, and the debt disappears. 3. A member corrects a mis-entered expense amount, the activity log records the change, and all balances recompute from the ledger. SCREENS AND INFORMATION ARCHITECTURE Build these as coherent responsive views. Each screen must specify its primary action, secondary actions, visible status, validation feedback, empty state, loading or pending state, success confirmation, and recoverable failure state. 1. Group overview: member balances at a glance, who-pays-whom suggestions, recent expenses, and add-expense and settle-up actions. 2. Expense form: amount, payer, description, date, and equal, percentage, share, or exact-amount split modes with a live remainder check. 3. Balances: each member’s net position, the minimized settlement plan, and a record-payment action beside every suggested transfer. 4. Activity: an append-only feed of expenses added, edited, deleted, and settlements recorded, with who did what and when. CORE CAPABILITIES 1. groups with invite links and member balances 2. expenses with equal, percentage, share, and exact-amount splits 3. running balances derived from the expense ledger 4. debt simplification that minimizes who pays whom 5. settle-up recording with an append-only activity history DETAILED BEHAVIOR AND BUSINESS RULES Treat these as server-enforced product requirements, not interface suggestions: 1. Store every amount as integer minor units in one group currency; splits must sum exactly to the total, with remainder cents assigned deterministically. 2. Derive all balances from the ledger of expenses and settlements rather than storing mutable running totals. 3. Compute the settlement plan by minimizing the number of transfers between members, and present it as a suggestion that never moves money. 4. Authorize every action by group membership, use unguessable invite links, and record edits and deletions in the activity log instead of erasing history. DATA MODEL AND LIFECYCLE Design a small relational schema centered on Group, Member, Expense, ExpenseShare, Settlement. Before implementing it, document: 1. Each table’s purpose, primary key, ownership or tenant boundary, timestamps, status fields, and important attributes. 2. Foreign keys, uniqueness constraints, check constraints, indexes needed by the named screens, and transaction boundaries for multi-record changes. 3. The allowed lifecycle or state transitions, who may trigger each transition, which transitions are terminal or reversible, and what audit history must remain immutable. 4. Archive, retention, and deletion behavior, including what happens to dependent records and external files. 5. Idempotency strategy for submissions, jobs, imports, notifications, webhooks, or retries where applicable. Use migrations rather than ad-hoc schema creation. Store time instants consistently and retain named timezone context whenever local schedules or dates matter. Never rely on a counter, disabled button, or client-side check to preserve a business invariant. USERS, AUTHENTICATION, AND PERMISSIONS Implement only the roles required by the stated audience. Make the ownership and visibility model explicit before coding. Enforce authorization in every server-side query and mutation, including search, exports, attachments, live updates, and guessed URLs—not merely by hiding controls. Use secure session defaults, protect state-changing requests, and provide an understandable signed-out, expired-session, and forbidden state. Seed distinct users when multiple roles are required so permissions can be demonstrated and tested. INTERACTION AND VISUAL DIRECTION The product should feel fast, calm, focused, and credible rather than like a generic admin template. Use a clear visual hierarchy, restrained color, readable typography, generous hit targets, and consistent placement for primary actions. Start with server-rendered HTML and progressively enhance only the interactions that benefit from it. The core workflow must remain understandable if enhancement fails. Start with server-rendered Blade views and ordinary forms. Use Livewire for focused server-driven interactions and Alpine.js only for small local interface state. The core workflow must remain understandable without relying on a client-side application shell. Design mobile layouts intentionally instead of simply stacking desktop panels. Support keyboard navigation, visible focus, semantic landmarks, explicit labels, useful page titles, reduced-motion preferences, and screen-reader announcements for asynchronous results. Never use color alone to communicate state. Destructive actions require clear scope and confirmation; safe repeated actions should be idempotent. TECHNICAL DIRECTION Build this version with Laravel, PHP, Blade, Livewire, and Alpine.js. Use controllers and Blade forms for durable navigation, Livewire for focused interactions, Form Requests for validation, Policies and Gates for authorization, and small application actions or services for domain transitions. Use Eloquent with migrations, database constraints, and transactions; Laravel Storage for private S3-compatible files; queued Jobs for retryable work; the Scheduler for recurring work; and Notifications or Mail for email. Keep domain rules in testable server-side modules instead of route handlers or UI components. Separate persistence, external providers, and background work behind small interfaces without building a framework. Prefer ordinary HTML forms and URLs for durable navigation; use optimistic interaction only when failure can be reconciled clearly. The product brief currently identifies Astro, HTMX, D1 as capability context. Preserve any required native, browser-only, edge, storage, real-time, or background-processing capability through a narrow adapter appropriate to the selected framework. If the core workflow genuinely requires native or browser APIs, keep that runtime as the primary execution surface rather than simulating inaccessible capabilities or inventing an unnecessary web surface. Integrate with transactional email. For every integration: - List required environment variables in an .env.example without real secrets. - Add a small adapter with timeouts, normalized errors, and a deterministic local fake or development path. - Verify inbound signatures and deduplicate provider events where supported. - Keep credentials server-side, encrypt long-lived provider tokens at rest, and redact secrets and sensitive payloads from logs. - Define retry, backoff, and idempotency behavior for any side effect that can be repeated. SECURITY AND PRIVACY Store amounts as integer minor units, require splits to sum exactly to the expense total, and never move real money. Validate, normalize, and length-limit all untrusted input on the server. Escape rendered content by default, sanitize any intentionally accepted markup, rate-limit public or abuse-prone actions, and use private object storage plus short-lived authorized URLs for sensitive files. Collect the minimum personal data necessary for the named workflow. Document retention and deletion behavior. Add specific protections for the riskier surfaces in this app, such as uploads, redirects, outbound requests, email delivery, OAuth, webhooks, CSV import or export, and real-time connections. ACCEPTANCE SCENARIOS Automate these app-specific scenarios at the most appropriate level: 1. Given a 100.00 expense split three ways, the shares sum to exactly 10000 minor units with the extra cent assigned predictably. 2. Given settlements recorded to match the plan, every member’s balance reaches zero and the group shows all settled up. 3. Given a deleted expense, balances recompute, the activity log keeps the deletion visible, and no orphaned shares remain. TESTING Add focused unit tests for state transitions, authorization predicates, normalization, date or money calculations, and other risky domain rules. Add integration tests for persistence constraints and each external adapter’s success, timeout, retry, and rejection paths. Add at least one browser-level test for every end-to-end journey above, including one small-screen viewport. Tests must use isolated data and run through a documented single command. OPERATIONS AND FAILURE RECOVERY Add structured server logs with request, job, or event correlation IDs but no secrets or unnecessarily sensitive data. Make failures actionable in both the interface and logs. Background work must expose pending, succeeded, failed, and retrying states where relevant; do not silently swallow errors. Include safe database migration and rollback guidance, seed data, backup and restore notes, external-data cleanup behavior, and a basic health or diagnostic path appropriate to the stack. DELIVERABLES Ship the working application, migrations, representative seed data, tests, .env.example, and a concise README. The README must cover prerequisites, local setup, environment variables, migrations, seed and test commands, deployment, integration setup, backup and restore, security decisions, and known limitations. Seed data should exercise the happy path plus at least one empty, failed, overdue, expired, archived, or permission-restricted state relevant to the product. DEFINITION OF DONE The app is complete when a fresh developer can follow the README, create and migrate the database, run the app, sign in as each relevant role, complete every named journey using real persisted data, refresh without losing state, recover from common failures, and use the core interface on phone and desktop. All acceptance scenarios pass, permission boundaries are covered by tests, and no core screen is left as a placeholder. NON-GOALS Do not integrate payment providers, sync bank accounts, convert currencies, scan receipts, or build mobile apps.
You are building a production-ready software product named “Evensteven”, a deliberately focused alternative to Splitwise. Build a complete, usable vertical slice—not a landing page, static mockup, or disconnected collection of components. WORKING AGREEMENT Before writing implementation code, produce a short technical plan that names the routes or pages, server actions or endpoints, data tables, important state transitions, authorization boundaries, background jobs, and external adapters. Resolve contradictions in favor of the narrow audience and non-goals below. Prefer a small, legible architecture over speculative abstraction, but do not omit persistence, validation, error handling, or tests. PRODUCT BRIEF Primary user: housemates and trip groups splitting shared costs. Primary outcome: track who paid what and settle up with the fewest possible transfers. Product principle: optimize the exact workflow below instead of copying the full breadth of Splitwise. A first-time user should understand what to do from the interface itself, without a tour or documentation. END-TO-END USER JOURNEYS Implement all of these flows through the real interface and persistent data layer: 1. A member creates a group, invites housemates by link, adds a grocery expense split unevenly, and everyone sees updated balances. 2. A member opens the balances view, follows the simplified who-pays-whom plan, records a settle-up payment, and the debt disappears. 3. A member corrects a mis-entered expense amount, the activity log records the change, and all balances recompute from the ledger. SCREENS AND INFORMATION ARCHITECTURE Build these as coherent responsive views. Each screen must specify its primary action, secondary actions, visible status, validation feedback, empty state, loading or pending state, success confirmation, and recoverable failure state. 1. Group overview: member balances at a glance, who-pays-whom suggestions, recent expenses, and add-expense and settle-up actions. 2. Expense form: amount, payer, description, date, and equal, percentage, share, or exact-amount split modes with a live remainder check. 3. Balances: each member’s net position, the minimized settlement plan, and a record-payment action beside every suggested transfer. 4. Activity: an append-only feed of expenses added, edited, deleted, and settlements recorded, with who did what and when. CORE CAPABILITIES 1. groups with invite links and member balances 2. expenses with equal, percentage, share, and exact-amount splits 3. running balances derived from the expense ledger 4. debt simplification that minimizes who pays whom 5. settle-up recording with an append-only activity history DETAILED BEHAVIOR AND BUSINESS RULES Treat these as server-enforced product requirements, not interface suggestions: 1. Store every amount as integer minor units in one group currency; splits must sum exactly to the total, with remainder cents assigned deterministically. 2. Derive all balances from the ledger of expenses and settlements rather than storing mutable running totals. 3. Compute the settlement plan by minimizing the number of transfers between members, and present it as a suggestion that never moves money. 4. Authorize every action by group membership, use unguessable invite links, and record edits and deletions in the activity log instead of erasing history. DATA MODEL AND LIFECYCLE Design a small relational schema centered on Group, Member, Expense, ExpenseShare, Settlement. Before implementing it, document: 1. Each table’s purpose, primary key, ownership or tenant boundary, timestamps, status fields, and important attributes. 2. Foreign keys, uniqueness constraints, check constraints, indexes needed by the named screens, and transaction boundaries for multi-record changes. 3. The allowed lifecycle or state transitions, who may trigger each transition, which transitions are terminal or reversible, and what audit history must remain immutable. 4. Archive, retention, and deletion behavior, including what happens to dependent records and external files. 5. Idempotency strategy for submissions, jobs, imports, notifications, webhooks, or retries where applicable. Use migrations rather than ad-hoc schema creation. Store time instants consistently and retain named timezone context whenever local schedules or dates matter. Never rely on a counter, disabled button, or client-side check to preserve a business invariant. USERS, AUTHENTICATION, AND PERMISSIONS Implement only the roles required by the stated audience. Make the ownership and visibility model explicit before coding. Enforce authorization in every server-side query and mutation, including search, exports, attachments, live updates, and guessed URLs—not merely by hiding controls. Use secure session defaults, protect state-changing requests, and provide an understandable signed-out, expired-session, and forbidden state. Seed distinct users when multiple roles are required so permissions can be demonstrated and tested. INTERACTION AND VISUAL DIRECTION The product should feel fast, calm, focused, and credible rather than like a generic admin template. Use a clear visual hierarchy, restrained color, readable typography, generous hit targets, and consistent placement for primary actions. Start with server-rendered HTML and progressively enhance only the interactions that benefit from it. The core workflow must remain understandable if enhancement fails. Start with server-rendered Rails views and ordinary forms. Use Turbo for navigation, submissions, and server-driven updates, then Stimulus only for small browser-side behavior. Do not turn the product into a client-side SPA, and keep the core workflow usable when enhancement fails. Design mobile layouts intentionally instead of simply stacking desktop panels. Support keyboard navigation, visible focus, semantic landmarks, explicit labels, useful page titles, reduced-motion preferences, and screen-reader announcements for asynchronous results. Never use color alone to communicate state. Destructive actions require clear scope and confirmation; safe repeated actions should be idempotent. TECHNICAL DIRECTION Build this version with Ruby on Rails and Hotwire: Turbo for navigation, form submissions, and server-driven updates, and Stimulus for small browser-side behavior. Use RESTful controllers with strong parameters and explicit authorization, with domain transitions in testable models or small application services. Use Active Record migrations plus database-level constraints and transactions; Active Storage with an S3-compatible service for private files; Active Job with a durable queue backend for retryable work; Action Mailer for email; and Action Cable only when live updates are required. Keep domain rules in testable server-side modules instead of route handlers or UI components. Separate persistence, external providers, and background work behind small interfaces without building a framework. Prefer ordinary HTML forms and URLs for durable navigation; use optimistic interaction only when failure can be reconciled clearly. The product brief currently identifies Astro, HTMX, D1 as capability context. Preserve any required native, browser-only, edge, storage, real-time, or background-processing capability through a narrow adapter appropriate to the selected framework. If the core workflow genuinely requires native or browser APIs, keep that runtime as the primary execution surface rather than simulating inaccessible capabilities or inventing an unnecessary web surface. Integrate with transactional email. For every integration: - List required environment variables in an .env.example without real secrets. - Add a small adapter with timeouts, normalized errors, and a deterministic local fake or development path. - Verify inbound signatures and deduplicate provider events where supported. - Keep credentials server-side, encrypt long-lived provider tokens at rest, and redact secrets and sensitive payloads from logs. - Define retry, backoff, and idempotency behavior for any side effect that can be repeated. SECURITY AND PRIVACY Store amounts as integer minor units, require splits to sum exactly to the expense total, and never move real money. Validate, normalize, and length-limit all untrusted input on the server. Escape rendered content by default, sanitize any intentionally accepted markup, rate-limit public or abuse-prone actions, and use private object storage plus short-lived authorized URLs for sensitive files. Collect the minimum personal data necessary for the named workflow. Document retention and deletion behavior. Add specific protections for the riskier surfaces in this app, such as uploads, redirects, outbound requests, email delivery, OAuth, webhooks, CSV import or export, and real-time connections. ACCEPTANCE SCENARIOS Automate these app-specific scenarios at the most appropriate level: 1. Given a 100.00 expense split three ways, the shares sum to exactly 10000 minor units with the extra cent assigned predictably. 2. Given settlements recorded to match the plan, every member’s balance reaches zero and the group shows all settled up. 3. Given a deleted expense, balances recompute, the activity log keeps the deletion visible, and no orphaned shares remain. TESTING Add focused unit tests for state transitions, authorization predicates, normalization, date or money calculations, and other risky domain rules. Add integration tests for persistence constraints and each external adapter’s success, timeout, retry, and rejection paths. Add at least one browser-level test for every end-to-end journey above, including one small-screen viewport. Tests must use isolated data and run through a documented single command. OPERATIONS AND FAILURE RECOVERY Add structured server logs with request, job, or event correlation IDs but no secrets or unnecessarily sensitive data. Make failures actionable in both the interface and logs. Background work must expose pending, succeeded, failed, and retrying states where relevant; do not silently swallow errors. Include safe database migration and rollback guidance, seed data, backup and restore notes, external-data cleanup behavior, and a basic health or diagnostic path appropriate to the stack. DELIVERABLES Ship the working application, migrations, representative seed data, tests, .env.example, and a concise README. The README must cover prerequisites, local setup, environment variables, migrations, seed and test commands, deployment, integration setup, backup and restore, security decisions, and known limitations. Seed data should exercise the happy path plus at least one empty, failed, overdue, expired, archived, or permission-restricted state relevant to the product. DEFINITION OF DONE The app is complete when a fresh developer can follow the README, create and migrate the database, run the app, sign in as each relevant role, complete every named journey using real persisted data, refresh without losing state, recover from common failures, and use the core interface on phone and desktop. All acceptance scenarios pass, permission boundaries are covered by tests, and no core screen is left as a placeholder. NON-GOALS Do not integrate payment providers, sync bank accounts, convert currencies, scan receipts, or build mobile apps.
Build just one piece
Not ready to replace all of Splitwise? Fine. These are the peculiar sub-problems hiding inside it — the parts that are actually interesting to build. Each one is a standalone prompt, scoped to an evening, no strings attached to the full build.
The debt simplifier that turns 12 IOUs into 3Everyone owes everyone. Minimize the actual transfers.
Build a debt simplification algorithm for a shared-expense group. Input: each member's net balance in integer minor units, positive for creditors, negative for debtors, summing to zero. Output: a short list of transfers (who pays whom how much) that settles everyone. The greedy approach works well: repeatedly match the largest debtor with the largest creditor, transfer the smaller of the two magnitudes, and repeat until all balances hit zero. This guarantees at most n-1 transfers for n members with nonzero balances, and finding the true minimum is NP-hard, so don't chase it. Make it deterministic: tie-break equal balances by member id so the same ledger always yields the same plan, because a plan that reshuffles on every page load looks broken. Present the result as suggestions only; the app records settlements but never moves money. Done when: a tangled 5-person group settles in 4 transfers or fewer, every plan sums to zero per member, and identical inputs always produce the identical plan.
The split engine where every cent has a homeFour split modes, integer math, and a deterministic answer for the leftover penny.
Build the split calculator for a shared expense. Amounts are integer minor units, never floats. Support four modes: equal, percentage, shares, and exact amounts. The first three all hit the same wall: 10000 split three ways is 3333.33..., and rounding each share independently loses or invents cents. Compute floor shares first, then distribute the remainder one cent at a time by a deterministic rule, say, ascending member id, so the same expense always splits the same way and the shares always sum exactly to the total. For percentage mode, validate the percentages sum to 100 before computing. For exact mode, show a live remainder as the user types and block saving until it reaches zero. Reject zero-member splits and negative shares outright. Done when: a 100.00 three-way split yields shares of 3334, 3333, 3333 assigned predictably, every mode passes a property test that shares always sum to the total, and no float appears anywhere in the money path.
The balance that is always just the ledger, replayedNo running totals to corrupt. Edit an expense, everything recomputes.
Build ledger-derived balances for a shared-expense group. Store expenses and settlements as an append-only ledger and derive every member's balance by replaying it, rather than maintaining mutable running totals that drift out of sync the first time an edit goes wrong. When someone corrects a mis-entered amount or deletes an expense, don't mutate history silently: record the edit or deletion as an event with who did it and when, keep the original visible in the activity feed, and recompute balances from the surviving entries. Guard the invariants: the sum of all balances in a group is always exactly zero, deleting an expense leaves no orphaned shares, and the activity feed shows the full story, added, edited, deleted, settled, in order. If replay gets slow, cache a snapshot, but treat it as a disposable optimization you can rebuild from the ledger at any moment. Done when: editing an expense updates every affected balance, the deletion stays visible in the activity log, and balances sum to zero after any sequence of operations.
The settle-up that survives someone adding a pizza mid-paymentPlans go stale the moment a new expense lands. Handle it gracefully.
Build the settle-up flow for a shared-expense group. The balances view shows a suggested payment plan: pay Sam 4200, pay Ana 1750. A member records a real-world payment against a suggestion and the debt shrinks. The race: between rendering the plan and recording the payment, someone adds a new expense, and the suggestion no longer matches reality. Don't blindly apply it. Validate the recorded settlement against current balances; if the payer no longer owes that much, accept the actual amount paid as a plain settlement entry and regenerate the plan around it, with a note that things shifted. Support partial settlements, someone pays half of what they owe, and overpayment, which simply flips the direction of the remaining balance rather than erroring. Recording a settlement appends to the ledger like any expense, so history explains exactly how the group reached zero. Done when: recording all suggested payments zeroes every balance, a mid-settlement expense produces a corrected plan instead of a corrupt one, and partial payments leave accurate remainders.
Frequently asked questions
How long does it take to build your own Splitwise?
A basic version — groups, unequal splits, balances, simplified debts — takes about 8 hours. Roughly 2 days gets you a solid v1 with receipt uploads, recurring expenses, comments, email reminders. Matching everything Splitwise really does (mobile apps, payment integrations, currencies, receipt scanning) is closer to 1 month+, which is exactly why you should scope down instead.
How much does Splitwise cost if I keep subscribing?
Splitwise runs $3.33–$4.99 per month on public paid plans, which is $40–$60 per year. A focused self-built replacement costs your build time plus close-to-zero hosting.
What stack should I use to build a Splitwise alternative?
The build prompt on this page ships in four flavors: the AHA stack (Astro, HTMX, Alpine.js), Next.js, Laravel, and Ruby on Rails. The capability context for this product is Astro, HTMX, D1. Pick the stack you already know — the scope matters more than the framework.
What features does a minimal Splitwise replacement need?
A useful v1 needs: groups with invite links and member balances; expenses with equal, percentage, share, and exact-amount splits; running balances derived from the expense ledger; debt simplification that minimizes who pays whom; settle-up recording with an append-only activity history. Everything else is scope creep until you personally miss it.
What should I deliberately not build?
Do not integrate payment providers, sync bank accounts, convert currencies, scan receipts, or build mobile apps.
Does this build also replace Tricount and Settle Up?
Yes. Splitwise, Tricount and Settle Up all solve the same core job — track who paid what and settle up with the fewest possible transfers. The scoped v1 on this page covers what most people use any of them for, so one focused build replaces whichever you currently pay for.