Software built around how a gymnastics academy actually runs.

It is one system for the class side of a gymnastics business: term enrollments, class levels, waitlists, make-up lessons, attendance, and family billing. Parents enroll and pay online, coaches record skill progress against the level, and staff see rosters, balances, and make-up credits on one family record. It fits academies whose levels, terms, or billing rules do not fit neatly into a standard class platform.

A youth league system is built around teams, fixtures, and rosters. A swim school system is built around pool lanes and lesson stages. A gymnastics academy runs on something else: classes grouped by age and level, enrollment by term, progression through skills, make-up lessons when a child misses a class, and one bill for a whole family. This page is about that workflow, not team sports or swim lessons.

A parent picks a class by age and level, sees whether a place is open, and enrolls for the whole term in one step, not session by session. The class fills to a hard cap, never past it. Prices, annual fees, and sibling or multi-class discounts are set before enrollment opens, so the bill a parent sees is the bill the academy meant to charge. Staff approve enrollments that need a level or age check before payment is taken.

When a child misses a class, the absence creates a make-up credit on the family record with a clear expiry rule your academy sets, for example within the same term or within 30 days. Parents book the make-up themselves into a class at the same level with an open place, without calling the front desk. Staff see who owes a make-up, who has used one, and which credits have expired, so nobody argues from memory.

No. Software can show the skills for the current level, which ones the coach has marked as done, what is still missing, and which class the gymnast would move to next. Qualified coaches own readiness, assessment, safety, and the move itself, with a clear approval step. A calculated status should never replace a coach's judgment, and a past level record should never be overwritten when your level names or skill lists change.

One family account holds every child, every class, and every charge, so a parent gets one bill, not one per child. Sibling discounts and multi-class discounts apply automatically from rules you set, mid-term joins are prorated, and failed payments trigger retries and a card-update prompt before staff have to chase anyone. Annual fees, meet fees, and pro-shop sales sit on the same record, with a clear history of who paid what and when.

When a class reaches its cap, the booking option becomes a waitlist place, in order, with the date each family joined. When a place opens, the next family gets an offer with a short hold window, so the place is not promised to two families at once. If the family declines or the hold expires, the offer moves to the next family automatically, and the front desk sees the full queue instead of a spreadsheet nobody trusts.

Configure an established class platform, such as iClassPro or Jackrabbit, when its class, level, term, and billing model fits your academy with reasonable setup. Build custom when your levels, term rules, make-up policy, or family billing keep bending around the platform: extra tools for waivers and messages, manual discounts, or a make-up system parents cannot use themselves. If your rules are still changing every term, settle them first, then decide.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how deep the class and level structure goes, how many kinds of users it serves, what it needs to connect to, whether records need moving over, whether phones or tablets are involved, and any safeguarding requirements. The agreed phase is priced in writing before it starts.

Timing depends on scope: a bounded audit or proof of concept is a smaller engagement, while a system with several connections to other systems, records to move over, a parent app, or formal safeguarding controls takes longer. The schedule is set once the first workflow and what 'done' looks like are clear.

Yes. Takeover is a common first engagement, and it always starts with an audit: where the code lives, how your data is organized, what is tested, which outside services it depends on, who can access what, and how updates go live. Code that is understandable and fit for the next release stays; only the parts blocking reliability get replaced. AI-built prototypes can be assessed as starting points. And if you already paid another vendor and have nothing working, the audit tells you which story you have before you spend more.

Security starts with the data, the people, who can see and change what, the systems it connects to, and where it runs. For children's records this matters more, not less: guardian-verified access, restricted access to minors' records, separate testing and live environments, protected passwords and keys, activity logs, backups, and recovery plans. We write down which protections are included and which evidence your team or an independent specialist must provide. We do not call a product compliant until the technical, operational, and legal requirements are all verified.

We need one person who owns the academy workflow, access to the relevant users and systems, timely answers on business rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.

Ask for the quote to name everyone who will use the system, including your own team. Every platform has two products: what families see, and what your people use all day: approvals, exceptions, refunds, managing users, and a record of who did what. When that second product is quoted as an 'admin panel' on a single line, it becomes the overrun. Our quotes treat your team's screens as their own scope, with their own users. Then the phase names the workflow, what 'done' looks like, the price, and the exclusions, all before paid work starts. You review working software at agreed checkpoints, and when new information changes the scope, you hear the effect on price and timing before anything is approved.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the workflow agreed at the start. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.

Yes, when they are scoped as part of the same academy record. A trial booking should convert into a term enrollment without retyping the family. Camps and private lessons share the same family account, billing, and attendance history, but keep their own capacity and pricing rules. If trials, camps, and term classes live in separate tools, staff reconcile them by hand, and that reconciliation is usually where the errors start.

Moving your data over is scoped as its own work, not an afterthought. We map your current classes, levels, enrollments, make-up credits, balances, and family links into the new structure, and we check the result with you before anything goes live: counts per class, open balances, and unexpired make-up credits. Records that cannot be mapped cleanly are flagged for your decision, not silently dropped or guessed.

Yes, when that is part of the first scope. Each location keeps its own classes, coaches, capacity, and term dates, while families, billing, and level history stay shared where a child trains at more than one site. If locations currently run on separate spreadsheets, agreeing on one shared level structure and one billing rulebook comes before the build, not after it.