Technical Architecture (Proposed)

This is a starting proposal for when build begins — intentionally boring/proven technology choices, consistent with this org's existing stack (see the CRM platform at crm.dmll.in for precedent: Node/Express + React + MySQL, Apache-fronted). Revisit once real requirements (team size, timeline) are locked in.

High-level shape

┌─────────────┐     ┌──────────────────┐     ┌───────────────┐
│  React SPA   │────▶│  Node/Express API │────▶│  MySQL          │
│  (frontend)  │     │  (REST, JWT auth)  │     │  (primary data) │
└─────────────┘     └──────────────────┘     └───────────────┘
                             │
                 ┌───────────┼────────────┐
                 ▼           ▼            ▼
          ┌───────────┐ ┌──────────┐ ┌──────────────┐
          │ Payment    │ │ Object    │ │ Notification  │
          │ Gateway    │ │ Storage   │ │ (email/SMS/   │
          │ (Razorpay/ │ │ (media/   │ │  in-app push) │
          │ Cashfree)  │ │ portfolio)│ │               │
          └───────────┘ └──────────┘ └──────────────┘

Core services/modules

• Auth: JWT-based session auth (matches existing CRM pattern), with OAuth options for social account linking (Instagram/YouTube/etc. — separate from login auth, used for verification per 07-trust-safety.md).
• User/Profile service: creator and hirer profiles, verification state, ratings.
• Gig/Campaign service: the lifecycle state machine from 05-campaign-lifecycle.md — this is the transactional core and deserves the most design care (event-sourced or at minimum a well-audited state-transition table, since disputes will need to reconstruct exact history).
• Messaging service: per-gig scoped chat, ideally with a lightweight real-time layer (WebSocket) for live messaging rather than polling.
• Payments/Escrow service: wraps the payment gateway, owns escrow-state bookkeeping — this must be built with the same rigor as financial ledger software (double-entry-style internal accounting, not just "update a balance column") given real money and dispute/audit requirements.
• Search/Discovery service: v1 can run directly against MySQL with well-designed indexes and filtered queries for the scale expected at launch; a dedicated search engine (Elasticsearch/Meilisearch) is a Phase 2 upgrade once query complexity or catalog size justifies it — do not over-engineer this on day one.
• Notification service: email (transactional — gig events, payment events), SMS (India: high open-rate channel, worth it for time-sensitive events like deadline reminders), and in-app notifications (reuse the pattern already proven in the CRM's notification system on this same infra).
• Admin service: the tooling from 04-features-admin.md — can be a separate internal-only frontend, doesn't need the polish of the main product, but does need solid access control (admin actions are sensitive).

Data model sketch (core entities, not exhaustive)

• users (base account: email, auth, account_type flags for creator/hirer/both)
• creator_profiles (1:1 with users where creator flag set)
• hirer_profiles / businesses (1:1 or 1:many if team seats — a business can have multiple user members)
• social_accounts (linked platform accounts per creator, with verification state)
• rate_cards (per-creator deliverable-type pricing)
• gigs (the posted brief/listing)
• gig_applications / offers (pitches and direct offers)
• engagements (the hired instance of a gig — the actual state-machine entity from 05-campaign-lifecycle.md)
• milestones (for milestone-based engagements)
• deliverables (submitted content/links against an engagement)
• messages (scoped per engagement)
• transactions / escrow_ledger (financial ledger — treat as append-only/immutable for audit integrity)
• reviews (bidirectional, per completed engagement)
• disputes (case records, linked to engagement + full evidence snapshot)

Integration points requiring early decisions

1. Payment gateway (Razorpay/Cashfree/PayU) — determines escrow implementation details (some gateways have native marketplace/escrow/split-payment products, e.g., Razorpay Route — strongly prefer using a gateway's native marketplace payment product over hand-rolling escrow logic if one fits, to reduce compliance/PCI burden).
2. Social platform APIs — Instagram Graph API (business accounts only, requires app review), YouTube Data API (more open), TikTok API (restrictive). v1 should not depend on deep API access being approved before launch — design verification (07-trust-safety.md) to degrade gracefully to manual/self-reported methods.
3. Object storage for portfolio media/deliverables — S3-compatible storage (matches common patterns), with CDN in front for profile/portfolio media that gets repeatedly viewed.
4. SMS/Email provider — transactional email (existing org pattern uses Resend per other DMCoder-managed services) + an SMS provider for India (MSG91/Twilio).

Hosting note (this environment)

Given DNS for hireforgig.dmll.in already resolves to this host's infrastructure (same pattern as crm.dmll.in, my2ndbrain.dmll.in), the natural path is: Apache-fronted, Node/Express API + pm2, MySQL database, React SPA build served as static files — identical operational pattern to the CRM platform already running here, which keeps ops/monitoring/deploy tooling consistent across this org's projects.

Non-functional requirements worth calling out early

• Financial data integrity is the highest-stakes requirement in this entire system — escrow/ledger code needs review rigor beyond the rest of the app.
• Audit logging on every state transition and every admin action (disputes will be litigated against this data).
• Media storage costs scale with creator portfolio uploads — plan storage tiering/limits from day one rather than retrofitting.