title: description: published: true date: 2026-02-24T16:56:07.887Z tags: editor: markdown dateCreated: 2026-02-23T15:24:29.506Z

Vision and Goals

Business Objectives

Primary Objective

Build a commercially viable SaaS platform that becomes the leading European solution for sports club and fitness studio management, generating recurring subscription revenue through a modular pricing model.

Revenue Model

All prices net (plus applicable VAT).

No zero-euro strategy -- every user must have a billable account to ensure reachability and commitment. Even the Starter tier at EUR 0.99/month validates payment credentials, ensures the user has a real identity, and creates a commercial relationship from day one.

Trial Studio

Interested parties can create a Trial Studio to experiment with the platform before committing to a paid plan. The Trial Studio provides a risk-free evaluation environment with the following constraints:

• No payment method required -- trial creation requires only an email address and organization name
• Full feature access -- all features of the Professional tier are available for evaluation, including dashboards, member management, billing configuration, and resource booking
• No outbound messaging -- Trial Studios cannot send messages (email, push notifications, SMS). This prevents abuse (spam), protects the platform's sender reputation, and ensures only paying customers use communication infrastructure
• Automatic deletion after 30 days -- Trial Studios and all associated data are permanently deleted after 30 days with no option to extend. Users receive reminder notifications at day 20 and day 27
• Conversion path -- at any point during the trial, the user can convert to a Starter plan (EUR 0.99/month) by adding a payment method. All data is preserved on conversion
• Sample data included -- Trial Studios are pre-populated with realistic sample data (10 demo members, 2 membership plans, sample transactions) so users can explore immediately without manual setup
• Watermark -- all screens display a subtle "Trial Studio -- X days remaining" banner to maintain awareness of the trial status

The Trial Studio replaces the traditional freemium model. Instead of a permanently free tier that attracts non-serious users and creates support burden, the Trial Studio offers a time-limited, full-featured evaluation that drives conversion to the Starter plan.

Growth Targets

• Year 1: 100 paying clients (Phase 1 validation), product-market fit confirmed, aggressive global outreach via marketing automation (email sequences, content marketing, trade show pipeline) with DACH as initial focus
• Year 2: 500+ clients across Europe, positive unit economics, automated lead nurturing driving 60%+ of new sign-ups
• Year 3: 2,000+ clients, expansion into Benelux, Nordics, Southern Europe, first non-EU markets
• Year 5: 10,000+ clients, marketplace revenue, partner ecosystem established

Marketing automation is the primary acquisition engine -- globally, with DACH as initial focus. Automated drip campaigns, SEO-optimized content in 24 EU languages, and self-service Trial Studio sign-up must drive the majority of leads by Year 2. The accessible pricing (Starter at EUR 0.99/month) keeps the cost barrier low and shifts the conversion bottleneck to product experience, not price negotiation. While DACH provides the initial customer base and product-market fit validation, the platform's multilingual architecture enables global reach from day one.

Distribution Channels

1. Direct sales -- Outbound to clubs and studios in the DACH region
2. Partner network -- Resellers, consultants, sports associations
3. White-label -- OEM licensing to franchise networks and industry partners
4. Marketplace -- Self-service sign-up via website with Trial Studio onboarding
5. Referral program -- Existing clients incentivized to recommend the platform
6. Trade shows -- FIBO, IHRSA Europe, national sports association conferences

Technical Goals

Cross-Platform Delivery

The platform must be accessible on every device a sports organization uses, from the front desk PC to a trainer's smartphone on the gym floor.

Internationalization (I18N) -- EU Multilingual from Day One

The platform supports all 24 official languages of the European Union from the initial release. This is a strategic decision: sports clubs and fitness studios operate across the EU single market, and members expect to interact with the platform in their native language. Rather than launching with a handful of languages and retrofitting later (which always results in inconsistent coverage), Membership treats full EU language support as a baseline requirement.

Supported Languages (24 EU Official Languages)

Base Language

English (en) is the base language for all translation files. All translation keys are authored in English first, and all other 23 languages are translated from the English source. The English version serves as the fallback when a translation is missing in any other language.

Translation File Strategy

The ARB files for Flutter follow this naming convention: - app_en.arb -- English (base, contains descriptions and placeholders) - app_de.arb -- German - app_fr.arb -- French - ... one file per supported locale

The Spring Boot properties files follow: - messages.properties -- English (default fallback) - messages_de.properties -- German - messages_fr.properties -- French - ... one file per supported locale

Translation Management

A dedicated translation management workflow ensures consistent quality:

1. Key creation: Developers add new keys to app_en.arb (frontend) or messages.properties (backend) with descriptive names following the convention <feature>.<screen>.<element> (e.g., member.form.firstNameLabel, payment.status.settled)
2. Translation export: ARB and properties files are exported to a translation management system (TMS) such as Crowdin, Lokalise, or Phrase
3. Professional translation: All 23 non-English languages are translated by professional translators with sports/fitness domain knowledge
4. Review: Native speaker reviewers validate translations in context (screenshots provided)
5. Import: Translated files are imported back into the codebase via CI/CD pipeline
6. Validation: Automated checks verify all keys exist in all 24 language files, no placeholders are missing, and pluralization rules are correct

Locale Negotiation

Locale is determined through a cascade:

1. User preference (stored in user profile, highest priority)
2. Browser/device locale (detected from Accept-Language header or Platform.localeName)
3. Entity default locale (configured per organization)
4. Fallback: English (en)

On the frontend, the Localizations.localeOf(context) resolves the active locale. On the backend, LocaleContextHolder.getLocale() provides the request-scoped locale, set by a LocaleChangeInterceptor that reads the Accept-Language header or a lang query parameter.

Non-EU Languages for EU Residents

Large non-EU citizen populations living in EU countries require their native languages for member-facing content. These are not hypothetical future markets -- they are real members walking into studios and clubs today. For example, approximately 3 million Turkish speakers live in Germany, ~1.5 million Arabic speakers reside across the EU, and significant Russian, Ukrainian, Serbian, and Albanian communities exist throughout Western Europe. Providing these languages for member-facing screens (profile, booking, check-in, payment history) is essential for inclusivity and market reach.

Priority non-EU languages (Phase 2):

These languages are added to the frontend ARB files and backend message bundles alongside the 24 EU languages, bringing the total to 32 supported languages.

RTL Support

Required -- Arabic and other RTL languages are needed for non-EU resident populations in the EU, even without expansion into RTL-dominant countries. The frontend must support bidirectional text (BiDi) from v1.0.

The Flutter framework provides built-in RTL support via the Directionality widget. All layouts must be tested in both LTR and RTL modes. Specific requirements: - Mirrored layouts: Navigation rails, drawers, and action buttons must mirror for RTL locales - Text alignment: Form labels, input fields, and body text must respect text direction - Icon placement: Directional icons (arrows, chevrons) must flip for RTL - Mixed content: BiDi text handling for screens displaying both LTR and RTL content (e.g., an Arabic member name alongside a German address) - Testing: RTL layout testing is included in the QA checklist for every screen

Supported Currencies (16)

The platform supports 16 currencies covering the EU economic area, key global currencies, and currencies matching the supported non-EU languages. Currency support parallels the language strategy: just as every EU official language is supported from v1.0, every EU currency is supported from v1.0 alongside the currencies needed for non-EU resident populations.

EU Currencies (8):

Non-EU Currencies (8):

Base currency: EUR is the platform's base currency. All subscription prices are quoted in EUR. Non-EUR currencies use daily ECB reference rates for display. Billing is always in the entity's configured currency. Multi-currency billing (invoicing in a member's preferred currency) is a v2.0 feature for Professional+ tiers.

Date, Number, and Currency Formatting

All date, number, and currency values are formatted according to the active locale using the intl package (Flutter) and java.text / java.time formatters (Spring Boot):

Important: Monetary values are always stored and transmitted in a locale-independent format (plain decimal numbers). Locale-specific formatting is applied only at the presentation layer (UI, PDF, email).

Address Formatting

Address formats vary significantly across EU countries. The platform uses a per-country address template:

Templates are stored in configuration and can be overridden per entity.

Translation Key Conventions

Keys follow a hierarchical dot notation:

# Pattern: <module>.<screen|component>.<element>
member.list.title = Members
member.list.searchPlaceholder = Search by name, email, or member number...
member.form.firstNameLabel = First Name
member.form.firstNameRequired = First name is required
member.detail.contractSection = Active Membership
payment.status.new = Not yet processed
payment.status.paid = Paid
payment.status.settled = Settled
common.action.save = Save
common.action.cancel = Cancel
common.action.delete = Delete
common.validation.required = This field is required
common.validation.invalidEmail = Please enter a valid email address

Pluralization uses ICU message format:

member.list.resultCount = {count, plural, =0{No members found} =1{1 member found} other{{count} members found}}

Compliance and Security

Multi-Tenant Architecture

Every aspect of the platform operates in a multi-tenant model where a single deployment serves all clients with complete data isolation:

• Database isolation: Schema-per-tenant or row-level security (configurable per deployment size)
• Configuration isolation: Each tenant has independent settings, branding, payment configuration, and workflow rules
• White-label support: Custom domain, logo, color scheme, email sender identity, app store listing (for enterprise tier)

Modular Architecture

The platform is composed of independently deployable packages that can be activated per tenant:

• Each package can be enabled/disabled per tenant without redeployment
• Inter-package communication via internal event bus (not direct coupling)
• Package-level feature flags for granular control during rollout

API-First Design

Every feature in the platform is accessible through a public API before any UI is built:

Microservice Readiness

The initial deployment is a modular monolith for simplicity with a 4-person team, but the architecture is designed for extraction into microservices as scale demands:

• Domain boundaries align with the 8 packages
• Asynchronous messaging (RabbitMQ/Kafka) between domains from day one
• No shared database tables across domain boundaries
• Each domain owns its data and exposes it only through APIs

Cloud and CDN

• Primary hosting: Hetzner Cloud (Nuremberg, nbg1) -- committed provider, EU-based, GDPR-compliant, cost-effective
• CDN: Static assets, media files, and generated documents served via edge network
• Offline mode: Service worker caching for critical workflows (check-in, attendance, basic member lookup)
• Auto-scaling: Horizontal scaling based on tenant activity patterns (peak hours at studios)

Non-Functional Requirements

Scalability

Offline Mode

Sports facilities often have poor connectivity (basements, rural areas, outdoor fields). Critical workflows must function without internet:

• Check-in/attendance: Local cache of member list, sync when online
• Payment recording: Queue transactions offline, process when connected
• Course attendance: Mark attendance locally, sync to server
• Member lookup: Basic profile data cached for authorized staff

Accessibility

• WCAG 2.1 AA compliance for all web interfaces
• Screen reader compatibility (ARIA labels, semantic HTML)
• Keyboard-only navigation for all workflows
• Minimum contrast ratio 4.5:1 for text, 3:1 for large text
• Touch targets minimum 44x44 pixels on mobile
• No information conveyed by color alone

Performance

• First contentful paint: target < 0.2 seconds, absolute maximum < 1.5 seconds (any page exceeding 1.5s is a blocking bug)
• Time to interactive: target < 0.5 seconds, absolute maximum < 2.0 seconds
• Lighthouse score > 90 (Performance, Accessibility, Best Practices)
• Bundle size < 500 KB (initial load), code splitting for feature packages
• Flutter Web compiled to WASM for near-native execution speed

Design Philosophy: "Effortless UX"

The primary users of Membership are not software professionals. They are volunteer club administrators who log in twice a month, studio managers juggling multiple tasks between client sessions, trainers checking their phone between sets, and members who just want to book a class. The design philosophy is ruthlessly focused on reducing cognitive load.

Principles

1. Goal and Task Orientation

Every screen answers one question: "What is the user trying to accomplish right now?" Navigation, layout, and information hierarchy are organized around tasks (e.g., "Add a new member", "Export SEPA file"), not around data structures (e.g., "Consumer entity list").

2. Guided Workflows

Multi-step processes use wizard-style flows with clear progress indicators, contextual validation, and sensible defaults. A club admin creating their first membership plan should be able to complete it in under 3 minutes without reading documentation.

3. Simple Language

No technical jargon in the UI. "Members" not "Consumers", "Payment" not "Transaction", "Export bank file" not "Generate SEPA XML". Error messages explain what happened and what to do next, in plain language.

4. Contextual Help

Every complex screen includes inline help text, tooltips on non-obvious fields, and links to relevant documentation. First-time users see onboarding tooltips that experienced users can dismiss permanently.

5. Role-Based Simplification

Each role sees only what they need:

6. Error-Friendliness

• Undo for destructive actions (with grace period)
• Confirmation dialogs only for truly irreversible operations
• Auto-save for forms and drafts
• Clear recovery paths when something goes wrong

7. Automation and Smart Suggestions

The system should anticipate user needs:

• Auto-suggest membership plans based on member age and preferences
• Pre-fill bank account details from IBAN validation
• Suggest payment reminders when invoices are overdue
• Recommend course times based on historical attendance patterns
• Flag potential data quality issues (duplicate members, expired contracts)

8. Vibe Design

The visual design evokes energy, community, and professionalism:

• Clean, modern aesthetic with generous whitespace
• Sport-inspired accent colors (configurable per tenant brand)
• Motion design that feels responsive without being distracting
• Dark mode support for evening/gym-floor use
• Consistent component library ensuring visual coherence across all packages

Success Metrics

Commercial Metrics

Technical Metrics

User Experience Metrics