Wed.money

• 

wed.money is a web-based financial planning tool for weddings and similar

one-off celebrations. Unlike general-purpose wedding planning software, it is deliberately narrow in scope: it does not manage guest lists, seating charts, tasks, or vendor communication. It exists to answer a single question — how much do I owe, to whom, and when? The application is available at wed.money.

The tool treats a wedding as a cash-flow problem rather than a project-management problem. Its core model is a three-level hierarchy of budget (what an item is expected to cost), payment plan (the schedule of deposits and instalments agreed with a vendor), and payments (what has actually been paid, when, and from which source). Every view in the application is a different projection of that hierarchy.

Key features

• Worksheet — a spreadsheet-style entry grid that serves as the main working surface. One grid per event, with vendor rows and payment cells edited in place, without dialogs interrupting data entry.
• Budget tracking — budget envelopes per vendor and event, with expandable rows revealing the underlying payment schedule.
• Payment plans — scheduled instalments with dates, amounts, descriptions, and optional funding source. Zero-amount lines act as milestones (contract signing, final headcount date) that appear on the timeline without contributing money.
• Payment recording — actual payments logged against a planned instalment or entered standalone for unbudgeted spending.
• Variance — planned versus actual is shown wherever both exist, colour-coded, and is always computed rather than stored.
• Timeline chart — a stacked bar chart of committed spending over time, with a date-range slider and a toggle to overlay actual payments against the plan.
• Calendar view — payment due dates rendered as a month calendar.
• Dashboard — a summary view with a vendor breakdown donut (paid versus remaining per vendor) and a "due soon" list of upcoming obligations.
• Payment sources — optional labelling of where money comes from (a joint account, a parental contribution, savings), so contributions can be tracked separately from vendors.
• Multi-user collaboration — several people can share one celebration with distinct roles: Owner, Admin, Editor, and Viewer. Viewers have genuine read-only access, enforced at the API level and not merely hidden in the interface.
• Multilingual interface — the UI is translated into several languages, with per-account and per-celebration language and number/date formatting preferences.

How it works

The unit of tenancy is the celebration, not the user account. An account is a person; a celebration is the thing being planned; a membership record links the two with a role. All data belongs to a celebration, and every read is scoped to the currently selected one. A single account can own or be invited to several celebrations and switch between them.

Derived financial figures — totals budgeted, totals planned, totals paid, and variance — are never stored. They are computed at read time from the underlying records, so the numbers cannot drift out of sync with the payments they summarise.

The application distinguishes two kinds of time. Calendar dates (a payment due date, the event date, a contract date) are floating: they are stored and displayed exactly as entered and are never shifted by a time zone. Machine timestamps (account creation, logins) are stored in UTC and rendered in the viewer's local time zone. "Due soon" calculations use the viewer's own notion of today rather than the server's, so a payment due tomorrow does not appear due today for a user in a different time zone.

New accounts are not dropped into an empty screen. A starter worksheet is drawn in advance with placeholder structure, and nothing is written to the database until the user commits their first real entry. Celebrations can also be created from a template, or template contents imported into an existing empty celebration.

Editing happens in place. Adding or changing a budget item, editing its whole payment schedule, or recording a payment all occur through shared modals that open on whichever page the user is currently on — the application does not navigate away from a view to perform a create or edit.

Technically, wed.money is a server-rendered PHP application with a browser-native front end. It deliberately uses no front-end framework or build step; the only third-party JavaScript is a small set of charting and calendar libraries loaded from a CDN. All interface text is served from a translation database rather than hardcoded, and all data access flows through a scoped API rather than direct queries from the page.

Problem it addresses

Wedding costs are not a single number; they are a sequence of obligations spread over many months and owed to a dozen or more separate parties, each with its own deposit schedule and final-balance date. The common failure mode is not overspending in the abstract but a liquidity surprise — three vendors happening to require final payment in the same fortnight, or a deposit forgotten until it is overdue.

General wedding planning apps typically model money as a flat category list with a single "spent so far" figure, which cannot express when money is actually required. Spreadsheets can express it, but they degrade quickly once several people edit them and offer no view of what is due next week. wed.money targets that gap specifically: it keeps the commitment, the schedule, and the actual payment as three distinct records, and renders the result as a timeline of obligations rather than a running total.

Limitations

The following are explicit non-goals rather than pending features:

• No vendor portal — vendors do not have accounts and cannot log in.
• No file or document storage, and no contract attachments.
• No multi-currency support; a celebration uses one currency.
• No recurring-payment automation.
• No guest management, seating, RSVPs, or messaging.
• No marketing email, digests, or payment reminders — outbound mail is limited to invitations and password resets.

External links

• wed.money — official website