Files
lunarfront-app/planning/13_Deployment_Compliance_Pricing_Support.md
Ryan Moon 5f8726ee4e Add planning documents for Forte music store platform
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
2026-03-27 14:51:23 -05:00

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)