Adriana Garcia walking the sales floor at Cande Bridal Boutique, gowns on the rail behind her
Platform overview

Every part of a bridal store, on one record

RingUps is one system for a bridal store: appointments, brides, gowns, special orders, checkout, payments, alterations, email, reporting and staff training, all on a single record per bride. This page maps every domain it covers, and links each one to its own page.

2,902
bride records migrated off Bridal Web Solutions
1,391 orders
totalling $2,275,597.72, reconciled before go-live
625 styles
catalogued, with 427 gown photographs rehosted
The RingUps dashboard: today's appointments, outstanding balances, bookings at risk and monthly revenue, with a morning brief flagging orders, fittings and brides that need attention

The dashboard at Cande Bridal Boutique, live and in daily use.

The three things that go wrong in a bridal store are all data problems

A gown arrives in a different dye lot from the sample the bride chose. A deposit is taken at the counter and nobody can say, six months later, whether it was ever applied. A bride is never called back after the appointment where she said maybe. None of these are staff failures. They happen because the appointment lives in one system, the order in a second, the deposit in a third, and the alterations on a whiteboard that gets wiped on Saturday.

The evidence for this is not rhetorical. When Cande Bridal Boutique in Kelowna, British Columbia moved off Bridal Web Solutions, three of that system's own exports gave three different answers for one order, number 872. Its Category Defaults screen reported 655 units in stock while its own inventory export reported 506. Reversals had been recorded with both a negative quantity and a negative price, so they read as positive charges: 93 lines across 59 orders, $141,807.75 wrong-signed, which made roughly 78% of an apparent $384,659.89 receivable an artefact of the data rather than money anyone owed.

RingUps is built the other way round. One record per bride, one ledger for money, one place where a deadline is calculated. The sections below map that record domain by domain, and each one says where it stops.

A stylist and a bride in an appointment at Cande Bridal Boutique, a gown held up against the light
An appointment at Cande Bridal Boutique. Every gown tried in this hour is written to the same record that later carries the order, the deposit and the alterations job.
The ten domains

What RingUps covers, one domain at a time

Ten domains, each with its own page: what it does, and the one behaviour that only makes sense in a bridal store.

01 · Brides and CRM

One record holds the bride and her whole party

Contact details, wedding date, every gown tried on, every order, payment, message and appointment sit on one customer record rather than in four systems that have to be cross-referenced by name.

Specific to bridal. A bridal sale is a group. Mothers and bridesmaids are linked to the bride they came in with, so a maid order and the gown sit on one timeline. 2,902 bride records came across in the Cande migration.

Client relationships →
02 · Appointments

Availability is calculated, and brides can book it themselves

A calendar for the floor, appointment types, rooms and consultants, plus a public booking page on the store's own domain. 3,820 historical appointments were migrated with the rest of the record.

Specific to bridal. A bridal appointment is not a haircut: it occupies a room, a consultant and two hours, and the party size changes what fits. A real end-to-end booking ran on the public page, returning 12 slots, and the confirmed row was verified in the database.

Appointments →
03 · Inventory and gowns

The sample on the floor and the style in the catalogue are different objects

Designer catalogues, styles, colours, size charts and photographs, with per-unit records for the samples physically hanging in the store. 625 styles, 500 floor units, 23 suppliers across 49 divisions.

Specific to bridal. A store sells a style it does not own from a sample it does. Each floor unit carries its own size, colour and condition so a sample can be sold off the rack without touching the style that is still special-ordered. 427 gown photographs were pulled off the previous vendor's servers and rehosted, so the catalogue survived the subscription.

Inventory and catalogue →
04 · Special orders

The must-arrive-by date is computed backward from the wedding

Purchase orders to designers, with a deadline engine that works back from the wedding date through the alterations window and the designer's lead time, rather than asking a consultant to guess a date.

Specific to bridal. The dye-lot guard is enforced at the write path, not on a screen. Placing a purchase order that would put a bridal party into mismatched dye lots is refused at the point of writing, with an explicit override checkbox for the case where the store decides to proceed anyway.

Special orders →
05 · Checkout and contracts

Checkout writes a promise, not a completed till transaction

Order lines, tax, deposits, balances and contracts generated from the store's own templates. 12 contract templates came across from Cande's previous system, captured by hand because there was nothing behind them to extract.

Specific to bridal. The gown does not exist yet when the sale is agreed. Checkout records a deposit and a balance due against a delivery that is months away, and the money is held as a liability until the bride takes the gown home.

Checkout and contracts →
06 · Payments and revenue

A deposit is a liability until the gown leaves the store

Payments, refunds and an append-only double-entry ledger, with revenue recognised at delivery rather than at the moment the card clears. 2,341 payments totalling $2,161,190.44 net of 43 refunds were migrated.

Specific to bridal. Most of a bridal store's cash on hand is money it has not earned yet. Treating deposits as deferred revenue is the difference between knowing what the store made in March and knowing what it collected in March.

Payments and revenue →
07 · Alterations

The workroom is one screen instead of four reports

A queue of alterations jobs with items, fittings, seamstress assignment and charges, attached to the same order as the gown it belongs to.

Specific to bridal. Bridal Web Solutions has no alterations workroom at all: the work is scattered across appointments, per-supplier charge records and four separate reports. That is a structural difference rather than a feature count.

Alterations workroom →
08 · Communications

A log that says why a message was not sent

Transactional and scheduled email from 12 customer templates, with a message outbox and a suppression log. The pipeline is live and proven in production: 100 delivered, most recently on 4 August 2026, with real provider message ids.

Specific to bridal. The suppression log carries a plain-English reason for every held message, which is what lets a manager answer the question every bridal store eventually gets asked: why did she never receive the review request. No other bridal system is documented as answering it.

Client communications →
09 · Reporting

28 report pages, and honest about which ones have data

28 standalone report pages plus a hub, and 30 export keys, all reading the same tables the floor writes to, so a report cannot disagree with the screen it came from.

Specific to bridal. Because deposits are held as a liability, the store can be asked what it has collected and what it has actually earned, and get two different answers on purpose.

Reporting and analytics →
10 · Team and training

Staff accounts, per-person permissions, and a training portal in the same product

Roles and per-person permission switches for the floor, and a training portal with courses and certificates built through 2 August 2026.

Specific to bridal. A bridal floor runs on part-time consultants who are trained on the job, and neither BridalLive nor Bridal Web Solutions has an equivalent training portal. Course first drafts can be generated, which requires an API key provisioned per store.

Four more areas exist, and here is exactly where each one stands

Cross-store marketplace →

Listings, eligibility, a five-tier condition scale and cross-store browsing are built. It is discovery and enquiry, with no transaction of any kind, and it is rolling out with a waitlist rather than operating as a populated network.

Drafting and automation →

Training course first drafts and gown attributes read from a photograph. Live, and it requires an API key provisioned per store.

Integrations →

What RingUps connects to, and what it deliberately leaves to your accountant and your processor.

Social and content studio →

In development. It is on the roadmap page, not in the product.

The whole map, in one table

Every domain, and its bridal-specific behaviour

The same ten domains as above, compressed. If you are comparing systems on a spreadsheet, this is the row set to copy.

RingUps domains: coverage and the behaviour specific to bridal retail.
Domain What it does Specific to bridal Page
Brides and CRM One customer record carrying contacts, wedding date, gowns tried, orders, payments and messages. The bride and her party are linked, so a maid order sits on the same timeline as the gown. Client relationships
Appointments Floor calendar, appointment types, rooms, consultants, and a public booking page. Availability is computed from rules at request time. A live public booking returned 12 slots and was verified in the database. Appointments
Inventory and gowns Catalogues, styles, colours, size charts, photographs and per-unit floor stock. 625 styles, 500 units. The floor sample and the orderable style are separate objects. 427 gown photographs were rehosted off the vendor's servers. Inventory and catalogue
Special orders Designer purchase orders with a must-arrive-by date computed backward from the wedding. The dye-lot guard is enforced at the write path and blocks placement, with an explicit override. Special orders
Checkout and contracts Order lines, tax, deposits, balances and contracts from the store's own templates. Checkout records a promise months ahead of delivery rather than closing a till transaction. Checkout and contracts
Payments and revenue Payments, refunds and an append-only double-entry ledger, recognised at delivery. Deposits are held as a liability, so collected and earned are two different numbers on purpose. Payments and revenue
Alterations One workroom screen: jobs, items, fittings, seamstress assignment and charges. Bridal Web Solutions has no workroom at all; the work sits across appointments, charge records and four reports. Alterations workroom
Communications Email from 12 customer templates, an outbox, and a suppression log. 100 delivered in production. Every held message carries a plain-English reason, so a manager can say why a bride never received one. Client communications
Reporting 28 report pages plus a hub, 30 export keys, reading the tables the floor writes. Collected and recognised revenue are reported separately because the ledger keeps them apart. Reporting and analytics
Team and training Staff accounts, roles, per-person permission switches, and a training portal with courses and certificates. Built for part-time consultants trained on the floor. Neither named competitor has an equivalent portal. Team and permissions, Training
Architecture

Four decisions that were made in the database, not in the interface

Most retail software checks a rule on the screen and hopes the screen was the only way in. RingUps puts the rules where the rows are written. This is the part of the product an evaluator can verify, and the part that decides whether the numbers still agree in three years.

01

Capacity is enforced in the database, not re-checked in the app

Whether a slot can take another appointment is decided as part of writing the row, not by a lookup the screen performs first and then trusts. Two people confirming the same slot in the same second do not both succeed, and neither does an import, an admin edit, or the public booking page, because none of them can route around the constraint.

Why it matters: the classic double-booking bug is not a bug in the calendar, it is a rule that lived in one screen and not in the others.

02

Deposits are an append-only double-entry ledger, not a balance field

A payment writes entries. Nothing is edited in place. A refund is a new pair of entries rather than an adjustment to an old one, so the history of what a bride paid cannot be quietly rewritten. Deposits sit as a liability and the revenue is recognised at delivery.

03

Availability is computed from rules, not stored as pre-generated slots

There is no table of empty appointment slots waiting to be claimed. Opening hours, appointment type, staff, rooms and existing bookings are resolved into an answer at the moment somebody asks. Change your Saturday hours and next February is already correct, because next February was never written down.

04

Multi-tenant isolation is enforced at the database

Every row carries an organisation id, and which rows a session may read is decided by the database rather than by a filter a developer has to remember to write into every query. The internal console we run RingUps from is deliberately outside your data: it is a trust proof that we cannot read your brides, not a feature you receive.

One more that belongs here: every imported row is idempotent on organisation, source and source reference, and reversible by batch id. That is why the safe wording for migration is that imports are reversible in one click, rather than that the data came across clean.

One sale, end to end

How one gown moves through all ten domains

Six steps for one bride. At each one, what the staff member does and what the system does in response. The panels are illustrations of real screens with an invented bride, not screenshots of a live store.

app.ringups.com/book/cande
Public booking page — this week
Thu
10:00 Bridal
14:00 Bridal
Fri
11:00 Bridal
15:30 Party
Sat
09:30 Bridal
12:00 Bridal
Sun
Closed
Slots returned in the live end-to-end test
12
booking confirmed, row verified
Confirmation
Email
sent the moment she books

She does: picks a time on the store's own booking page. RingUps does: computes availability from opening hours, appointment type, staff and rooms at that moment, writes the appointment against the capacity constraint, and creates her customer record before she walks in.

A seamstress sewing a wedding gown in the alterations workroom at Cande Bridal Boutique
The alterations workroom at Cande Bridal Boutique, where every fitting is queued against the same order as the gown.

The proof is a migration nobody had to take on trust

One store has moved onto RingUps in full. Every figure below was verified against the production database on 4 August 2026, and the store has been trading since, so the live totals are now higher. These are migration figures, not current ones.

2,902
brides
3,820
appointments
1,391
orders, $2,275,597.72
2,341
payments, $2,161,190.44 net of 43 refunds
624 of 625
products matched; the miss was a bookkeeping row
228
orders skipped rather than invent a bride

What the reconciliation actually found

Their exports disagreed with each other
On order 872, Bridal Web Solutions gave three different answers: one in its sales-tax export, one in its payments export, one in its own line data.
Their screens disagreed with their exports
Category Defaults reported 655 units in stock. The inventory export from the same system reported 506.
Reversals were recorded so they read as charges
93 lines across 59 orders carried both a negative quantity and a negative price, $141,807.75 wrong-signed, making roughly 78% of an apparent $384,659.89 receivable an artefact.
Tax had to be rebuilt, then corrected
The sales export carried no tax at all, so it was reconstructed on 1,391 orders and then corrected against a second report on 36 exception invoices, catching a $3,253.05 overstatement.

The honest part: the import was not pristine. All 1,391 orders arrived with zero tax and were backfilled, 32 were then corrected against Bridal Web Solutions' own report, and every imported order landed with the status picked up. That is a migration-competence story, not a claim that the data came across clean.

Ask an owner to reconcile their current system against itself.

Read the Cande Bridal Boutique migration in full →

What comes off the wall when RingUps goes in

Most bridal stores do not run one system. They run a system plus the things they built around it because the system could not hold them.

  • The paper appointment book, and the second copy someone keeps on their phone.
  • The spreadsheet of special-order deadlines, with its column of dates typed in by hand.
  • The deposit tracker that only balances if nobody was off sick.
  • The alterations whiteboard, and the four separate reports a previous system needed to stand in for a workroom.
  • The separate email tool that never knew which bride had already picked up.
  • The owner who keeps the rest of it in her head, and cannot take a week off.

What it does not replace, and should not

RingUps is not your accounting package. It is not your card processor, and stores keep the processor they already have. It is not a website builder, and it does not replace the designers' own ordering portals, because purchase orders print rather than transmit.

Bridal Web Solutions, for the record, is not a thin product: roughly 85 reports, 156 pages and 11 subsystems, dating to 2006. Depth you will never finish configuring is a different thing from capability. Its own screens flag 14 of Cande's 22 primary suppliers as never fully set up and 82 categories hidden.

Questions

Four things owners ask before they look at anything else

What does RingUps replace?

RingUps replaces a bridal point of sale and the things a store keeps beside it: the appointment book, the special-order deadline spreadsheet, the deposit tracker, the alterations whiteboard and the separate email tool. At Cande Bridal Boutique in Kelowna, British Columbia it replaced Bridal Web Solutions, and the migration carried 2,902 brides, 3,820 appointments, 1,391 orders and 2,341 payments across. It does not replace your accounting software or your card processor.

Is RingUps a point of sale or a CRM?

Both, and holding them apart is the problem it was built to fix. Every appointment, gown tried on, contract, payment, purchase order and alterations job hangs off one bride record, so the sale and the relationship are the same object. It is not a general-purpose retail point of sale: it assumes a sale agreed months before the gown exists and paid for in stages.

Does RingUps work for a single-location store?

Yes. One independent store is the design centre, and the single boutique running RingUps in production today is one location. Every row in the database carries an organisation id and that isolation is enforced by the database rather than by application code, so adding a second location is a data question rather than a rebuild. Nothing in the product assumes a chain.

How long does setup take?

There is no published number, because the time goes on reconciling the export rather than loading it. For Cande Bridal Boutique the sales export carried no tax at all, so tax was rebuilt on 1,391 orders and then corrected on 36 exception invoices, and 228 orders were held back rather than attach them to a bride we could not identify. Imports are reversible in one click and every row is idempotent on organisation, source and source reference, so a bad load is undone rather than cleaned up by hand.

More of these, across every domain, on the frequently asked questions page.

See all ten domains running on your own gowns

Book a fifteen-minute demo on your own data. We import a slice of your real export first, so you are looking at your brides and your deadlines rather than a demo store.