RingUps keeps a multi-shop group inside a single organisation instead of a separate account per shop. Every tenant table carries an organisation id and row-level security enforces it, so another store's data cannot appear in your queries. Nine operational tables, including the appointment book, floor inventory and orders, record which location the row belongs to.
Software vendors run these two words together, because one of them is much easier to build than the other. RingUps is genuinely multi-tenant, and that is provable. Multi-location is the second question, and it deserves its own answer rather than a borrowed one.
This is about strangers. A boutique in one province and a boutique in another both run on RingUps, and neither can see a single row belonging to the other. It is an architectural property, it is enforced by the database, and it is the same for every store on the platform whether it has one shop or six.
RingUps is this, and can show you why.
This is about you. It is a product question, not an isolation question: which screens carry a location filter, which numbers add up across shops, whether a manager can be held to one store. Strong tenant isolation is a precondition for it and is not the same as having it.
Structurally present. Walk through the specific screens with us.
A vendor answering "yes, we are multi-location" to a question about data separation, or answering "your data is isolated" to a question about a group report, has swapped one for the other. Ask both questions separately and write down both answers.
Ask us the same way. We would rather lose a deal than win it on a word.
Every tenant table in RingUps carries an organisation id, and which rows a session is allowed to read is decided by the database as part of answering the query. It is not a filter a developer has to remember to write into every screen, every export and every background job.
That distinction is the whole point. Application-level separation fails the day somebody writes one query without the filter, and the failure is silent: a report quietly containing somebody else's brides looks exactly like a report. Database-level separation cannot fail that way, because the careless query returns nothing rather than returning the wrong store.
The console RingUps runs the platform from sits outside that boundary and cannot read your brides. That is a trust proof about us, not a feature you receive, and it is worth saying in exactly those words.
| Record | Carries a location | What that means for a group |
|---|---|---|
| Appointments | Yes | An appointment belongs to a shop. So do rooms, working hours, availability blocks, slot rules and the waitlist, which is what makes two diaries possible rather than one shared calendar. |
| Floor inventory units | Yes | Each physical unit on the floor is stamped with the shop it is standing in. 502 units are recorded in production today, all at one location. |
| Orders | Yes | The sale records where it was written, which is the column any per-shop revenue answer has to be built on. |
| Wedding parties | Yes | A bridal party is attached to the shop looking after it. |
| Bride records | Organisation | One bride, held once for the group. She is not duplicated per shop, and nothing stops a consultant at one shop opening her record. |
| Gown catalogue | Organisation | Styles, designers and size charts are held once. A style added for the group is a style every shop can sell. |
| Payments and deposits | Organisation | The deposit ledger is one ledger for the business. Payments are tied to the order, and the order carries the location. |
| Designer purchase orders | Organisation | A purchase order belongs to the business rather than to a shop. If you buy per shop, raise it with us before you sign. |
| Staff, roles, permissions | Organisation | This is the honest one. A permission is granted across the organisation, not scoped to one shop. There is no per-location permission today. |
Most bridal software sells a second location as a second account. Each one is complete and neither knows the other exists, so the third job is the owner, on a Sunday, making the two agree.
She books at the shop near her work and buys at the shop near her mother. In two accounts she is two records, with the appointment history in one and the deposit in the other, and whichever consultant opens the wrong one is the one who calls her about a gown she already bought.
The same designer is set up separately at each shop, so the style codes stop matching, the prices go out of step, and by the second season no report can add the two together without somebody mapping them by hand.
Two systems produce two spreadsheets and the owner produces the third. At Cande Bridal Boutique we found a single system whose own exports disagreed with each other on one order. Two systems do not halve that problem.
Per-location charges are the ones nobody models before signing. The table further down this page multiplies out the one we have on record, because a group pays it once per shop and the arithmetic is the argument.
The location is not a label on a dashboard. It is a column on the row, written when the appointment is booked, when the unit is received onto the floor, and when the order is created. Anything you later want to ask per shop has to be answerable from that column, which is why it is worth checking that it exists before you check whether a chart is pretty.
The isolation and the location column are both in production now. What no page can honestly show you is a group in daily use, because there is not one yet.
How the rest of the platform is built →The good half first. Logins are personal and unlimited on every plan, so nobody shares a counter password across two shops, a departure is one revocation rather than a password change at both, and the audit trail carries a name. Who can see reports and who can see payments are separate switches per person, alongside four more for the training portal.
The honest half. Staff records, roles and permissions carry an organisation id and no location id. A permission therefore applies across the group rather than to one shop, so a manager you give report access to has report access for the business. If holding a manager to one location is a requirement for you, say so early: it is a change to the permission model, not a checkbox somebody forgot to tick.
Staff invites are also not emailed. The manager generates a link and forwards it, which matters more when the person is starting at your other shop on Saturday.
Every role and what it can see →
RingUps ships 28 standalone report pages plus a hub, and 30 export keys, on every plan. Orders carry the location they were written at, which is the column a per-shop revenue answer has to be built from. Which reports present that column, and whether a particular comparison between your shops comes out of the box, is a question to answer in front of your own data rather than to assert here.
We would rather show you the screen than describe it. Bring a question you ask every Monday and we will answer it live or tell you it needs building.
With 30 export keys behind them. Every account gets all of them at the one flat rate; there is no tier to unlock.
And 8 of 3,851 imported appointments name a stylist. Sales-by-employee and closing rate are real reports running on near-empty history, so comparing consultants across shops starts the day you go live, not before it.
Nothing arrives in your inbox on Monday morning. You open RingUps and pull it. For an owner covering several shops that is a real inconvenience and we are not going to dress it up.
Our review of BridalLive recorded a charge of $295 per month, per location, applied where a store does not move to that vendor's payment processing. A single boutique reads that as an annoyance. A three-shop group pays it three times, and the number stops being an annoyance somewhere around the second shop.
RingUps takes no percentage of your sales and makes no charge for keeping the processor you already use. Read the table, then go and read your own agreement for the same clause before you compare anything else.
| Shops in the group | BridalLive, per month | BridalLive, per year | RingUps equivalent charge |
|---|---|---|---|
| 1 shop | $295 | $3,540 | None |
| 2 shops | $590 | $7,080 | None |
| 3 shops | $885 | $10,620 | None |
| 4 shops | $1,180 | $14,160 | None |
| 5 shops | $1,475 | $17,700 | None |
Two things this table does not say. It is not a total cost of ownership comparison, because it is one line from one vendor's pricing and your invoice has other lines on it. And a charge you avoid is not the same as a capability you gain: in-app card processing is wired for Cande today and rolls out to new stores as Stripe Connect comes online, so a new shop keeps its existing terminal in the meantime and RingUps records the payment.
RingUps is one flat rate, $99 a month, CAD or USD depending on where the store sells, with every feature included and no tier to climb. There is no self-serve way to add a second location yet, so each shop in a group, including the first, is priced individually: ask, and we bring your next location online with you personally. Full pricing and the BridalLive comparison are both published.
Every role, what it can see, and the six capability switches that sit beside it. Read it with the organisation-wide scope on this page in mind.
The 28 report pages, the 30 export keys, and the parts of the imported history that cannot be reported on. Worth reading before you plan a group scorecard.
A group moves one shop at a time. This is what a migration actually involves, including the 228 orders we refused to guess at rather than fabricate a bride.
One RingUps organisation can hold more than one location, and a person's login is granted against the organisation rather than against a single shop. Nine operational tables stamp the location on the row, including appointments, rooms, working hours, floor inventory units, orders and wedding parties. Whether a particular cross-location report or rollup exists is a question to put to us on a demo, not something to take on trust from a web page.
Yes, and it is separated by the database rather than by application code remembering to add a filter. Every tenant table carries an organisation id and row-level security decides which rows a session may read, so one store's brides cannot appear in another store's queries even if a query is written carelessly. The RingUps-internal platform console is deliberately outside that boundary and cannot read your brides, which is a trust proof rather than a feature you receive.
$885 a month, which is $10,620 a year. BridalLive applies $295 per month per location where a store does not move to its own payment processing, so a three-shop group pays it three times. RingUps charges no percentage of your sales and has no equivalent charge for keeping the processor you already use.
Tell us how many shops, on what systems, in what order. We will answer the cross-location questions on the screen, in front of your own data, and tell you plainly which ones need building.