AI Platform Recommendations

Where AI Adds Value

Architecture Recommendations

1. Event-Driven Architecture

Replace Google Pub/Sub + eval()-based cron with a proper workflow orchestration system:

• Consider: Inngest, Temporal, or a serverless event bus
• Benefits: Typed events, automatic retries, observability, no eval() code injection risk
• Pattern: Domain events (InvoiceCreated, BookingConfirmed, MemberOnboarded) triggering typed handlers

2. Unified Authentication Layer

Replace the mix of sessions, API keys, and JWT tokens:

• Consider: OAuth 2.0 / OIDC with a provider like Auth0, Clerk, or Supabase Auth
• Pattern: Single auth middleware, role-based access control, proper token verification
• Critical: Always use jwt.verify(), never jwt.decode()

3. Service Boundaries

The current monorepo shares models directly via file paths. For the replacement:

• Option A: Modular monolith with clear domain boundaries and shared nothing between modules
• Option B: Microservices with API gateway, each service owning its data
• Key: The wallet/ledger, booking, and invoicing domains should be independently deployable and testable

4. Explicit Service Layer

Extract business logic from Mongoose hooks into explicit, testable service functions:

// Instead of logic in model hooks:
class LedgerService {
  async createDebit(params) {
    const currency = await this.deriveCurrency(params);
    await this.validateOrganisation(params.organisationId);
    await this.validateSufficientFunds(params);
    const splits = this.calculateWalletSplits(params);
    return this.ledgerRepo.create({ ...params, currency, splits });
  }
}

5. Accounting Adapter Pattern

Xero is deeply coupled throughout the current codebase. Abstract behind an adapter:

// Accounting adapter interface
interface AccountingProvider {
  createInvoice(data: InvoiceData): Promise<ExternalInvoice>;
  recordPayment(data: PaymentData): Promise<ExternalPayment>;
  syncContact(data: ContactData): Promise<ExternalContact>;
}

// Implementations
class XeroProvider implements AccountingProvider { ... }
class QuickBooksProvider implements AccountingProvider { ... }
class SageProvider implements AccountingProvider { ... }

This allows supporting multiple accounting systems and makes testing far simpler.

6. Double-Entry Accounting

The current wallet/ledger system is the most complex piece. Redesign with proper double-entry principles:

• Every transaction creates both a debit and credit entry
• Balance is always derivable from the ledger (no cached Balance model needed)
• Immutable ledger entries — corrections via reversing entries, not updates
• Clear separation of concerns: the ledger records facts, business rules live in the service layer

Technical Debt to Avoid Repeating

Data Migration Considerations

Key Challenges

• Heavily denormalised MongoDB schema — computed fields in hooks mean the stored data doesn't always reflect the "truth". Plan for data transformation, not lift-and-shift.
• Wallet/Ledger system — 6 transaction types, priority-based multi-wallet deduction, overflow logic, and reserve-to-debit conversion. This is the hardest piece to migrate correctly.
• Xero IDs everywhere — many models store Xero-specific IDs (xero_id, xero_invoice_id, xero_tenant_id). These need mapping to the new accounting adapter layer.
• Encrypted data — PINs, passwords, and session data encrypted with deprecated cipher. Must decrypt with old method and re-encrypt with new.
• Multi-instance federation — some data lives across multiple WSM instances. Migration needs to handle cross-instance references.

Migration Strategy

1. Phase 1: Read-only access to legacy data via API adapter. New platform reads from old MongoDB.
2. Phase 2: Dual-write period. New operations write to both systems.
3. Phase 3: Full migration. Historical data transformed and loaded into new schema.
4. Phase 4: Legacy system decommissioned.

Suggested Technology Stack