Skip to main content

CODITECT-PLATFORM Customer Discovery Questionnaire

Version: 1.0.0 Date: January 1, 2026 Purpose: Foundational architecture discovery to prevent future refactoring Brand Context: Future brand = FUTUREPRISE

How to Use This Document​

  1. Answer questions sequentially - one at a time, in order
  2. Each answer informs data models - we'll design schemas as you respond
  3. Priority levels indicate timing:
    • P0 (Foundation) - Must have before pilot launch
    • P1 (Phase 2) - Post-pilot, pre-scale
    • P2 (Phase 3) - Enterprise features
  4. Reusable templates - Your answers become onboarding templates for future customers

Domain 1: Organization Hierarchy & Structure​

Goal: Define how organizations, subsidiaries, teams, and entities relate to each other

Q1.1: Organization Types (P0 - Foundation)​

Question: What types of organizations will CODITECT serve?

  • Individuals (solopreneurs, freelancers)
  • Teams (5-20 people, single legal entity)
  • Small Companies (20-100 employees, single entity)
  • Mid-Market (100-1000 employees, possibly multi-entity)
  • Enterprise (1000+ employees, multi-subsidiary, multi-country)

Data Model Impact:

  • Single-tenant vs multi-tenant architecture
  • Organization hierarchy depth
  • Billing complexity

Your Answer:

[Fill in which types you want to support]

Q1.2: Subsidiary Structure (P1 - Phase 2)​

Question: Do you need to support parent-subsidiary relationships like NetSuite?

Example:

  • Parent: AZ1.AI INC (US)
    • Subsidiary: AZ1 Europe GmbH (Germany)
    • Subsidiary: AZ1 APAC Pte Ltd (Singapore)

Considerations:

  • Each subsidiary = separate legal entity
  • Separate books, tax reporting, compliance
  • Possible shared users/services

Options:

  • A) No - Single legal entity per tenant
  • B) Yes, but limited (2-3 subsidiaries max)
  • C) Yes, NetSuite-class (unlimited hierarchy depth)

Data Model Impact:

  • Subsidiary table with parent_id self-reference
  • Financial data segregation by subsidiary
  • Consolidated vs standalone reporting

Your Answer:

[Choose A, B, or C + explanation]

Q1.3: Cross-Entity User Access (P1 - Phase 2)​

Question: Should a single user be able to access multiple subsidiaries/entities?

Example:

  • Jane Doe (CFO) needs access to:
    • AZ1.AI INC (US) - Full admin
    • AZ1 Europe GmbH - Read-only financials
    • AZ1 APAC Pte Ltd - No access

Options:

  • A) No - Users belong to one entity only
  • B) Yes - Same permissions across all entities
  • C) Yes - Different roles per entity (like NetSuite)

Data Model Impact:

  • If C: UserEntityRole table (user_id, entity_id, role)
  • Context switching in UI
  • Audit logging per entity

Your Answer:

[Choose A, B, or C]

Q1.4: Team Structure (P0 - Foundation)​

Question: How do teams fit within organizations?

Current Model:

  • Organization (Tenant)
    • Team (many)
      • TeamMembership (user + role)
    • Project (many)

Validation Questions:

  • A) Can a user belong to multiple teams? (Yes/No)
  • B) Are projects owned by teams or organizations? (Team/Org/Both)
  • C) Do teams need hierarchy (parent teams)? (Yes/No)

Data Model Impact:

  • If A=Yes: Many-to-many TeamMembership (already implemented ✅)
  • If B=Team: team_id foreign key on Project
  • If C=Yes: parent_team_id on Team table

Your Answer:

A: [Yes/No]
B: [Team/Org/Both]
C: [Yes/No]

Domain 2: Geographic & Jurisdictional Requirements​

Goal: Understand data residency, compliance boundaries, multi-country operations

Q2.1: Data Residency (P1 - Phase 2)​

Question: Do you need to store customer data in specific geographic regions?

Example:

  • EU customers → EU data centers (GDPR)
  • China customers → China data centers (PIPL)
  • US customers → US data centers

Options:

  • A) No - Single global region (e.g., us-central1)
  • B) Yes - Multi-region deployment (US, EU, APAC)
  • C) Yes - Per-customer region selection

Data Model Impact:

  • If B/C: data_region field on Tenant
  • Multi-region database setup (Spanner or regional PostgreSQL)
  • Cross-region routing logic

Your Answer:

[Choose A, B, or C]

Q2.2: Multi-Currency (P1 - Phase 2)​

Question: Do you need to support transactions in multiple currencies?

Example:

  • US company bills EU customer in EUR
  • Same company pays contractor in GBP
  • Financial reports need multi-currency consolidation

Options:

  • A) No - USD only
  • B) Yes - Display currency (convert at runtime)
  • C) Yes - Transaction currency (store original + converted)

Data Model Impact:

  • If C: currency_code, exchange_rate, base_amount on financial records
  • Currency table with exchange rates
  • Base currency per subsidiary/org

Your Answer:

[Choose A, B, or C]
If B/C: List primary currencies needed

Q2.3: Tax Jurisdiction (P2 - Phase 3)​

Question: Do you need to handle different tax rates by jurisdiction?

Example:

  • California sales tax: 7.25%
  • Texas sales tax: 6.25%
  • EU VAT: varies by country (19-27%)

Options:

  • A) No - Flat rate or tax-exempt
  • B) Yes - US state sales tax
  • C) Yes - Global VAT/GST support

Data Model Impact:

  • TaxJurisdiction table (code, rate, rules)
  • tax_jurisdiction_id on invoices/subscriptions
  • Tax calculation engine

Your Answer:

[Choose A, B, or C]

Domain 3: User Identity & Access Management​

Goal: Define authentication, authorization, and profile management

Q3.1: Authentication Methods (P0 - Foundation)​

Question: What authentication methods should be supported?

Options:

  • Email + Password (basic)
  • OAuth 2.0 (Google, GitHub, Microsoft)
  • SAML/SSO (enterprise single sign-on)
  • Magic Links (passwordless email)
  • Multi-Factor Authentication (MFA)

Data Model Impact:

  • UserAuth table: provider, provider_user_id, credentials
  • OAuth token storage (encrypted)
  • MFA secrets storage (TOTP)

Your Answer:

[Check all that apply + priority]

Q3.2: User Profile Structure (P0 - Foundation)​

Question: What user profile fields are required?

Current Model:

class User:
    email: str
    first_name: str | None
    last_name: str | None
    profile_picture_url: str | None
    system_role: SystemRole  # SUPER_ADMIN, TENANT_ADMIN, MEMBER

Validation:

  • A) Is first_name/last_name sufficient, or need full_name + display_name?
  • B) Need phone number? (For MFA, notifications)
  • C) Need timezone? (For scheduling, datetime display)
  • D) Need locale/language preference?

Data Model Impact:

  • Additional columns on User table
  • Profile completeness validation

Your Answer:

A: [first_name/last_name OR full_name/display_name]
B: [Yes/No - If Yes, required or optional?]
C: [Yes/No]
D: [Yes/No - If Yes, list locales needed]

Q3.3: Role-Based Access Control (P0 - Foundation)​

Question: What permission granularity do you need?

Current Model:

SystemRole: SUPER_ADMIN | TENANT_ADMIN | MEMBER
TenantRole: OWNER | ADMIN | MEMBER | VIEWER

Options:

  • A) Current model sufficient (4 system + 4 tenant roles)
  • B) Need custom roles per tenant
  • C) Need permission-level control (create, read, update, delete per resource)

Example (Option C):

Role: "Billing Manager"
Permissions:
  - subscriptions: read, update
  - invoices: read, create
  - projects: read
  - users: no access

Data Model Impact:

  • If B: CustomRole table
  • If C: Permission table + RolePermission junction

Your Answer:

[Choose A, B, or C]

Domain 4: Billing, Subscriptions & Contracts​

Goal: Design subscription plans, usage tracking, billing cycles

Q4.1: Pricing Model (P0 - Foundation)​

Question: What pricing models do you need?

Options:

  • Flat monthly fee (per tenant)
  • Per-user pricing (seat-based)
  • Usage-based (API calls, storage, compute)
  • Tiered plans (Free, Pro, Enterprise)
  • Custom contracts (enterprise negotiated pricing)

Data Model Impact:

  • SubscriptionPlan table
  • UsageMeter for tracking (if usage-based)
  • Contract table for custom agreements

Your Answer:

[Check all that apply]
For each checked:
  - Describe pricing structure
  - Example: "Pro plan: $49/month + $10/user"

Q4.2: Billing Cycle (P0 - Foundation)​

Question: What billing frequencies do you support?

Options:

  • Monthly
  • Quarterly
  • Annual
  • Custom (enterprise 2-3 year contracts)

Data Model Impact:

  • billing_cycle enum on Subscription
  • Pro-rata calculation for mid-cycle changes

Your Answer:

[Check all that apply]
Default cycle: [Monthly/Annual]

Q4.3: Service Contracts (P1 - Phase 2)​

Question: Do you need NetSuite-style service contracts with line items?

Example:

Contract: AZ1.AI - Enterprise Support
  Start: 2026-01-01, End: 2027-12-31
  Line Items:
    - Base Platform: $10,000/year
    - 100 User Licenses: $5,000/year
    - Premium Support: $2,500/year
    - Professional Services (20 hours): $3,000 (one-time)
  Total: $20,500/year
  Billing: Quarterly ($5,125/quarter)

Options:

  • A) No - Simple subscriptions only
  • B) Yes - Basic contracts (start/end date, total amount)
  • C) Yes - Full contract line items with item types (recurring, one-time, usage)

Data Model Impact:

  • If B: Contract table
  • If C: Contract, ContractLineItem, ItemType tables

Your Answer:

[Choose A, B, or C]

Q4.4: Payment Methods (P0 - Foundation)​

Question: What payment methods should be supported?

Options:

  • Credit card (Stripe)
  • ACH/Bank transfer
  • Invoice + NET 30/60 terms (enterprise)
  • Purchase Order (PO) workflow

Data Model Impact:

  • PaymentMethod table
  • Stripe integration for card
  • Manual invoice tracking

Your Answer:

[Check all that apply]
Priority order: [List]

Domain 5: Accounting & Financial Management​

Goal: Design chart of accounts, revenue recognition, financial reporting

Q5.1: Revenue Recognition (P1 - Phase 2)​

Question: Do you need to track deferred revenue for subscriptions?

Example:

Customer pays $1,200 on Jan 1 for annual subscription
  - Deferred Revenue: $1,200 (liability)
  - Monthly recognition: $100/month for 12 months
  - After 3 months: Recognized = $300, Deferred = $900

Options:

  • A) No - Cash-based accounting (recognize on payment)
  • B) Yes - Accrual accounting with deferred revenue

Data Model Impact:

  • If B: DeferredRevenue table, monthly recognition job

Your Answer:

[Choose A or B]

Q5.2: Chart of Accounts (P2 - Phase 3)​

Question: Do you need a configurable chart of accounts (NetSuite-style)?

Example:

1000 - Assets
  1100 - Cash
  1200 - Accounts Receivable
2000 - Liabilities
  2100 - Deferred Revenue
3000 - Equity
4000 - Revenue
  4100 - Subscription Revenue
  4200 - Professional Services Revenue
5000 - Expenses

Options:

  • A) No - Hardcoded revenue/expense categories
  • B) Yes - Configurable per tenant
  • C) Yes - Subsidiary-specific charts

Data Model Impact:

  • If B/C: ChartOfAccounts table (tenant_id, account_code, account_name, type)

Your Answer:

[Choose A, B, or C]

Q5.3: Financial Reporting (P1 - Phase 2)​

Question: What financial reports are required?

Options:

  • Monthly Recurring Revenue (MRR)
  • Annual Recurring Revenue (ARR)
  • Churn Rate
  • Customer Lifetime Value (LTV)
  • Income Statement (P&L)
  • Balance Sheet
  • Cash Flow Statement

Data Model Impact:

  • Reporting tables/views
  • Aggregation jobs

Your Answer:

[Check all that apply]
Priority: [List top 3]

Domain 6: White-Label & Multi-Platform​

Goal: Enable B2B customers to rebrand and customize

Q6.1: White-Label Scope (P1 - Phase 2)​

Question: What level of white-labeling do you need?

Options:

  • A) None - Single brand (FUTUREPRISE)
  • B) Visual only (logo, colors, domain)
  • C) Full white-label (brand name, email templates, billing name)

Example (Option C):

Tenant: "Acme Corp"
  - Brand: "Acme Workspace"
  - Domain: workspace.acme.com
  - Logo: acme-logo.png
  - Colors: #FF5733 (primary), #FFFFFF (secondary)
  - Emails sent from: noreply@acme.com
  - Invoices show: "Acme Corp" as merchant

Data Model Impact:

  • If B/C: BrandingConfig table (tenant_id, logo_url, primary_color, domain)
  • If C: Custom email templates per tenant

Your Answer:

[Choose A, B, or C]

Q6.2: Custom Domains (P1 - Phase 2)​

Question: Should tenants be able to use custom domains?

Example:

  • Default: acme.coditect.com
  • Custom: workspace.acme.com

Options:

  • A) No - Subdomain only (*.coditect.com)
  • B) Yes - Custom domain with CNAME
  • C) Yes - Fully custom with SSL cert automation

Data Model Impact:

  • custom_domain field on Tenant
  • SSL cert provisioning (Let's Encrypt)

Your Answer:

[Choose A, B, or C]

Q6.3: Multi-Platform Strategy (P0 - Foundation)​

Question: Will CODITECT-PLATFORM be multi-platform or single platform?

Example:

  • Platform 1: CODITECT (AI code assistant)
  • Platform 2: FUTUREPRISE (enterprise workspace)
  • Platform 3: [Future product]

Options:

  • A) Single platform - All features under one product
  • B) Multi-platform - Shared auth, separate apps
  • C) Marketplace - Platform + 3rd-party integrations

Data Model Impact:

  • If B: Platform table, user_platform_access junction
  • If C: Integration marketplace table

Your Answer:

[Choose A, B, or C]

Domain 7: Compliance & Data Governance​

Goal: Ensure regulatory compliance and data protection

Q7.1: Compliance Requirements (P1 - Phase 2)​

Question: What compliance standards must you meet?

Options:

  • GDPR (EU data protection)
  • SOC 2 Type II (security controls)
  • HIPAA (healthcare data)
  • PCI-DSS (payment card data)
  • ISO 27001 (information security)

Data Model Impact:

  • Audit logging requirements
  • Data retention policies
  • Encryption requirements
  • User consent tracking

Your Answer:

[Check all that apply]
Timeline for each: [When needed]

Q7.2: Data Retention (P1 - Phase 2)​

Question: How long must data be retained?

Example:

User activity logs: 90 days
Financial records: 7 years
User-generated content: Until account deletion + 30 days

Options:

  • A) Indefinite retention
  • B) Configurable per tenant
  • C) Compliance-driven (e.g., GDPR = max retention limits)

Data Model Impact:

  • retention_policy table
  • Data archival jobs
  • Soft delete vs hard delete

Your Answer:

[Choose A, B, or C]
For each data type, specify retention period:
  - Logs: [X days]
  - Financial: [X years]
  - User data: [Until deletion + X days]

Q7.3: User Consent & Privacy (P0 - Foundation)​

Question: What user consent do you need to track?

Options:

  • Terms of Service acceptance
  • Privacy Policy acceptance
  • Marketing email opt-in
  • Cookie consent (GDPR)
  • Data processing consent (GDPR Article 6)

Data Model Impact:

  • UserConsent table (user_id, consent_type, granted_at, version)

Your Answer:

[Check all that apply]

Domain 8: Integration & API Strategy​

Goal: Design extensibility and 3rd-party integrations

Q8.1: API Access Levels (P1 - Phase 2)​

Question: Who should have API access?

Options:

  • A) Internal only (no public API)
  • B) Tenant admins (manage their own data)
  • C) Public API (3rd-party developers)

Data Model Impact:

  • API key generation
  • Rate limiting per tenant
  • OAuth scopes

Your Answer:

[Choose A, B, or C]

Q8.2: Webhook Events (P1 - Phase 2)​

Question: What events should trigger webhooks?

Example:

- subscription.created
- subscription.renewed
- subscription.cancelled
- invoice.paid
- user.created
- user.deleted

Options:

  • A) No webhooks
  • B) Basic webhooks (subscription events only)
  • C) Comprehensive webhooks (all resource types)

Data Model Impact:

  • WebhookEndpoint table (tenant_id, url, events[])
  • Webhook delivery queue
  • Retry logic

Your Answer:

[Choose A, B, or C]
If B/C: List required events

Q8.3: Marketplace Integrations (P2 - Phase 3)​

Question: Do you need a marketplace for 3rd-party integrations?

Example:

CODITECT Marketplace:
  - Slack integration (notify on events)
  - Stripe integration (billing automation)
  - QuickBooks integration (accounting sync)
  - Custom integrations (OAuth apps)

Options:

  • A) No - Built-in integrations only
  • B) Yes - Curated marketplace (approved partners)
  • C) Yes - Open marketplace (any developer)

Data Model Impact:

  • Integration table
  • OAuth app registration
  • Scoped permissions

Your Answer:

[Choose A, B, or C]

Domain 9: Audit & Activity Logging​

Goal: Track all system activity for security and compliance

Q9.1: Audit Trail Scope (P0 - Foundation)​

Question: What actions need to be logged?

Options:

  • User authentication (login, logout, failed attempts)
  • User CRUD (create, update, delete)
  • Tenant CRUD
  • Subscription changes
  • Payment events
  • Permission changes
  • Data exports
  • API calls

Data Model Impact:

  • AuditLog table (actor_id, action, resource_type, resource_id, timestamp, ip_address, metadata)

Your Answer:

[Check all that apply]

Q9.2: Activity Dashboard (P1 - Phase 2)​

Question: Should users see an activity feed?

Example:

Activity Feed (Tenant Admin View):
  - 10:45 AM: Jane Doe added user john@example.com
  - 10:30 AM: Subscription upgraded to Pro plan
  - 09:15 AM: Invoice #1234 paid ($99.00)

Options:

  • A) No - Audit logs for compliance only (admin query)
  • B) Yes - Per-user activity feed
  • C) Yes - Tenant-wide activity dashboard

Data Model Impact:

  • If B/C: Optimized activity query views

Your Answer:

[Choose A, B, or C]

Domain 10: Scalability & Performance​

Goal: Plan for growth from day 1

Q10.1: Expected Scale (P0 - Foundation)​

Question: What is your growth projection?

Year 1:

  • Tenants: [Number]
  • Users: [Number]
  • API requests/month: [Number]

Year 3:

  • Tenants: [Number]
  • Users: [Number]
  • API requests/month: [Number]

Data Model Impact:

  • Sharding strategy
  • Caching layer
  • Database choice (Postgres vs Spanner)

Your Answer:

Year 1: [Fill in]
Year 3: [Fill in]

Q10.2: Database Strategy (P0 - Foundation)​

Question: What database architecture do you need?

Options:

  • A) Single PostgreSQL instance (Supabase/Cloud SQL)
  • B) Read replicas (primary + read-only replicas)
  • C) Multi-region (Spanner or distributed Postgres)
  • D) Sharded (tenant-based sharding)

Current:

  • Using Supabase (PostgreSQL)

Data Model Impact:

  • If B/C/D: Connection pooling, replication lag handling

Your Answer:

[Choose A, B, C, or D]
Reasoning: [Explain based on Q10.1]

Q10.3: Caching Strategy (P1 - Phase 2)​

Question: What should be cached?

Options:

  • User sessions (Redis)
  • Tenant metadata (Redis)
  • Subscription plans (CDN/Redis)
  • API responses (CDN)
  • Database query results (Redis)

Data Model Impact:

  • Cache invalidation strategy
  • TTL policies

Your Answer:

[Check all that apply]
TTL defaults: [Session: Xh, Metadata: Xm, etc.]

Summary & Next Steps​

How to Proceed​

  1. Answer questions in order - Start with Domain 1, Q1.1
  2. Provide one answer at a time - We'll design data models incrementally
  3. Ask clarifying questions - If any question is unclear
  4. Review data model proposals - Approve before moving to implementation

Expected Timeline​

  • Discovery: 2-4 sessions (answering all questions)
  • Data Model Design: 1-2 sessions per domain
  • Implementation: Incremental (P0 first, then P1, P2)

Repository Structure​

Your answers will be stored in:

docs/
  customer-discovery/
    answers.md              # Your responses
    data-models/
      domain-1-org.md       # Organization models
      domain-2-geo.md       # Geographic models
      domain-4-billing.md   # Billing models
      ...

Let's start with Q1.1: Organization Types

What types of organizations will CODITECT serve? (Check all that apply)

  • Individuals (solopreneurs, freelancers)
  • Teams (5-20 people, single legal entity)
  • Small Companies (20-100 employees, single entity)
  • Mid-Market (100-1000 employees, possibly multi-entity)
  • Enterprise (1000+ employees, multi-subsidiary, multi-country)