It’s a Tuesday in February, and you’re three demos deep into replacing the setup you swore you’d replace last year. Each vendor walks you through a polished tour, ticks every box on your list, and asks for a contract. They all look fine. None of them shows you the thing you actually need to know, which is what your camp will feel like to run on day three of registration when a parent calls because their payment went through but their camper’s session still says pending.
A demo is built to show capability. Running a camp is about coherence — whether the parts know about each other when no salesperson is in the room. This is a checklist for judging that, the part the tour skips. It’s the buyer’s side of choosing camp management software: not what a system claims it can do, but how to tell, before you sign, whether it holds together.
Judge coherence, not feature count
The instinct when you compare systems is to line up capabilities and count. Does it do registration? Payments? Medical forms? Communication? Two systems can answer yes to all four and be nothing alike.
A feature checklist measures whether a job gets done somewhere in the software. It doesn’t measure whether the parts that do those jobs share a record. In one system, a camper’s payment and their medical form belong to the same camper. In the other, they’re two databases you keep in sync by hand. That difference never appears on a comparison grid. It appears every day you run the camp, and most sharply at season end, when a coherent system reads its financial picture off one ledger and a stitched one makes you match a payment export against a roster row by row.
So the first question isn’t “what can it do.” It’s “when I enter a camper once, where does that show up — and where do I have to enter them again.” The deeper version of this — exactly where stitched-together tools leak — is the subject of all-in-one vs. point solutions. For the checklist, it’s enough to know the test: enter a thing once and watch how far it travels.
Run one camper through the whole season
The most useful evaluation you can do isn’t reading a feature list. It’s tracing a single camper end to end and counting the hand-offs.
Take one imaginary family and walk them through the system you’re evaluating. The parent registers a returning camper. Does last year’s record prefill, or do they start from a blank form? They add a sibling. Does the sibling link to the family, or get keyed in fresh? They pay a deposit and set up a plan. Does that charge know which camper and which session it belongs to, or land in a separate ledger you’ll reconcile later? They submit a medical form with an allergy and a daily medication. Does that arrive as structured fields a nurse can sort and flag, or as a PDF that sits in a folder until someone opens it?
Each point where the camper has to be entered again, or a record fails to carry forward, is a seam — and seams are where your season’s by-hand work collects. A coherent system carries that camper through registration, payment, and the medical record on one record, so the returning family prefills, the sibling links, the deposit knows its session, and an incomplete medical form surfaces on its own before opening day. Count the seams in the demo. That number is what you’ll be doing by hand all summer.
Check what you can take with you
The hardest thing to evaluate is the part no vendor volunteers: whether you can leave. Every system makes getting in easy. Getting out is where the real architecture shows.
Ask, before you sign, what your export looks like. Not whether one exists — they all say yes — but what comes out and in what shape. Rosters, registration history, and fee history are the backbone, and they usually port cleanly. The high-risk records are returning-family links and structured medical data: exported as flat text or a PDF dump, they stop being queryable, and you’ve quietly downgraded your safest records into a stack of documents. The more structured and relational a record is, the more careful its export has to be — which is the whole subject of what actually moves when you switch camp software.
The move that costs nothing and tells you the most: ask the vendor to audit your real export. Hand them the file from your current system and have them name what ports cleanly and what comes out lossy. A vendor willing to do that gives you a specific answer about your specific data. A vendor who deflects is telling you the exit is harder than the entrance — the most important thing to learn now, not a year in.
Weigh the parent side, because it’s your support load
Most software checklists are written from the admin’s chair. But the parent experience belongs on the list, because the parent side is where most of your support calls come from. Every question the software can’t answer becomes a question you answer by hand.
So look at what a parent can do without calling the office. Can they see what they still owe, and pay it, without an email back and forth? Can they find last year’s receipt or a tax statement on their own? Can they set up or adjust a payment plan, save a card for autopay, register a sibling, and check whether their forms are complete — all from one place that knows who they are? When the parent view carries balances, payment plans, receipts, and registration status, the questions answer themselves and your inbox stays quiet. When it doesn’t, you become the parent dashboard, one phone call at a time.
This is an axis you can observe in a demo without any numbers. Ask to see the parent side, not just the admin side, and ask the vendor to show you a returning family logging in. How much they can do alone is how much you won’t be doing for them in July.
Read the pricing model, not just the price
You can’t always compare prices honestly — list prices move, discounts vary, and the validation here is on the shape, not the figure. But you can compare pricing models, and the model tells you more than the number.
A per-camper model scales with the size of your season; a flat tier charges the same whether you grow or shrink; an add-on model quotes a base and bills the modules separately, so the real cost is the one you assemble at checkout. None of these is wrong on its own. What you’re checking is whether the price you’re quoted is the price you’ll pay, or a starting point that climbs as you turn on the parts you assumed were included. Camp Runner’s model is one published rate — $1.50 per active camper, per month — so the bill tracks the season instead of the feature list, and you can estimate that cost for a camp your size before you ever talk to anyone. Ask each vendor to total the real cost for a camp your size with the features you’d actually use, and read whether the answer is a single number or a stack of line items.
The short checklist
Run this against any system before you commit:
- Coherence. Enter one camper and count how many places you re-enter them. Fewer is the whole point.
- One record. Confirm a payment, a registration, and a medical form belong to the same camper — not three databases you reconcile by hand.
- Portability. Ask for an export audit on your real data; confirm what ports cleanly and what’s lossy, in writing.
- Parent side. Watch a returning family log in, see a balance, pay, and register a sibling without calling the office.
- Pricing model. Get the real total for your camp’s size and feature set, and read whether it’s one number or a climbing stack.
You run the camp, and you make the call. A demo will tell you what a system can do; this checklist tells you what it’ll be like to run on the morning everything happens at once. When you want to put a system through the one-camper trace yourself, the feature tour walks a real registration end to end, and you can join the waitlist to start with your own export rather than a sales pitch.
Common questions
- What should I look for when choosing camp management software?
- Look past the feature checklist to three things it hides: whether the parts share one camper record, whether you can take your data with you when you leave, and what the parent side actually feels like to use. A capability list tells you a job gets done somewhere in the software. It doesn't tell you whether the parts know about each other, and that's what you run on every day.
- Why isn't a feature checklist enough to compare camp software?
- Because two systems can check the same boxes — registration, payments, medical — and be nothing alike underneath. In one, the payment and the medical record belong to the same camper, so you enter a thing once and it's available everywhere. In the other, they're separate databases you keep in sync by hand. That difference never shows up on the checklist; it shows up at season end when you reconcile three tools by hand.
- How do I test data portability before I sign?
- Ask the vendor to look at your real export — not a demo — and tell you which records port cleanly and which come out lossy. Rosters and fee history usually move fine; returning-family links and structured medical records are where careless migrations lose the most. A vendor who'll do this audit gives you a specific answer about your specific data, which is worth more than any promise on a sales call.
- Why does the parent experience belong on a software checklist?
- Because the parent side is where most of your support load comes from. If a parent can't tell what they still owe, find a receipt, or register a sibling without re-typing last year's record, your inbox fills with the questions the software should have answered. A self-serve parent view of balances, payment plans, receipts, and registration status is the difference between a quiet office and a busy one.
- What's the one question that separates a good vendor from a hopeful one?
- Ask whether you can leave with your data intact, and ask them to prove it on your actual export before you sign. A confident vendor will show you what ports cleanly and name what doesn't. A vendor who deflects is telling you the exit is harder than the sales pitch — which is the most important thing to learn before you commit, not after.
