Karate Software · Karate, taekwondo, BJJ, and martial-arts schools · Early access · 2026

Enrollment, attendance, belt progression, and safe media — the dojo platform that starts with the parent-trust layer

Karate Software is built for youth-heavy martial-arts schools that need more than billing software. The family-safe CRM stores every guardian, every authorised pickup contact, every custody restriction, and every consent record — and the check-in engine enforces them, not a sticky note at the front desk. Consent-gated belt-ceremony galleries and a branded parent storefront handle the photo and video commerce. Belt-progression engine and autopay tuition billing are early-access. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How it works

Fail-closed pickupauthorised-list enforcement at the data layer — not a dismissible popup

Consent-firstopt-in before the first mat session — no photo, no comms without guardian consent

No-skim payoutsexact-cent distribution — fee off gross first, dojo keeps the remainder

Delete-on-requeststated window, logged — no record persists beyond stated retention

The parent-trust layer — why it is the foundation, not a feature

Most dojo software treats family safety as a notes field. This platform enforces it at the engine.

A child in a martial-arts school is a minor in the custody of their guardian. The dojo is responsible for knowing who is authorised to be with that child, who consented to that child’s photograph appearing in a gallery, and what happens to that child’s records when the family leaves. These are not edge cases. They are the operating reality of running a youth program.

Karate Software is built around that reality. The family-safe CRM structures custody restrictions as a flagged field that surfaces at the pickup gate — not a note in a comment box that depends on staff memory. The consent layer is collected at enrollment, stored as a machine-readable record, and enforced at every operation that touches a student’s image or contact details. A student whose family did not consent to photography is absent from the gallery — not blurred, not noted, not present. When a family leaves and requests deletion, the records come down within a stated window, logged.

The family CRM, check-in engine, and consent substrate are built and production-ready. The belt-ceremony gallery and branded parent storefront are built and production-ready. The payment rail is honest-off: the engine is there, the charge rail is not yet enabled. The belt-progression engine and autopay tuition billing are early-access.

Book a conversation Full platform

How it works

The dojo operating year in four stages

Karate Software runs on the rhythm of a martial-arts school: family enrollment and consent collection before the first session, check-in and pickup enforcement on the mat floor, belt test and ceremony season with consent-gated media delivery, and a clean annual records handoff. Every stage is described as it is built today.

Step 1 · Enrollment and family setup — CRM, consent collection, and pickup configuration

A new family enrolls with a complete student record from day one: primary and secondary guardian details, every authorised pickup contact with their relationship and any photo-ID confirmation notes, emergency contacts in order of priority, and any custody restriction flags that apply. Consent is collected at this stage — depiction consent for photos and videos, communications consent for the channels the dojo will use to reach the family — before the student steps onto the mat. No message reaches a family who has not opted in. No student appears in a gallery whose guardian did not consent. The dojo owns all student and family records from day one.

Step 2 · First mat sessions — check-in, authorised-pickup gate, and attendance

Each class session opens with QR or PIN check-in at the door. The system marks the student present, logs the time, and updates the class attendance record. Ratio tracking ensures class capacity is respected in the engine, not on a clipboard. At the end of class, the pickup gate governs every departure: the contact presenting to collect a student is matched against the authorised list for that student. A custody restriction flag stops a prohibited contact at the counter without requiring staff to remember which children have restrictions. The engine surfaces it. Attendance records build automatically across sessions and contribute to test-eligibility calculation when the progression engine is live.

Step 3 · Belt test and ceremony season — media consent, gallery delivery, and storefront

A belt test cycle begins with the instructor reviewing which students meet the current requirements for promotion. The test-eligibility scoring engine — early-access — will calculate this automatically from live attendance and checkoff data. On ceremony day, the photographer’s workflow is governed by the consent records: a student whose guardian did not consent to photography is not captured, and the flag is visible at the photographer’s device. After the ceremony, the consent-gated gallery organises images by student and rank advancement. Consented families access their private gallery and order from the branded storefront. The gallery and print fulfillment pipeline are built. Live checkout is honest-off until the payment rail is enabled.

Step 4 · Annual records and family audit — rank history, data export, and deletion

At the end of each year, the dojo has a complete record of every student’s attendance, rank history, and ceremony media — stored against their consent record. When a family leaves, delete-on-request is available: the family can request removal of their student’s records and media within a stated window, and the deletion is logged. No record of a departing student persists beyond the stated retention period. A full data export delivers every student record, consent log, attendance history, and belt-progression record in a portable format — so the dojo owns its data and can carry it independently of the platform.

The full platform

Five engines — honest about what is built and what is early-access

Every feature is labelled honestly: Built means the underlying engine is production-ready. Early-access means the surface is in active development. We do not claim otherwise.

Family-safe student CRM — guardians, pickup authority, emergency contacts, and custody flags

Every student record in Karate Software starts from the guardian, not the student. The family-safe CRM stores every adult associated with a child: primary guardian, secondary guardian, authorised pickup contacts with individual photo-ID confirmation notes, emergency contacts with role and relationship, and custody restriction flags — restraining-order notes, pickup-prohibited contacts, and court-document references that front-desk staff can surface in two taps at pickup time. No adult who is not on the authorised list moves a child from a mat session. The restriction system is not a text field in a notes box — it is a structured flag the system enforces at the check-in and pickup layers. The family-safe student CRM is built and production-ready. The same data model is built to handle a dojo owner-operator from a single 75-student location to a 1,500-student multi-location studio group.

Family CRM built · production-ready

Attendance and authorised-pickup gate — QR/PIN check-in, ratio tracking, and a fail-closed pickup rule

The check-in engine handles every mat session: a student scans a QR code or enters a PIN at the door, the system marks attendance and logs the check-in time against the class record. Ratio tracking runs on the BAS (before-and-after-school) substrate — class ratios are enforced in the engine, not on a whiteboard. At pickup, the fail-closed rule governs: a staff member cannot release a student to a contact who is not on the authorised list for that student. Not by a warning popup that can be dismissed — by the engine refusing the release and surfacing the restriction record. A custody flag stops a prohibited contact at the counter before the conversation starts. Attendance records are stored per student and exportable per class or per period without rebuilding the history from memory. The check-in engine and fail-closed pickup gate are built and production-ready.

Check-in & pickup gate built · production-ready

Consent-gated belt-ceremony galleries, branded parent storefront, and print fulfillment

Belt ceremonies are the dojo’s signature moment: every student advancing a rank deserves a record of it, and every family that opted out of photography deserves to have that decision enforced. The consent-gated gallery maps every photo and video clip to a performer-level consent record. A student whose guardian did not consent to photography is not in the gallery — not blurred, not cropped out, not present. The gallery is private to consented families: no public URL, no searchable index. A branded parent storefront lets families order digital downloads, print packages, and photo albums directly from the ceremony gallery. Payout rails distribute proceeds to the dojo with exact-cent accuracy: the fee is deducted from gross first and the dojo receives the remainder with no skim. The consent-gated gallery, branded storefront, and print/product fulfillment are built and production-ready. The live checkout interface that accepts payment from parents is honest-off — present in the platform, not enabled for live transactions today.

Gallery & storefront built · live checkout honest-off

Belt-progression engine — curriculum maps, checkoffs, rank history, and test-eligibility scoring

The belt-progression engine tracks every student’s rank history from white through the school’s highest degree: curriculum maps define the requirements for each rank transition (techniques, forms, sparring criteria, minimum attendance, character standards), instructor checkoffs record mastery of each requirement, and the rank history preserves the full promotion record with date and certifying instructor. Test-eligibility scoring calculates whether a student meets every requirement for the next test date based on live data — attendance logs, checkoffs, and time-in-rank — and surfaces the result to the instructor without manual calculation. Parent-visible progress shows a family where their child stands on the path to the next rank without requiring a phone call to the front desk. The belt-progression engine, test-eligibility scoring, and parent-visible progress dashboard are early-access — in active development, not yet live as a shipped product.

Belt progression · early-access

Tuition and dojo billing — transparent plans, test fees, and no-hidden-fee model

Dojo billing plans cover the recurring structures a martial-arts school actually runs: monthly tuition by rank or program level, family-rate multi-student discounts, testing fees collected once per promotion cycle, uniform and equipment line items, and trial-period configurations for new students. The no-hidden-fee model is enforced in the billing data layer: the fee a family sees in enrollment is the fee they pay, with no platform surcharge inserted between the dojo and the family after signup. The billing engine stores plan configurations and calculates amounts. The payment rail that moves money — the live checkout interface that charges a parent’s payment method — is honest-off: present in the platform, not enabled for live transactions today. Dojo autopay tuition billing, family billing portal, and collections workflows are early-access — in active development.

Billing engine early-access · payment rail honest-off

Who uses it

Built for single-location dojos, multi-location studios, and school-affiliated martial-arts programs

Single-location dojos

An owner-operator running 75 to 400 students at a single location gets a complete operating system without enterprise-software complexity. The family CRM handles the full guardian and pickup configuration from enrollment. Check-in runs on phones or a front-desk tablet without additional hardware purchase. Belt ceremonies produce a consent-gated gallery the owner can deliver to families without a separate photo service. The single-location dojo is the primary buyer the platform is designed around.

Multi-location studios and franchise operations

A studio group or franchise running 400 to 1,500 students across two or more locations needs consistent enforcement of the parent-trust rules across every front desk. The consent and pickup rules are configured at the organisation level and enforced the same way at every location: no location opts out of the fail-closed pickup gate or the consent-gated photography rules. Reporting consolidates across locations so an operations director sees the full picture.

School-affiliated and after-school martial-arts programs

A district-affiliated or school-site martial-arts program runs under institutional rules for minor data: FERPA-aware data handling, ratio compliance records, authorised-pickup enforcement aligned with the school’s own records. The BAS (before-and-after-school) substrate was built for this compliance context. A school-affiliated program gets the same consent and pickup architecture as a standalone dojo, with the data-handling posture a school or district expects.

Student data & family consent

The dojo owns its data. Consent is collected, not assumed. No minor’s photo goes public without it.

Student enrollment records, attendance logs, belt-progression history, gallery access, and family contact details belong to the dojo — not to the platform. No student or family data is sold to or shared with outside companies or advertisers. No behavioral or location tracking runs on minor students. No student photos appear in a public gallery, public search index, or any external use without an explicit marketing-consent record for that student.

Consent is collected at enrollment for two purposes: depiction consent (photos and videos of the student) and communications consent (channels the dojo will use to reach the family). Both are opt-in. A family that does not consent to photography has their student excluded from every gallery and every storefront product. A family that withdraws communications consent stops receiving messages. Consent can be withdrawn at any time. The one-click export is available in writing — if the dojo ever leaves the platform, every record leaves with it.

What is built and what is coming — plainly

The CRM, check-in gate, and gallery are built. The belt-progression engine and payment rail are not live yet.

Built and production-ready today: the family-safe student CRM (guardians, authorised pickup list, custody restriction flags, emergency contacts); the check-in engine and fail-closed pickup gate (QR/PIN, ratio tracking, release enforcement at the data layer); the consent substrate (depiction and communications consent, opt-in, revocable, logged); the consent-gated belt-ceremony gallery (performer-level consent mapping, private access, no public index); the branded parent storefront and print/product fulfillment pipeline; and the no-skim payout rails (exact-cent, fee off gross first).

Not yet live: the payment rail (the part that moves money), live gallery purchase checkout, live tuition autopay, the belt-progression engine (curriculum maps, checkoffs, rank history, test-eligibility scoring, parent-visible progress), and live carrier delivery for SMS parent messaging. These are honest-off or early-access — present or in active build in the platform, not yet enabled for live use. There is no live checkout here. No billing. No subscription. We say so directly because dojo owners deserve to know what is production-ready and what is still being built.

Connected to the school platform

Karate Software runs the dojo. Assembly captures the ceremony. Seen puts every student on a page.

Karate Software manages the enrollment, the check-in floor, and the belt-ceremony gallery. Assembly is the moment layer: live school events captured, ticketed, and archived — the belt promotion ceremony, the tournament send-off, the end-of-year banquet. A belt ceremony is a live event; Assembly and Karate Software are natural partners for the same night. Seen is the recognition layer: the programme that ensures every student athlete and performer lands on a real page in the yearbook, the newspaper, or the programme — adviser-approved and consent-verified. For the school publishing platform these products connect to, homeroom.software is the foundation.

assembly.school seen.school homeroom.software

Early access · Dojo owners, studio directors, and school program coordinators

Book a conversation to see the current state honestly

Karate Software is in active development. We do conversations that show the current state honestly: how the family CRM handles a student with multiple guardians, an authorised pickup list, and a custody restriction flag; how the check-in engine runs a mat session with ratio tracking and the fail-closed pickup gate; how the consent-gated belt-ceremony gallery organises a promotion night by student and rank; and where the belt-progression engine stands in the build. There is no pricing commitment and no signup. If it looks right for your school, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

What is the “parent-trust layer” and why does it matter for a dojo?

Most dojo software treats family safety as a text field in a notes box: write “do not release to John Doe” and hope the front desk remembers. The parent-trust layer in Karate Software is a structured data layer enforced at the engine: authorised pickup contacts per student, custody restriction flags that surface at check-in without staff needing to remember, and consent records that govern photography, communications, and data retention. A prohibited contact is stopped by the system at the counter, not by a staff member who happened to recall a handwritten note. The trust layer is not a feature added on top of billing software. It is the foundation the operations are built on.

How does the authorised-pickup gate work on the mat floor?

At the end of a class, when a contact presents to collect a student, the system matches them against the authorised pickup list for that student. A contact who is not on the list cannot complete the pickup — the engine refuses the release and surfaces a clear message to staff. A custody restriction flag goes further: it stops a prohibited contact by name and surfaces the restriction record, including any document-reference note. This is not a popup that can be dismissed. It is a fail-closed rule enforced at the data layer. Staff do not need to remember which children have restrictions. The system enforces it consistently for every child, every session.

Is the belt-progression engine built? Can families track rank progress today?

Not yet. The belt-progression engine — curriculum maps, instructor checkoffs, rank history, test-eligibility scoring, and parent-visible progress — is early-access and in active development. It is not yet live as a shipped product. What is built today: the family CRM, check-in and attendance, the consent substrate, and the belt-ceremony gallery and storefront. The belt-progression engine is the next vertical surface being built. In a conversation we can show where it stands in the build and discuss what early access looks like.

How do the consent-gated belt-ceremony galleries work?

Every belt ceremony produces photos and video that families want — but not every family consented to their child being photographed. The consent-gated gallery is built on the consent substrate: every image is tied to a performer-level consent record. A student whose guardian did not consent to photography is not in the gallery. Not blurred, not listed with a note, not present. The gallery is private to consented families: there is no public URL and no searchable index of student images. Families who did consent access a private gallery and can order digital downloads, print packages, and albums through the branded parent storefront. The gallery, storefront, and print fulfillment pipeline are built and production-ready. The live checkout interface that accepts payment is honest-off — not enabled for live transactions today.

Is the payment rail live? Can we collect tuition, test fees, and gallery orders now?

Not yet. The billing engine, the payout-rails split calculation, the gallery, and the storefront commerce substrate are built and production-ready — the logic, the ledger, and the fulfillment pipeline are all there. The payment rail that moves money is honest-off: it exists in the platform but is not enabled for live transactions today. There is no live tuition checkout, no live gallery purchase, and no subscription. When the charge rail is enabled (a founder-gated decision), dojos will be notified. The CTA here is “book a conversation,” not “sign up and pay.”

What happens to student data when a family leaves the dojo?

A family that leaves can request deletion of their student’s records: enrollment data, attendance history, belt-progression records, gallery access, and any media associated with the student. Deletion happens within a stated window and is logged in the consent ledger. No record of the student persists beyond the stated retention period. The dojo also owns a full export of its records — the student roster, consent logs, attendance history, and ceremony media — in a portable format. If the dojo ever leaves the platform, every record leaves with it. This guarantee is part of the onboarding agreement, not a footnote in a terms page.

How do custody restrictions work? Can we block a specific contact from picking up a student?

Yes. The family CRM stores custody restriction flags as a structured data field, not a free-text note. A restriction flag includes the prohibited contact’s name, the restriction type (pickup-prohibited, restraining-order-referenced, supervised-only), and an optional document-reference note for the court order or legal document on file. At pickup, the flag surfaces automatically when the check-in engine encounters that student — no staff member needs to remember which students have restrictions. The engine enforces it for every session. Adding, editing, or removing a restriction is an authorised-user action with an audit log entry.

What about photos of students whose families opted out of photography?

A student whose guardian did not consent to photography does not appear in any gallery, program, or storefront product. The no-photo flag is enforced at the gallery-ingestion layer: images captured at a belt ceremony are mapped to student records, and any image associated with a non-consenting student is excluded from the gallery automatically. The flag is also surfaced at the photographer’s device during the ceremony shoot, so the exclusion can be applied before capture, not only after the fact. No opt-out student is present in any image shared with another family or offered for sale. This is an engine-level enforcement, not a policy reminder.

Is this built for karate specifically, or does it work for other martial arts styles?

The platform works across karate, taekwondo, Brazilian jiu-jitsu, mixed martial arts, judo, hapkido, and other youth-heavy martial-arts disciplines. The family-safe CRM, check-in and pickup gate, consent substrate, and gallery workflows are style-agnostic. The belt-progression engine — early-access — is designed to support configurable rank structures: karate kyu/dan, taekwondo gup/dan, BJJ stripe and belt systems, and hybrid school-specific progressions. If your discipline has a named rank structure and a promotion ceremony, the platform is built to handle it. The domain is karate.software because that is the most-searched entry point for the audience. The product serves all youth martial-arts schools.

What can a dojo owner actually use right now?

The platform is in active development. In a conversation we walk through the current state honestly: the family CRM configured for a student with multiple guardians, an authorised pickup list, and a custody restriction flag; the check-in engine running a class session with ratio tracking and the fail-closed pickup gate; the consent-gated belt-ceremony gallery with a private family access link and a branded storefront; and the payout-rails split projecting the exact-cent distribution to the dojo. None of those involve live payments today. Belt-progression, test-eligibility scoring, and autopay tuition billing are early-access and shown in that state. A conversation is the honest next step — we show what is built, where the early-access surfaces stand, and what a first access arrangement looks like.

How does Karate Software handle student photos in marketing? Can we use gallery images on the dojo website?

Gallery images are produced under a specific consent record: a family consented to photos for the belt ceremony and the private gallery, not necessarily to public use on a website or social account. Using gallery images in marketing requires a separate, explicit consent from the guardian — the platform tracks whether that consent has been collected. Images without explicit marketing consent are not available for export to external use. This is intentional: the default state is private and consent-specific. A family that consented to a private gallery did not consent to a public website. The platform distinguishes between the two.