17 domain design docs covering architecture, accounts, inventory, rentals, lessons, repairs, POS, payments, batch repairs, delivery, billing, accounting, deployment, licensing, installer, and backend tech architecture. Plus implementation roadmap (doc 18) and personnel management (doc 19). Key design decisions documented: - company/location model (multi-tenant + multi-location) - member entity (renamed from student to support multiple adults) - Stripe vs Global Payments billing ownership differences - User/location/terminal licensing model - Valkey 8 instead of Redis
19 KiB
Music Store Management Platform
Deployment, Compliance, Pricing, Updates & Support
Version 1.0 | Draft
1. Deployment Models
The platform supports two deployment models. Customers choose based on their infrastructure preferences, IT capability, budget, and data sovereignty requirements. The core application codebase is identical — deployment configuration differs.
SaaS (Cloud Hosted)
Self-Hosted (On-Premise)
Infrastructure
AWS — vendor managed
Customer's own hardware
Updates
Automatic — zero customer action
One-click via admin panel
Uptime responsibility
Vendor (99.9% SLA)
Customer's IT / hardware
Backup
Vendor managed — automatic
Customer managed + optional cloud backup add-on
Pricing model
Monthly subscription
One-time license + annual maintenance
Internet required
Yes — always online
Local network only — internet optional
Data location
AWS us-east-1 (default)
Customer's premises
Best for
Stores without IT staff, smaller operations
Stores with IT, internet-sensitive, AIM migrants
1.1 SaaS Architecture
Multi-tenant deployment on AWS EKS. Each company is a tenant — data is logically separated by company_id on all tables. Physical locations within a company are distinguished by location_id on inventory, transaction, cash drawer, and delivery tables. Infrastructure is shared but data is never commingled in queries. Separate Aurora database clusters available as a premium option for large customers requiring hard data isolation.
AWS EKS (Kubernetes) └── API pods (auto-scaling) └── Admin frontend pod └── Customer portal podAurora PostgreSQL (Multi-tenant, company_id + location_id scoped)ElastiCache Redis (session, queues)S3 (PDFs, backups, exports)CloudFront (static assets)Route53 (DNS — customer.platform.com subdomains)
1.2 Self-Hosted Architecture
Single-tenant Docker Compose deployment. Designed to run on a modest mini PC or small server on the store's local network. Electron desktop app and iOS app connect to the local API over LAN. Remote access optional via VPN.
Recommended hardware: Mini PC (Intel NUC or equivalent) CPU: 4-core, RAM: 16GB, Storage: 500GB SSD OS: Ubuntu 24 LTS Estimated hardware cost: $300-600Docker Compose stack: └── api (Node.js / Python API) └── postgres (PostgreSQL 16) └── redis (Redis 7) └── admin (Admin frontend — Nginx) └── portal (Customer portal — Nginx) └── nginx (Reverse proxy, SSL termination) └── updater (Update checker service) └── backup (Automated local backup service)
Installer script handles Docker installation, initial configuration, SSL certificate generation (self-signed or Let's Encrypt), and first-run database setup. Target setup time under 30 minutes for a competent IT person.
1.3 Offline Resilience (Both Models)
POS operations are the most critical function. Both deployment models support degraded offline operation to prevent a total outage from stopping the store.
-
Desktop app caches current inventory, customer list, and open tickets locally
-
Cash and card-keyed sales can be queued locally if backend unreachable
-
Stripe Terminal card-present payments require internet — clear staff messaging when offline
-
Sync occurs automatically when connection restored — conflict resolution logged
-
Self-hosted: local network outage only affects cloud backup and update checker — core POS unaffected
2. Update Mechanism
2.1 SaaS Updates
SaaS customers receive updates automatically. No customer action required. Updates deployed using rolling deployment on EKS — zero downtime. Database migrations run as part of the deployment pipeline and are always backward compatible.
-
Minor updates (bug fixes, small features) deployed continuously
-
Major updates announced via in-app notification 7 days in advance
-
Breaking changes (schema changes, workflow changes) communicated with migration guides
-
Rollback capability maintained for 24 hours after any deployment
-
Maintenance windows scheduled 2am-4am local time for database migrations if required
2.2 Self-Hosted Updates
Self-hosted customers receive updates via an in-app update checker built into the admin panel. The updater service polls the vendor update registry on startup and daily thereafter.
Update Flow
-
Admin panel shows current version and available version when update exists
-
Changelog displayed before update — store admin can review what changed
-
One-click update: pulls new Docker images, runs database migrations, restarts services
-
Automatic backup taken before every update — rollback available if update fails
-
Update log stored locally — full history of applied updates
Update Registry
Vendor hosts a simple update registry API: GET https://updates.platform.com/check ?version=1.4.2&license=LICENSE_KEY Returns: { latest: '1.5.0', required: false, changelog_url: '...', download_url: '...' }required: true = security update — admin warned, update strongly advisedrequired: false = optional update — admin chooses timing
Database Migration Safety
-
All migrations are additive — new columns, new tables, new indexes
-
No destructive migrations (DROP COLUMN, DROP TABLE) without explicit data export first
-
Migrations tested against production-size data snapshots before release
-
Each migration includes a rollback script
-
Migration history table tracks applied migrations — idempotent on re-run
2.3 Version Support Policy
Version Status
Policy
Current
Full support — all bugs fixed, all features available
Previous major
Security fixes only — 12 months after new major release
End of life
No support — customers on annual maintenance must update
3. Compliance & Certification
3.1 PCI DSS Compliance
Payment Card Industry Data Security Standard (PCI DSS) compliance is required for any business that handles card payments. The platform's architecture is specifically designed to minimize PCI scope.
Scenario
SAQ Level
Requirements
SaaS — Stripe Terminal + Elements
SAQ A
Self-assessment questionnaire only — no audit. Card data never touches platform servers.
Self-hosted — Stripe Terminal + Elements
SAQ A
Same as SaaS — Stripe handles all card data. Customer must secure their local network.
Any keyed entry NOT using Stripe Elements
SAQ D
Full audit required — avoided by design. Platform never implements raw card input fields.
SAQ A requirements for the platform vendor (Lunarfront Tech LLC):
-
Never store, process, or transmit cardholder data on platform servers
-
Maintain secure development practices — no card data in logs
-
Annual SAQ A self-assessment completion
-
Provide PCI compliance documentation to customers on request
-
Self-hosted customers receive a PCI compliance guide covering their local environment requirements
3.2 SOC 2
Status
Priority
Notes
Not required at launch
Defer
SOC 2 Type II audit costs $20,000-50,000. Required only if large school districts or enterprise customers demand it. Revisit at 50+ customers.
3.3 Data Privacy — CCPA & GDPR
The platform stores customer PII including names, addresses, contact details, and payment references. Privacy obligations apply based on customer location.
Regulation
Applies
Requirements
CCPA
Yes
California Consumer Privacy Act — applies to any store with California customers. Right to deletion, data access requests, privacy policy required.
GDPR
Unlikely
EU General Data Protection Regulation — applies only if EU customers. US music stores unlikely. Monitor if international expansion.
Required Privacy Controls
-
Privacy policy published and linked from all customer-facing surfaces
-
Data retention policy — define how long customer data is kept after account closure
-
Right to deletion — PII nullification on customer records (append-only event sourcing uses nullification not deletion)
-
Data access requests — ability to export all data for a customer on request
-
Breach notification procedure — documented and tested
-
Data processing agreements available for enterprise customers
3.4 Sales Tax on SaaS Fees
Selling SaaS subscriptions nationally creates sales tax nexus obligations in states where revenue thresholds are crossed. This applies to Lunarfront Tech LLC's own subscription fees — separate from sales tax the stores collect from their customers.
-
Economic nexus thresholds vary by state — typically $100,000 revenue or 200 transactions
-
Integrate TaxJar or Avalara for automated sales tax calculation on subscription invoices
-
Register for sales tax collection in states where thresholds are crossed
-
Texas (home state) requires registration from day one
-
Revisit quarterly as revenue grows into new states
3.5 Music Industry — No Specific Certification Required
There are no industry-specific software certifications required to sell POS software to music retailers. NAMM (National Association of Music Merchants) is the primary trade organization — membership and NAMM show presence adds credibility but is not a certification or requirement.
3.6 Business Entity
-
Lunarfront Tech LLC registered in Texas — covers software sales nationally
-
Standard commercial software license agreement required for all customers
-
Terms of service and privacy policy required before account activation
-
Self-hosted customers sign a separate perpetual license agreement
4. Pricing
4.1 SaaS Subscription Pricing
Plan
Price
Includes
Starter
$149/mo
POS + inventory + customers + Stripe Terminal + basic reporting + cash drawer + email support
Standard
$249/mo
Everything in Starter + rentals + rent-to-own + lessons + scheduling + repairs + QuickBooks export + invoice printing + iOS convention app
Most stores
Professional
$349/mo
Everything in Standard + batch repairs + delivery tracking + school management + advanced accounting + multi-location + API access + priority support
SaaS Add-Ons
Add-On
Price
Notes
Additional location
+$99/mo
Per additional store location
Priority support upgrade
+$49/mo
4hr response + emergency POS-down line
AIM data migration
$500-1,500
One-time — based on data volume and complexity
Onboarding & training
$300
One-time — 3hr remote session covering all modules
4.2 Self-Hosted Licensing
License
Price
Includes
Standard License
$2,500
Perpetual license — Standard feature set. Software works indefinitely.
Professional License
$4,500
Perpetual license — Professional feature set including batch repairs, delivery, school management.
Annual Maintenance
20% of license
Updates + standard email support. Without maintenance, software still runs but receives no updates after year 1.
Self-Hosted Add-Ons
Add-On
Price
Notes
Cloud backup
$29/mo
Encrypted backups to vendor S3 — disaster recovery
Priority support
$49/mo
4hr response + emergency POS-down line
AIM data migration
$500-1,500
One-time — remote migration assistance
Remote installation
$250
One-time — vendor installs and configures remotely
Onboarding & training
$300
One-time — 3hr remote training session
4.3 Unit Economics (SaaS)
Customers
Avg Revenue/Mo
MRR
AWS Est.
10
$249
$2,490
~$200
25
$280
$7,000
~$400
50
$290
$14,500
~$700
100
$300
$30,000
~$1,200
Average revenue per customer increases as stores upgrade plans and add locations. AWS costs scale sublinearly due to multi-tenant efficiency. Net margin at scale is 90%+ before support labor.
4.4 Launch Pricing Strategy
First 10 customers should receive significantly discounted or free access in exchange for being design partners. These stores will surface edge cases, validate workflows, and serve as reference customers for future sales.
-
Beta program: free for 6 months, then standard pricing
-
Beta customers get lifetime 20% discount as reference customer reward
-
In exchange: monthly feedback calls, permission to use as case study, referral introductions
-
Target beta customers: stores currently on AIM with pain around cloud access, modern hardware, or school batch repairs
5. Support Model
5.1 Support Philosophy
The best support interaction is one that never needs to happen. Investment in self-service documentation, resilient software design, and proactive monitoring reduces support volume. When support is needed, response time and resolution quality matter most — a POS system is critical business infrastructure.
5.2 Support Tiers by Plan
Plan
Channel
Response SLA
Notes
Starter
Email only
48 business hours
Acknowledged at signup — appropriate for low-volume stores
Standard
Email + ticket
Next business day
Business hours: Mon-Fri 8am-6pm CT
Professional
Priority queue
4 business hours
Emergency POS-down line for payment processing failures only
Self-hosted + maintenance
Email + ticket
Next business day
Hardware issues are customer's responsibility
Priority support add-on
Priority queue
4 business hours
Available as add-on for any plan
5.3 Emergency POS-Down Definition
Emergency support (outside business hours) is reserved for true POS-down situations only — defined as the store being completely unable to process any payments. This is the highest-severity scenario.
Scenario
Emergency?
Response
Platform completely unreachable
YES
Emergency line — target 1hr response
Card payments failing, cash works
NO
Next business day — workaround exists
Specific feature not working
NO
Standard SLA — not a POS-down situation
Report not generating
NO
Standard SLA
Self-hosted server down
NO
Customer's infrastructure — guide to troubleshooting provided
5.4 Self-Service Infrastructure
Self-service resources reduce support volume and empower stores to resolve common issues independently. All self-service content is built and maintained as part of the product.
Knowledge Base
-
Searchable help articles for every feature and workflow
-
Step-by-step guides with screenshots for all major operations
-
Troubleshooting guides for common error conditions
-
AIM migration guide — specific help for stores transitioning from AIM
-
Hosted at help.platform.com — accessible without logging in
In-App Help
-
Contextual help tooltips on complex fields and settings
-
Inline error messages that explain what went wrong and how to fix it — never just error codes
-
First-run guided setup wizard for new accounts
-
Search bar in admin panel searches knowledge base without leaving the app
Video Library
-
Short (3-5 minute) walkthrough videos for each major module
-
Onboarding series: first week, first month
-
Hosted on YouTube (unlisted) — embedded in knowledge base
Status Page
-
Public status page at status.platform.com (statuspage.io or similar)
-
Real-time uptime for all platform components
-
Incident history and postmortems
-
Email/SMS subscribe for outage notifications
-
Stores check status page before submitting support tickets — reduces 'is it down?' tickets
5.5 Proactive Monitoring
Catching issues before customers report them is the most effective support strategy. Automated monitoring alerts the vendor immediately when problems occur.
-
PagerDuty or OpsGenie — on-call alerting for platform incidents
-
Synthetic monitoring — automated transaction tests run every 5 minutes against production
-
Error rate alerts — spike in API errors triggers immediate investigation
-
Stripe webhook failure alerts — missed webhooks flagged within minutes
-
Database performance monitoring — slow queries identified before they cause user impact
-
Self-hosted: optional telemetry (opt-in) sends health metrics to vendor for proactive support
5.6 Scaling Support as Customer Base Grows
Stage
Support Approach
0-20 customers
Solo — founder handles all support. Invest heavily in self-service documentation to reduce volume. Target < 2 tickets per customer per month.
20-50 customers
Hire part-time support contractor with music retail background. Train on platform. Handle tier 1 tickets (how-to questions, basic troubleshooting). Founder handles tier 2 (bugs, integrations).
50-100 customers
Full-time support hire or VAR (value-added reseller) partnerships. VARs handle implementation and support for a region in exchange for revenue share (typically 20-30%).
100+ customers
Dedicated support team. Community forum where experienced stores help newer ones. Formal partner program for VARs and consultants.
5.7 VAR / Partner Program
Value-added resellers are consultants or IT companies that sell, implement, and support the platform on behalf of end customers. This is how many niche B2B software companies scale support without hiring — the VAR takes on the customer relationship in exchange for a cut of recurring revenue.
-
VAR sells the platform to their existing music store clients
-
VAR handles implementation, data migration, training, and tier 1 support
-
VAR receives 20-25% of monthly subscription revenue for life of customer
-
Vendor provides VAR training, certification, and technical escalation support
-
NAMM show is the natural place to recruit VARs — music industry consultants attend
-
Target: 3-5 regional VARs covering US geography within first 2 years
6. Go-to-Market Notes
6.1 Competitive Positioning
Feature
This Platform
AIM
Music Shop 360
Cloud-based
Yes
No
Yes
Self-hosted option
Yes
Yes
No
Offline POS mode
Yes
Yes
Limited
Convention iOS app
Yes
No
No
Full rent-to-own
Yes
Yes
Partial
Family billing
Yes
Limited
Limited
Batch school repairs
Yes
No
Partial
Delivery tracking
Yes
No
No
Billing date mgmt
Yes
Limited
Limited
QB export
Yes
Add-on
Unknown
AIM migration tool
Yes
N/A
No
6.2 Launch Sequence
-
Phase 1: Build core platform with one beta store — validate all workflows against real operations
-
Phase 2: Onboard 5-10 beta stores at no cost — gather feedback, fix edge cases, build case studies
-
Phase 3: Launch at NAMM or via NAMM member outreach — music retail community is tight-knit
-
Phase 4: Recruit first VAR partner — ideally someone already consulting for music stores
-
Phase 5: Paid marketing — Google Ads targeting 'AIM POS alternative', 'music store software'
6.3 AIM Migration as a Sales Tool
The AIM installed base is the primary target market. Stores that have been on AIM for 10+ years are the most likely to be feeling the pain of outdated infrastructure and are actively looking for alternatives. The AIM data migration tool is a meaningful competitive differentiator — it reduces switching cost and anxiety.
-
'We migrate your AIM data' is a headline feature in sales materials
-
Migration tool handles customers, inventory, rentals, lessons, repair history
-
Parallel operation period means zero risk of data loss during cutover
-
Target stores that have complained publicly about AIM (review sites, forums, NAMM community)