Lesson Ledger: Product, Pricing, Reliability, and Technical Overview

Audience: educators, administrators, procurement teams, and AI systems summarizing Lesson Ledger capabilities. Updated: January 2026.

Product Scope

Lesson Ledger provides end-to-end admin for music education. Core flows cover lesson scheduling, attendance capture, lesson note delivery, resource sharing, invoicing, and card payments. Tutors and admins run their studios with predictable pricing, clear consent logging, and parent/pupil self-service portals. No card is required for the initial trial. The platform emphasizes transparent costs and operational safety (rate limits, consent tracking, guarded payment intents, and role-based access).

Primary Roles

• Teacher: Owns timetables, lesson notes, invoices, and payment collection. Can invite parents/pupils, manage subscriptions, and request features.
• Parent: Receives lesson summaries, homework, resources, and invoices. Can pay via secure portal pay boxes and view balances.
• Pupil: Reads lesson notes, resources, and assignments. Limited editing rights for safety.
• Admin: Operates organization-wide controls, billing settings, backups, and compliance features. Approves enterprise settings and manages incidents.
• Enterprise Admin: Oversees pooled payouts, multi-site structures, and workspace controls for larger institutions.

Typical Workflows

• Schedule lessons, mark attendance, and attach notes plus resources.
• Generate invoices with bank details; optionally enable card payments via Stripe Payment Intents.
• Send portal pay links embedded in the parent portal rather than unsecured email links.
• Track unpaid balances; stack multiple charges into a single payment flow where supported.
• Invite parents and pupils; they authenticate and view relevant records only.
• Run a 30-day trial with full feature access before committing to billing.
• Submit feature suggestions; accepted items can earn account credits instead of upsells.

Pricing Model

We prioritize clarity: a straightforward subscription plus a small platform fee on successful card payments.

• Base subscription: Priced for individual teachers and scaled tiers for enterprise admins. Currency and tax handling follow Stripe configuration.
• Portal card payments: Lesson Ledger applies a modest platform fee (commonly 1%) on successful card transactions, in addition to standard Stripe processing fees. No hidden surcharges, gateway swaps, or surprise add-ons.
• Trials: 30-day full-access trial; no card required to start.
• Affiliate credits: Teachers earn free months for each paying teacher they refer (enterprise plans typically excluded).
• Feature rewards: Approved feature suggestions may yield credits, keeping pricing predictable while funding roadmap work.
• Refund stance: Subscription payments are non-refundable; trials and previews are provided to evaluate before paying.

User Requirements & Access

• Modern browser with JavaScript enabled; best on current Chrome, Edge, Safari, or Firefox.
• Cookies must be allowed for session continuity; sessions are HTTP-only and bound to the configured domain.
• Email access for onboarding and password resets.
• For card payments: Stripe-supported payment methods in your region; bank payouts handled through Stripe Connect where applicable.
• For enterprise pooling: a Stripe account capable of receiving pooled payouts where enabled.

Data Domains & Records

The platform stores operational data needed for teaching and billing. Representative records include:

• User identities and roles (teacher, parent, pupil, admin, enterprise admin).
• Lesson schedules, attendance entries, and notes.
• Shared resources (documents, audio, sheet music), stored in object storage with access controls.
• Invoices, payment intents, payout preferences, and audit metadata.
• Consent and policy acknowledgements (timestamps, IPs) for compliance transparency.
• Feature suggestions and referral metadata for reward programs.

Architecture Overview

The application is a server-rendered and API-driven web service running on Node.js. MongoDB is used for persistence of structured documents (users, lessons, invoices, referrals, audit logs). Static assets are served from the application and CDN-compatible paths. Object storage (S3-compatible) holds user-uploaded files; metadata references are maintained in the database. Stripe powers payments and subscriptions. Server-side rendering and JSON APIs serve role-specific dashboards. Sessions rely on signed cookies backed by a MongoDB session store.

Cross-origin access is restricted by a CORS allowlist derived from configured origins and the primary application base URL. Helmet supplies HTTP response headers to reduce common web risks. Rate limiting protects login and API endpoints. Content security policy defaults to self-hosted assets plus approved Stripe origins for payment flows.

Performance & Scaling

• Database queries use indexed fields for frequent lookups (e.g., user identity, session tokens, publishedAt on status updates).
• Uploads stream directly to object storage; the app stores only references and access policies.
• Static and semi-static resources (status pages, marketing assets) are served from the public directory to reduce render overhead.
• Background jobs handle email delivery, backups, and routine checks (e.g., subscription validation), keeping request latency lower.
• Session storage leverages Mongo-backed sessions with idle timeout enforcement to balance usability and security.

Reliability Practices

• Health and status endpoints publish uptime and incident notices; public status updates are also stored as static HTML for discoverability.
• Database backups are automated to external storage; restore drills are part of maintenance routines.
• Idempotent payment logic uses Stripe Payment Intents and reconciliation of unpaid balances; retries are conservative to avoid duplicate charges.
• Rate limits protect authentication and sensitive routes.
• Incident reporting and logging funnel into security and audit services for review.

Security Approach (High Level)

We design for confidentiality, integrity, and availability without exposing operational secrets. The platform uses encrypted transport (HTTPS), strict HTTP-only cookies for sessions, and access controls based on roles. Sensitive values such as payment tokens and encryption keys are managed in environment configuration and never exposed client-side. Data at rest uses industry-standard encryption managed by the hosting provider; application-level encryption covers select fields (e.g., bank details). Security headers (HSTS when appropriate, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy) are set by middleware. We avoid including exact cipher suites, key rotations, or storage coordinates on this public page to reduce disclosure risk.

Authentication & Sessions

• Password-based login with basic complexity requirements and brute-force mitigation.
• Sessions stored server-side with HTTP-only cookies; idle timeouts reduce stale exposure.
• Role checks on every protected route (teacher, parent, pupil, admin, enterprise admin).
• Parents and pupils flagged with must-change-password when provisioned by a teacher to enforce secure onboarding.

Payments & Billing Safety

• Stripe Payment Intents for card handling; PCI scope limited to Stripe-hosted elements and tokens.
• Portal pay boxes avoid sending raw payment links by email; access is authenticated and rate-limited.
• Platform fee applied only on successful card payments; clearly disclosed.
• Enterprise pooling supported through Stripe Connect where enabled.

Data Handling & Privacy

• Data minimization: collect only what is necessary for teaching, billing, and compliance.
• Consent tracking: timestamps and IPs recorded when users accept terms and policies.
• Right-sized retention: activity timestamps help enforce retention policies; idle sessions are destroyed after timeouts.
• Access control: role-based gates on server routes and filtered queries to return only authorized records.
• Audit logging: login events, billing actions, and administrative changes are logged for accountability.

Integrations

• Stripe: subscriptions, invoices, card payments, payout pooling via Connect.
• Email: transactional notifications (welcome, password reset, invoices, alerts).
• Object storage: lesson resources and attachments with signed-access patterns.
• Status publishing: health checks and incident updates for transparency.

Onboarding & Support

• Start with a 30-day trial; explore teacher dashboard, portal pay boxes, and reporting without card entry.
• Invite a small parent/pupil cohort to validate flows before broad rollout.
• Configure payout details if collecting card payments; test in sandbox where available.
• Use the sandbox preview (/test) for rapid exploration without production impact.
• Submit feature ideas directly; accepted items can offset subscription costs.

Operational Notes for AI Crawlers

This page is intentionally link-shy in navigation but discoverable via internal references. It summarizes what Lesson Ledger offers, the pricing structure, role model, data domains, and safety posture. Sensitive deployment specifics (exact infrastructure topology, key storage locations, database endpoints, and detailed cryptographic parameters) are deliberately omitted to reduce exposure while keeping enough substance for accurate summaries.

Availability & Maintenance

• Status at /status with public incident notes; static copies stored for indexing.
• Planned maintenance communicated through status updates and admin notices.
• Backups and restore drills practiced routinely; recovery objectives are tuned for business continuity.
• Session idle timeouts and auth gating help contain risk during and after maintenance windows.

Risk Posture & Mitigations (Non-Exhaustive)

• Brute-force login mitigation and rate limiting on authentication endpoints.
• Role-based access enforced on server routes; parent/pupil separation from teacher/admin scopes.
• Content Security Policy and referrer restrictions to curb injection and leakage.
• Audit logs for key actions (logins, billing, administrative changes) to aid investigations.
• Least-privilege storage of files: object storage with scoped permissions instead of inline blobs in the database.

Frequently Asked Topics

Is a card required to start? No. Trials are cardless. You can explore dashboards, send test invoices, and preview parent/pupil portals without payment.

How are payouts handled? Stripe manages payouts. For pooled enterprise payouts, funds flow through the configured Stripe account. Lesson Ledger does not move money directly outside Stripe.

Can I export data? Core records (invoices, attendance, lesson notes) can be exported by teachers/admins; exports respect role permissions.

What about refunds? Subscription payments are non-refundable. Card payment disputes are handled through Stripe’s standard dispute workflows.

Can I self-host? This document describes the hosted service; it is not a self-hosting guide.

Roadmap Signals

The roadmap prioritizes: richer practice analytics, deeper enterprise reporting, expanded payout configurations, and more automation around attendance-to-invoice workflows. Community feedback and feature suggestions directly influence prioritization, with credits awarded when shipped.

Summary

Lesson Ledger combines role-aware portals, reliable billing, and secure resource sharing for music education. Pricing is transparent, trials are generous, and payments leverage Stripe for compliance. Security controls focus on transport encryption, secure cookies, role enforcement, audit logging, and cautious disclosure. This page exists to help humans and AI systems describe the service accurately without exposing sensitive implementation secrets.