At some point someone on the organizer team says it: “Next year we’ll do this digitally.” Everyone is relieved. Then somebody opens a browser, finds five providers, and all five websites claim roughly the same thing – simple, fast, saves time. How you’re supposed to tell them apart isn’t written on any of them.
Let’s start with the obvious: we build one of those solutions ourselves. So this isn’t a neutral product review, and it isn’t trying to be. What follows is the list of questions we’d put to any organizer team that’s currently comparing options – and next to each one, how MukiBasar handles it, so you can check us against it. If another provider answers the questions better, take them. A bazaar is far too much work to let software be the thing that ruins it.
One point matters to us more than any feature, and it almost never appears in a sales pitch: the data processing agreement. There’s a chapter on that below.
First, three questions for yourselves
Before you compare feature lists, settle this internally:
How do you sell? A pre-sorted numbered bazaar where you handle the entire sale, or a classic table market where people stand behind their own table? Most systems are built for exactly one of those. Pick the wrong one and you’ll fight the software all weekend.
How big are you really? Not by feel, but counted: how many sellers, how many articles per bazaar. That decides whether a per-article price or an annual flat rate works out cheaper – the difference can be a factor of three.
How often per year? One date, two dates, maybe a summer fête with a sales stand? That determines whether a subscription pays off or whether you’d rather only pay when you actually sell.
With those three answers, the following list becomes useful.
1. Does the till keep working when the Wi-Fi drops?
This is the most important question on the list, and it’s the one asked least often.
Sports halls are dead zones. Thick walls, no reception, a guest network built for two devices rather than twelve. If your till needs a stable connection, your sale stops dead at precisely the moment three hundred people are queuing.
Ask every provider: Does the till work without internet? What happens to a sale made offline – is it lost, does it have to be entered afterwards, or does it transfer by itself later? And how does the till show you whether it’s currently online or offline?
Red flag: “You’ll need a stable internet connection.” That isn’t a requirement, that’s a risk you’re being handed.
How MukiBasar handles it: The till keeps working offline. On first opening it downloads all of the bazaar’s articles onto the device once – that part needs internet, which is why you don’t set tills up five minutes before the rush. After that, sales are stored locally and transferred automatically as soon as there’s a connection again. The till permanently shows Online or Offline along with how many receipts are still waiting to transfer. Nobody has to enter anything twice.
2. Do you have to re-label the goods?
This is where most volunteer hours hide, and you can’t tell from an offer.
Some systems require you to re-tag incoming goods with your own labels at drop-off. With four hundred items that’s an entire evening spent by several people – and every handwritten tag is a potential error in the settlement.
Ask: Who produces the price tags – the sellers at home, or you in the hall? What happens if someone changes a price after printing? How does the till detect that a label is out of date?
Red flag: Anything that sounds like “articles are recorded at drop-off”. That means: you’re the ones typing.
How MukiBasar handles it: Sellers create their own articles and print the labels at home – 16 to an A4 sheet on an ordinary printer, or one at a time on a label printer. Every label carries a QR code that the till scans; price and seller number are attached to it. If someone changes the price after printing, the till reports “Label €… , currently €… – please reprint” instead of quietly booking the wrong amount. Nothing gets re-labelled.
3. How do registrations come in – and get decided?
Before the bazaar, managing registrations is your main job, and it’s a slog when it runs on email and a spreadsheet.
Ask: Can sellers register themselves? Can you decide several registrations at once, or do you click two hundred times? Can you set caps – overall and per category? Can you exclude particular kinds of articles you don’t want in the hall?
Red flag: No quantity limits. Then on drop-off day there’s more stock in the hall than there is space, and you’re turning people away in person.
How MukiBasar handles it: Registrations come as a list with search, filters and sorting; you decide them individually or as a bulk decision. When you create a bazaar, a wizard walks through eight steps, five of them optional – including fees, discounts, per-category quantity limits and prohibited articles. Sellers see their own counter live (“12 of 50 articles”), and articles in blocked categories can’t be assigned in the first place.
4. What happens on drop-off day?
Drop-off day is the moment when software either helps or gets in the way. It’s loud, it’s crowded, and there are people at the counter holding boxes.
Ask: How do you identify a person at the counter – search for a name, read out a number, or scan? Do you see in real time who has already handed in and who is still missing? And – the underrated one – how do you correct a mistake? Sooner or later somebody confirms the wrong person.
Red flag: No way back. If a drop-off can’t be undone, you’ll be fixing it by hand in the settlement later.
How MukiBasar handles it: Sellers bring a box label carrying their seller number and a QR code, which the counter simply scans – faster than reading a number out over the noise. Alternatively you type the number in. You can see continuously how many of the approved sellers have already handed in, and a confirmed drop-off can be reversed if it was wrong. Once a box is accepted the articles are locked, so no price can move afterwards.
5. How fast are you finished on Sunday evening?
The hall is swept, everyone is tired, and now comes the part that decides the mood in the team: the payout.
Ask: What exactly do you get printed? Is there a receipt per seller, an overview for the settlement table, labels for the payout envelopes? And does the commission you keep actually fit your model?
Red flag: “You can export the data as CSV.” That means: you’re building the settlement yourself in a spreadsheet.
How MukiBasar handles it: The reports are grouped into settlement, labels and lists. There’s the full settlement with one receipt per seller (articles sold, fee, revenue, payout), a payout overview as a table for the settlement desk, envelope labels carrying revenue and payout – eight to an A4 sheet, ready to stick on – plus a blank variant carrying your processing fee and an empty amount line, and a simple seller list with two tick-box columns for everything you count by hand.
6. Can several people work at the same time?
A bazaar is teamwork, but plenty of systems are built around a single login – and then one person sits at the computer while everyone else waits.
Ask: How many tills can run in parallel? Can several people work the drop-off desk at once? Are there roles, or does everyone get full access to everything? And what happens if the person holding the login falls ill?
Red flag: One account and one password passed around the team. Convenient, right up until it becomes a data protection problem.
How MukiBasar handles it: Your organization has members with roles – admin (create and publish bazaars, manage the organization) and member (part of the team, without admin rights). Members are added by invitation and can be removed again. Several tills run in parallel, and the cockpit shows the whole team the current state of the bazaar along its four phases.
7. How do you reach your sellers?
The same questions arrive before every bazaar: when is drop-off? How many articles am I allowed? Where do I park? If that runs through a private mobile number, exactly one phone rings – yours.
Ask: Is there a communication channel inside the software, or does the provider point you at email? Can several team members answer? Do replies to automatic emails reach you – or a “noreply” void?
Red flag: Automatic mails with no working reply address. People reply anyway, and nobody reads it.
How MukiBasar handles it: There are direct conversations – just that person and your organizer team, so nothing hangs off a private number – and an event room for all participants of a bazaar, which you can moderate. You can start the first contact straight from the registration. For the automatic bazaar emails you enter a contact email address for your organization; it’s used as the reply address, so answers land with you rather than with us.
8. What does it actually cost?
The price on the homepage is rarely the price at the end of the year.
Ask: Is there a setup fee? Does every event cost extra? Is billing per seller, per created article or per sold article – the difference is substantial. Is there a minimum? What happens if a bazaar is cancelled? And does a subscription renew automatically?
Red flag: “Price on request” for a product aimed at volunteer associations.
How MukiBasar handles it: Two models, both public. Flexi bills €0.06 per sold article – no base fee, you only pay when you actually sell. Komfort costs €199 per year and includes unlimited articles and events. Both prices include VAT, payment runs through Stripe. All the numbers are on the pricing page, not in a quote you have to request.
9. Does anyone have to install something?
On bazaar day you’re helped by people who have never seen the software before – and they bring their own phones.
Ask: Does it run on an ordinary smartphone in a browser? Does it need an app store download, a particular operating system, special scanner hardware? And how does someone get in who steps in at the till at short notice?
Red flag: An installation that has to happen on every helper’s device. That costs you the first half hour of setup day.
How MukiBasar handles it: MukiBasar runs directly in the browser. If you want, install it as a PWA on iPhone, Android or a computer – no app store, with automatic updates. Scanning uses the phone camera; no special hardware needed.
10. Will anyone find you?
Software can take work off your hands. It only brings you sellers if your event is visible in the first place.
Ask: Does your bazaar appear anywhere publicly, or is the software purely an internal tool? Is there an info page you can link to – with dates, directions and your terms of participation?
How MukiBasar handles it: Published bazaars appear in the public bazaar overview with a map, dates and the registration period. Each event comes with an info page you can link in a parents’ letter or a WhatsApp group.
11. What happens to the data after the bazaar?
Almost nobody asks this one, and it leads straight into the next chapter.
Ask: How long is seller and settlement data stored? Can you get at your own data if you switch providers? And what happens to it if you cancel – is it deleted, and do you get that confirmed?
Red flag: No statement at all. Because deletion at the end of a contract isn’t a service, it’s a contractual obligation.
The chapter most people skip: data processing
Now the part that never comes up in a sales conversation and concerns you as an association regardless.
If you have the names, addresses and contact details of your sellers processed in someone else’s software, you remain the controller under the GDPR. The provider processes that data on your behalf – they are the processor. And for exactly this constellation, Art. 28 GDPR requires a data processing agreement, in German a Auftragsverarbeitungsvertrag or AVV. This isn’t an optional extra for large organizations. It applies to the parents’ council running one bazaar a year too.
What a DPA has to contain
A usable agreement covers at least:
- the subject matter, duration, nature and purpose of the processing
- the categories of data and the groups of people affected
- the provider’s obligation to act only on your instructions
- confidentiality of the people involved
- technical and organizational measures (TOMs) – how the data is actually protected
- the handling of sub-processors: who are they, how are you told about changes, can you object?
- support with data subject rights and data breaches
- deletion or return of the data at the end of the contract
- your inspection and audit rights
On top of that comes the question of where processing happens: is the data in the EU? And if providers outside the EU are involved – on what basis, for instance EU standard contractual clauses?
Red flags when choosing a provider
- No DPA on offer – or only once you ask for it
- No list of sub-processors. Every piece of software uses some; anyone who names none either has no overview or isn’t saying
- Unclear server location, or described as “in the cloud”
- No statement on deletion after the contract ends
- The DPA exists only as a PDF you’re meant to sign and send back – and afterwards nobody knows which version actually applies
How MukiBasar handles it: You conclude the DPA directly in the app – read the text, tick the box, conclude the agreement. It is versioned: if the text is revised, the app asks again, because a confirmation always applies to one specific version. The full text is publicly readable at any time, with §§ 1 to 12 – from rights of instruction through inspection powers and sub-processors to deletion and return – plus Annex 1 covering services, categories of data, groups of people affected and purpose, and the TOM annex on purpose limitation, confidentiality and integrity, availability and recoverability.
The sub-processors are named: Supabase, Inc., Amazon Web Services EMEA SARL and Functional Software, Inc. (Sentry). Hosting is in the AWS region eu-central-1 in Frankfurt am Main, so inside the EU; third-country elements are covered by EU standard contractual clauses and certification under the EU-US Data Privacy Framework respectively. For your sellers there’s a separate privacy notice you can link to.
This is not legal advice. When in doubt ask your data protection officer, your umbrella organization or your legal adviser – but ask before the decision, not after it.
The questions to copy
If you take one thing from this text: send this list to every provider on your shortlist. The answers – and how long they take – will tell you more than any product page.
- Does the till work without an internet connection? What happens to sales made offline?
- Who creates the price labels – the sellers, or us at drop-off?
- Can we decide registrations in bulk and set per-category quantity limits?
- How do we identify sellers at the drop-off desk – and how do we undo a wrong one?
- Which documents do we get printed ready for the payout?
- How many tills and user accounts are possible, and what roles exist?
- Can participants reply to your automatic emails, and where do the replies go?
- How exactly is billing calculated – per seller, per created article or per sold article? Are there setup fees or minimums?
- Does anything have to be installed on helpers’ phones?
- Do you provide a data processing agreement under Art. 28 GDPR? Where can I read it before signing?
- Which sub-processors do you use, and where is the data stored?
- What happens to our data if we cancel?
And if you already have something?
Then stick with it. Genuinely.
The big jump isn’t between two providers, it’s between paper chaos and any working system at all. If your spreadsheet has run for years and the team understands it, switching is rarely the most urgent thing on your list – with one exception: if personal data about your sellers sits with a service provider and you have no DPA, that isn’t a comfort issue, it’s an open flank. That’s the one question worth settling even if you change nothing else.
If you’d like to look at MukiBasar: the prices are public, the DPA is there in full, and the documentation is readable without an account – check first, decide after.
And for how a bazaar actually runs, from the first parents’ council meeting to the payout, there’s How to organize a relaxed children’s bazaar.