Skip to content

Technical Due Diligence Report — Someli Platform

Status: DRAFT v0.1 — frame document; API findings populated; web client and admin dashboard sections pending their respective audits.

Component coverage:

Component Audit status Source documentation
someli-api (backend HTTP API + worker fleet) ✅ Complete This doc set (located in the documentation tree under someli-doc/audit/someli-api/ — not committed in the cloned someli-api repo)
Web Client (customer-facing UI) ⏳ Pending Located under someli-doc/audit/someli-platform/
Admin Dashboard (internal admin UI) ⏳ Pending Located under someli-doc/audit/admin_console_R/

This document is a master / full-picture document. Its purpose is to summarize platform-wide findings and provide an executive-level assessment. It is generated from the documentation tree, not from the codebase. All claims trace back to source documents cited in §11 Appendices.

Sections that depend on cross-component findings are marked ⏳ Pending component audit where the input is not yet available. The risk register, maturity ratings, and roadmap will be revised when those audits land.

Document control
Document type Technical Due Diligence (TDD) report
Subject Someli platform (API + Web Client + Admin Dashboard)
Version 0.1 (DRAFT)
Audit date 2026-05
Audit basis Documentation tree (not direct code review at this revision)
Frameworks referenced Technical Due Diligence (industry pattern), AWS Well-Architected Framework, OWASP SAMM, OWASP API Security Top 10, SOC 2 Trust Services Criteria, ISO/IEC 25010, DORA, Twelve-Factor App, CMMI 1–5 maturity scale
Intended audience CTO, engineering leadership, security & compliance, finance, board, prospective acquirers, enterprise procurement reviewers

0. How to read this report

If you are… Read
CTO / Engineering Lead §1, §3, §5, §7 (full), §8 (skim)
Board / Investor §1 (full), §6, §7 (top items)
Sales / Customer Success §1, §8
Security / Compliance Lead §1, §4.1, §6 (security risks), §8
Operations / SRE §4.2, §4.3, §4.6, §7
Acquirer / Due-Diligence Team §1, §4 (all), §5 (all), §6, §7

The Executive Summary (§1) stands alone; the rest is consumable in any order.

1. Executive Summary

1.1 Verdict

The Someli platform is a Node.js + MySQL-backed B2B SaaS for AI-driven social media management. The backend API has been audited in depth (this report's primary content); the web client and admin dashboard are still pending audits.

Posture summary (based on backend audit; will be revised when other component audits land):

The platform is shipping features and serving real customers, but it is operating below the floor that most enterprise procurement processes accept. It cannot pass a serious enterprise security review in its current state, it cannot horizontally scale to a second host without correctness regressions, and several findings are independently sufficient grounds for an acquirer's technical due diligence to discount valuation.

Recovery is tractable. The findings are well-understood, the remediation plan is documented (§7), and the underlying business — social-platform automation with AI-generated content — is technically straightforward in principle. The work to bring the platform to enterprise-grade is roughly 12–18 months of focused engineering investment by 2–4 dedicated senior engineers.

Maturity rating: Level 1 of 5 across the audited backend (CMMI scale; see §5 for per-pillar detail). Platform-level rating cannot be finalized until the other component audits complete; the working assumption is that the rating will not improve materially because the most consequential findings (security, observability, infrastructure-as-code) are platform-wide.

1.2 Top 5 strengths

  1. Recently-completed comprehensive backend documentation. A 30+ document inventory of the codebase (architecture, integrations, jobs, dependencies, data model, deployment paths) was produced as input to this report. Few platforms at this maturity level have an artifact this complete.
  2. Recognizable technology choices. Node.js + MySQL + AWS is a known-quantity stack. Hiring is feasible. The eventual modernization moves will not require exotic technology.
  3. AI integration breadth. The platform uses AWS Bedrock, Google Vertex AI, OpenAI, and Google Gemini concurrently. Provider diversity reduces vendor lock-in; the AI-orchestration helpers (§Appendix A.2) are a recognizable competitive moat.
  4. Backend test of containerization exists. A Dockerfile is present (with known issues, see §4.3) and one deployment path uses Fargate. The infrastructure to deploy modern containerized workloads is partially in place.
  5. Strong product-market fit signals. A tJobs table at 46.6M auto-increment, a tMedia table at 1.5M rows, a tUserLibrary at 44K, and 4,800+ users in tMember indicate real customer usage. The platform is being used; this report is about running it well, not building it.

1.3 Top 5 risks

Risk Category Severity Mitigation phase
Hardcoded secrets in committed source code (Slack token, Polotno key, session secret) Security Critical Phase 0a — this week
Double-posting to social platforms under retry (no idempotency keys on publishing jobs) Correctness Critical Phase 0–1
Cannot horizontally scale beyond a single host (polling-pattern + Socket.IO global) Scaling High Phase 1
/auth/login issues plaintext tokens (no encryption, no signature) Security High Phase 0–1
Two single-file route modules totaling ~46,000 lines block effective code review Engineering High Phase 2

1.4 Top 5 recommendations

# Action Effort Impact
1 Phase 0a (this week): rotate every committed secret; add helmet, CORS allow-list, rate limiting on /auth/* 1 day Closes the highest-severity exposures
2 Phase 0 (3 months): adopt structured logging, schema migration tool, idempotency keys on publishing jobs, basic CI gates 8–12 person-weeks Eliminates the catastrophic-failure category
3 Phase 1 (3–9 months): replace polling with a real job queue (BullMQ/Redis); install OpenTelemetry; eliminate sync-mysql; introduce TypeScript 3–5 months with 2 dedicated engineers Unlocks horizontal scaling; reduces MTTD/MTTR; establishes observability baseline
4 Phase 2 (9–18 months): refactor backend into modular monolith with lint-enforced module boundaries; consolidate the 21k+24k-line route files 6–9 months Makes future change tractable; enables senior hiring; opens the path to selective service extraction
5 Establish engineering charter and adoption-wave practices BEFORE Phase 2 begins 1 week + ongoing enforcement Prevents the feature stream from undermining the refactor stream

1.5 Headline numbers (from API audit)

Metric Value
Backend API endpoints ~728
Backend route files 6
Backend largest single file routes/auth.js at 24,432 lines
Backend second-largest routes/routes.js at 21,631 lines
Background workers (PM2 fleet) ~108 root-level + 5 user-specific AI + 3 dashboard services
Database tables 214 (170 referenced in code, 44 unreferenced)
Direct npm dependencies 94
Dependencies removable immediately 20
External integrations 37
Hardcoded credentials in source 3 known (Slack token, Polotno key, session secret)
AWS S3 client instantiations (no shared client) 86
Polotno-rendering call sites 49 hardcoded-key files / 97 createInstance calls / 22 leak sites
tJobs.id auto-increment 46.6M (busiest table)

2. Methodology & Scope

2.1 Approach

This report is structured as Technical Due Diligence (TDD) — the recognized industry format for assessments of a software platform's health, risks, and improvement potential. TDD is not a single body's "owned" standard but a recognized format used by VC and PE firms, board-level technology committees, enterprise procurement teams, and acquirer technical-DD consultancies.

The TDD format embeds cross-walks to several formal frameworks (§8) without committing to any single one — appropriate because no single framework covers the full scope.

2.2 Sources

This report is generated from the documentation tree, not from the codebase. Every claim cites a source document. The documentation tree was itself produced by direct codebase inspection over the prior weeks; this report consolidates and re-frames its findings.

The doc tree at the time of this report (located under someli-doc/audit/someli-api/, not in the source repo):

someli-doc/audit/someli-api/
├── (master / full-picture documents)
│   ├── tdd-report.md ← this document
│   ├── README.md  (doc index)
│   ├── enterprise-readiness.md  (the strategic source for §5–§7)
│   ├── maturity-model.md  (the methodology for §5)
│   └── verification-report*.md  (the audit-trail for §10)
│
└── (someli-api component documents)
    ├── architecture-overview.md
    ├── data-model.md  (214 tables, with §6 active/unused catalog)
    ├── API-inventory.md  (728 endpoints)
    ├── authentication.md  (token model, OAuth, security findings)
    ├── content-pipeline.md
    ├── agents-and-ai.md
    ├── user-specific-ai.md
    ├── rag-pipeline.md
    ├── media-processing.md
    ├── notifications.md
    ├── jobs-inventory.md  (worker fleet)
    ├── dashboard-analytics.md  (the embedded analytics sub-app — distinct from the standalone admin dashboard which has not been audited)
    ├── deployment.md  (three-path topology)
    ├── configuration.md  (env vars)
    ├── Integration-inventory.md  (37 external services)
    ├── dependencies-inventory.md  (94 packages)
    ├── error-handling.md
    ├── logging-observability.md
    ├── security.md
    ├── realtime-events.md
    ├── getting-started.md  (developer onboarding runbook)
    ├── first-deployment.md  (new-environment runbook)
    ├── verify-markers.md  (open questions tracker)
    ├── visuals-tracking.md  (suggested diagrams)
    ├── engineering-charter.md  (the 12 commitments)
    ├── engineering-practices.md  (operational practice catalog)
    ├── definition-of-done.md  (per-PR checklist)
    └── pr-template-reference.md  (PR template content)

2.3 Scope

In scope (this revision):

  • The someli-api repository: HTTP API, ~108 background workers, embedded analytics dashboard sub-app, deployment artifacts (Dockerfile, nginx.conf, ecosystem.config.js, Jenkinsfile, GitHub Actions workflows, push.sh)
  • Cross-cutting concerns visible from the backend perspective: authentication model, security posture, observability, deployment, integrations, data model

Out of scope (this revision; pending component audits):

  • Web client (customer-facing UI) — see §5.2
  • Admin dashboard (internal admin UI) — see §5.3 (note: distinct from dashboard/ sub-app embedded in the backend, which IS in scope)
  • Production runtime telemetry (the audit is a code-and-docs audit, not a live-system audit)
  • AWS account configuration outside what's discoverable from infra-as-code in the repo
  • Vendor-side configuration (SendGrid, Paddle, social platform apps)

2.4 What this report cannot conclude until the other audits complete

The following sections are explicitly incomplete or provisional pending the web-client and admin-dashboard audits:

  • §1 Executive Summary — maturity rating may shift; some risks may move severity
  • §3 Platform Architecture — only the backend half is described
  • §4 Cross-cutting findings — sections that span all three components (e.g., §4.4 Identity & Authentication end-to-end, §4.5 Data Flow & Privacy) are partial
  • §5 Per-component findings — §5.2 and §5.3 are placeholders
  • §6 Risk Register — frontend-specific risks (XSS, CSP, bundle CVEs, accessibility) are not yet enumerated
  • §7 Roadmap — work items are not yet tagged by component; some Phase 1 items may turn out to require coordinated frontend changes
  • §8 Standards compliance — AWS Well-Architected pillars and OWASP SAMM ratings are backend-only

When those audits complete, this document will be updated to v0.2 (web client added) and v0.3 (admin dashboard added). v1.0 is the intended platform-complete release.

2.5 Frameworks referenced

Framework Used for
Technical Due Diligence (TDD) Overall report structure
AWS Well-Architected Framework (6 pillars) §4 Cross-cutting findings, §8.1
OWASP API Security Top 10 (2023) §4.1 Security, §8.2
OWASP SAMM (15 security practices) §4.1 Security maturity, §8.3
SOC 2 Trust Services Criteria §4.1 Compliance, §8.4
ISO/IEC 25010 (8 quality characteristics) §5 Per-component findings (quality lens), §8.5
CMMI 1–5 maturity scale §5.4 Maturity ratings
DORA capabilities / metrics §4.3 Operations, §7 Roadmap
Twelve-Factor App §4.3 Operations posture
NIST CSF (Identify, Protect, Detect, Respond, Recover) §4.1 Security risk-framing
CIS Controls v8 §4.1 Cybersecurity hygiene

3. Platform Architecture

3.1 Component map

                           ┌────────────────────┐
                           │   End Users        │
                           │   (browsers,       │
                           │    mobile)         │
                           └─────────┬──────────┘
                                     │ HTTPS
                                     │
                       ┌─────────────┴──────────────┐
                       │                            │
                       ▼                            ▼
            ┌────────────────────┐       ┌────────────────────┐
            │   Web Client       │       │  Admin Dashboard   │
            │   (customer UI)    │       │  (internal UI)     │
            │   ⏳ Pending audit │       │  ⏳ Pending audit  │
            └─────────┬──────────┘       └─────────┬──────────┘
                      │                            │
                      └─────────────┬──────────────┘
                                    │ HTTPS / API calls
                                    ▼
                       ┌─────────────────────────┐
                       │    someli-api (✅ audited)
                       │                         │
                       │  HTTP API (Express)     │
                       │  ~728 endpoints         │
                       │                         │
                       │  Worker Fleet (PM2)     │
                       │  ~108 background jobs   │
                       │                         │
                       │  Embedded analytics     │
                       │  sub-app (mounted /auth)│
                       └─────────┬───────────────┘
                                 │
              ┌──────────────────┼─────────────────────────┐
              │                  │                         │
              ▼                  ▼                         ▼
    ┌──────────────┐    ┌────────────────┐      ┌─────────────────┐
    │ MySQL (RDS)  │    │  AWS Services   │     │  External AI &   │
    │ 214 tables   │    │  S3 (×2 buckets)│     │  Vendor APIs     │
    │ us-west-1    │    │  Bedrock        │     │  (Vertex, OpenAI,│
    │              │    │  Secrets Mgr    │     │   Paddle,        │
    │              │    │  ECR, Fargate   │     │   SendGrid,      │
    │              │    │  us-west-2,     │     │   Polotno,       │
    │              │    │  us-east-1      │     │   FB/IG/LI/TT/X) │
    └──────────────┘    └─────────────────┘     └──────────────────┘

The backend serves both client surfaces. The two front-end applications are presumed to share authentication (token-in-header pattern, per authentication.md), but the exact contract between them is documented in those components' documentation, not the backend's.

3.2 Technology choices per component

Component Stack (known / inferred) Doc reference
someli-api Node.js 20.18.1 (CommonJS), Express 4.x, MySQL 8 (3 drivers), Socket.IO, PM2, Polotno-node architecture-overview.md, dependencies-inventory.md
Web Client ⏳ Unknown — to be documented TBD
Admin Dashboard ⏳ Unknown — to be documented TBD

3.3 Inter-component contracts

Authentication contract (per authentication.md):

  • Tokens issued by the API are passed as a custom HTTP header (TOKEN_HEADER_KEY env var on the API side; the header name on the client side is presumed to match)
  • Tokens are AES-encrypted JWTs for OAuth-issued tokens
  • Tokens issued by /auth/login are plaintext concatenations ({userId}_{timestamp}_{userId}) — see authentication.md § Standard Login and §4.1.5 below

API contract:

  • ~728 REST endpoints, no OpenAPI specification published
  • Inconsistent response shape (envelope vs raw JSON vs plain string) — per error-handling.md
  • No published versioning strategy

Real-time contract:

  • Socket.IO endpoint exists but is minimal — only an update broadcast event, no rooms/namespaces, no auth on connections
  • Server-Sent Events (SSE) are used for streaming AI agent responses (per agents-and-ai.md)

Data flow:

  • Cross-region: app in us-west-2, RDS in us-west-1, Bedrock in us-east-1, GCP services in us-central1 (per Integration-inventory.md § Cross-region data flow)

3.4 What's missing from this view

⏳ Pending other component audits, the following are not yet known: - Frontend bundle composition / framework - Frontend build pipeline - Frontend authentication / token storage approach (cookie? localStorage? memory?) - CDN configuration for frontend assets - Frontend error reporting / observability - Admin-only API surface (which endpoints are admin-only and how that's enforced)

4. Cross-Cutting Findings

This section synthesizes findings that span the entire platform or its operating environment. Each subsection cites the source documents in the audit tree (someli-doc/audit/someli-api/ and siblings — not in any source repo).

4.1 Security & Compliance

Source documents: security.md, enterprise-readiness.md §4.5, §5.7, §8

Posture (backend):

  • ❌ No OpenAPI spec — 728 endpoints with no published contract; OWASP API9 (Improper Inventory Management) finding
  • ❌ CORS open to all origins (cors() with no options) — OWASP API8
  • ❌ No helmet — security headers absent
  • ❌ No rate limiting — /auth/* is brute-forceable; OWASP API4 (Unrestricted Resource Consumption)
  • ❌ 150 MB JSON body limit globally — DoS-friendly; mismatch with nginx's 100 MB
  • ❌ 3 hardcoded credentials in source — Slack token, Polotno key, session secret (xoxb-3144030948916-..., FXZvloSJvAe09-bdR9iC, '3eB(2:\srlI+qa5')
  • ❌ /auth/login returns plaintext token — ${userId}_${timestamp}_${userId} with no encryption / signature / integrity check
  • ❌ No Dependabot / Snyk / yarn audit in CI — supply-chain attacks reach production
  • ❌ No SAST in CI (no Semgrep / SonarCloud / CodeQL)
  • ❌ Only 1 input validator across 728 endpoints (registerVal)
  • ❌ No global error handler — stack traces may leak to clients
  • ⚠ tMember.auth_pass DEFAULT 'Welcome!1' — hardcoded default password at the schema level
  • ⚠ GCS credentials correctly fetched from AWS Secrets Manager — partial credit; the only secret handled correctly today

Compliance posture:

Standard Backend status
OWASP API Top 10 (2023) 7 of 10 ❌ Not compliant; 3 ⚠ Partial; 0 ✅ Compliant
Twelve-Factor App 3 ✅; 8 ⚠; 1 ❌
SOC 2 readiness Not audit-ready (most criteria missing)
GDPR (data subject rights) No documented endpoints / processes
ISO 27001 Not pursued
PCI DSS N/A if Paddle handles all card data — verify

⏳ Pending other-component audits, the following platform-level concerns are not yet enumerated: - Frontend XSS exposures - Frontend Content Security Policy (CSP) - Frontend dependency CVEs and supply chain - Token storage on the client (cookie / localStorage / memory) - Cross-origin behaviors for the admin dashboard - Browser session lifetime / fixation / hijacking exposures

The OWASP SAMM rating (15 security practices × maturity 0–3) for the backend is largely Maturity 0–1; platform-level rating cannot be finalized until frontend findings are in.

4.2 Observability & Operations

Source documents: logging-observability.md, enterprise-readiness.md §4.6

Posture (backend):

  • ❌ No structured logging — console.log everywhere; winston is in package.json but only one caller (helper/functionsForAi/cloudRag.js)
  • ❌ No request logger — incoming HTTP requests not captured
  • ❌ No correlation IDs / trace IDs
  • ❌ No metrics endpoint — no Prometheus / StatsD / CloudWatch publication
  • ❌ No distributed tracing
  • ❌ No APM (Datadog / New Relic / Sentry agents not present)
  • ❌ No alerting on error rate, latency, or job failures
  • ❌ No SLOs / SLIs defined
  • ✅ Healthcheck endpoints exist: /health and /db-health — but /health returns status: 'Server is running', not the conventional 'ok'
  • ⚠ PM2 logs are the entire log surface — no centralized aggregation; pm2 logs | grep is the operational debugging tool

MTTD on production incidents is currently "until a customer reports it." That is incompatible with enterprise SLAs.

⏳ Pending audits: frontend error reporting (Sentry?), real-user monitoring (RUM), uptime monitoring, status page.

4.3 Deployment & Infrastructure

Source documents: deployment.md, enterprise-readiness.md §4.10, §4.11

Backend posture:

  • 🟢 Three-path deployment topology (per deployment.md):
  • Dev: GitHub Actions on dev_api push → SSH+PM2 to AWS Lightsail
  • Dev (alternate): Jenkins → SSH+PM2 to EC2 (54.189.254.22)
  • UAT: manual push.sh → ECR (255061853867.dkr.ecr.us-west-2.amazonaws.com/uat) → Fargate (one image, many tasks)
  • Production: no automation in this repo (assumed manual)
  • ❌ Two CI systems on the same branch — Jenkins + GHA both deploy dev_api, racing each other
  • ❌ Dockerfile has no yarn install step — combined with .dockerignore excluding node_modules, this would produce broken images on a clean checkout
  • ❌ No image versioning — push.sh overwrites :uapi tag every push; no rollback path
  • ❌ No infrastructure as code — no Terraform / Pulumi / CloudFormation / CDK in the repo
  • ❌ No automated rollback on health-check failure
  • ❌ No blue/green or canary deploys
  • ❌ No artifact signing (SBOM / cosign / Sigstore)
  • ⚠ nginx and Express body limits don't match (100 MB vs 150 MB)
  • ⚠ push.sh hardcodes /home/nisanth/someli-api — UAT releases bound to one developer's workstation (truck factor of 1)

Cross-region topology (per Integration-inventory.md § Cross-region): - App: us-west-2 - RDS MySQL: us-west-1 (cross-region database calls = added latency + egress cost) - Bedrock: us-east-1 - Vertex AI / GCS: us-central1 (Google Cloud)

⏳ Pending audits: frontend deployment pipeline (typically separate; CDN + bucket); admin dashboard deployment.

4.4 Identity & Authentication (end-to-end)

Source documents: authentication.md

This is the section most affected by the missing component audits. Backend findings only:

  • ⚠ Dual authentication paths — middlewares/auth.js (Passport JWT + AES) and methods.js (custom AES-only). The two are independent; routes choose. They use different headers (TOKEN_HEADER_KEY env var vs hardcoded "authorization").
  • ❌ /auth/login returns plaintext token — ${userId}_${timestamp}_${userId}, no encryption. Internal inconsistency with the rest of the auth model: the auth middleware decrypts an AES-wrapped JWT, which is incompatible with a plaintext concatenation. There must be a code path that handles the inconsistency that has not yet been traced. Investigate.
  • ⚠ Hardcoded session secret in server.js
  • ⚠ JWT secret rotation procedure not documented
  • ✅ OAuth flows for 6 providers (Google, GitHub, Facebook, LinkedIn, TikTok, Twitter) via Passport, with AES-encryption applied to OAuth tokens

⏳ Pending audits: how does the frontend store the token (cookie / localStorage / memory)? Is there CSRF protection on session-cookie-based flows? Does the admin dashboard use the same auth or a separate mechanism? Is there role-based access control documented end-to-end?

4.5 Data Flow & Privacy

⏳ Pending other-component audits.

Backend-only findings (per data-model.md, Integration-inventory.md):

  • 214 tables, 170 referenced, 44 unreferenced (some hold data — investigate before any cleanup)
  • Tokens stored in JSON detail blob in tMemberAuth rather than discrete columns (anti-pattern)
  • Cross-region database calls: app in us-west-2 → RDS in us-west-1
  • No SSL/TLS in transit on DB connections (driver default ssl: false)
  • AI provider calls send user content to: AWS Bedrock (us-east-1), Google Vertex AI (us-central1), OpenAI (US), Polotno (vendor-managed)
  • No documented Data Subject Access Request (DSAR) process for GDPR

Privacy posture cannot be fully assessed until the frontend's data-collection and storage practices are documented.

4.6 Reliability & Disaster Recovery

Source documents: enterprise-readiness.md §4.7

Posture (backend):

  • ❌ No idempotency keys on social-publishing jobs — retries can double-post (Critical)
  • ❌ No circuit breakers on external API calls
  • ❌ No graceful shutdown beyond SIGTERM/SIGINT handlers (worker fleet doesn't drain in-flight Polotno renders)
  • ❌ No documented RTO / RPO commitments
  • ❌ No backup verification (untested backups = no backups)
  • ❌ No chaos testing
  • ⚠ Single MySQL instance — Multi-AZ recommended for prod; status not verified from repo
  • ⚠ Single-region deployment — cross-region failover not documented

⏳ Pending audits: frontend uptime / error budget; admin dashboard reliability requirements (typically lower-stakes than customer-facing).

5. Per-Component Findings

5.1 someli-api (Backend)

Audit status: ✅ Complete Detail location: the entire someli-doc/audit/someli-api/ set as it exists today (audit-tree only — not committed in the source repo) Doc count: 30+ documents

Quick summary:

The backend is a Node.js + Express monolith with two route files totaling ~46,000 lines, served by a fleet of ~108 PM2-managed background workers polling MySQL on cron schedules. Three database drivers coexist (mysql, mysql2, sync-mysql — the last is an architectural antipattern). 37 external service integrations (AWS, Google Cloud, AI providers, social platforms, payment providers, communications). 86 separate S3 client instantiations (no shared client). 49 hardcoded Polotno render-key files with 22 documented memory-leak sites. The schema has 214 tables, 170 actively used, 44 unreferenced (some abandoned features, some superseded, some unclear).

Top findings (full list in Appendix A):

  1. Engineering malpractice on file size: 21,631-line routes/routes.js and 24,432-line routes/auth.js accumulated over 3.5 years across 21 contributors and 1,490+ commits without architectural review
  2. 3 hardcoded credentials (Slack token, Polotno key, session secret) in committed source
  3. /auth/login returns a plaintext token; no encryption / signature / integrity
  4. Polling-based job-queue pattern — cannot horizontally scale to a second host without correctness regressions
  5. No automated tests (zero); package.json's test script is a placeholder
  6. Three database drivers including sync-mysql which blocks the event loop in 127 callers
  7. 22 Polotno-renderer leak sites — chief cause of worker-fleet memory pressure
  8. Two CI/CD pipelines (Jenkins + GitHub Actions) deploying the same branch
  9. Schema with zero foreign-key constraints — application-level integrity only
  10. tEmailSchedule filter scope issue — job_send_mail.js only processes one specific TemplateId; behavior of other templates needs investigation

Maturity rating (CMMI 1–5, per enterprise-readiness.md §3):

Pillar Rating
Architecture & Modularity 1
API Contract & Versioning 1
Data Architecture 1
Background Processing 1
Security & Compliance 1
Observability 1
Reliability & Resilience 1
Scalability 1
Testing & Quality Gates 1
CI/CD & Deployment 2
Infrastructure as Code 1
Cost Visibility & FinOps 1
Documentation & Knowledge Management 3
Team Practices & Governance 2

Strengths: AI integration breadth; recent comprehensive documentation effort; Node.js + MySQL stack hireable.

Recommended target architecture: Modular monolith with Node.js + TypeScript for the HTTP layer and Go (or JVM/Kotlin) for the worker fleet, joined by a real job queue. Detailed in enterprise-readiness.md §5.

5.2 Web Client (Customer-Facing UI)

Audit status: ⏳ Pending Detail location: future web-client/ subtree Anticipated audit scope:

  • Frontend framework, version, and patterns
  • Bundle composition, size, performance (Core Web Vitals)
  • Accessibility posture (WCAG)
  • Security: CSP, XSS protection, dependency CVEs, supply chain
  • Authentication client behavior: token storage, refresh handling, session management
  • API consumption patterns (which backend endpoints are exercised, error handling, retries)
  • State management approach
  • Build / deploy pipeline
  • Cross-browser / mobile compatibility
  • Frontend observability (error reporting, RUM, analytics)
  • Testing posture (unit, integration, e2e)
  • Internationalization / localization
  • SEO / metadata / structured data

Findings to be added when the audit completes. Expected timing: TBD by audit team.

When this section is populated, §1 Executive Summary, §4 Cross-cutting findings (especially §4.1, §4.4, §4.5), §6 Risk Register, and §7 Roadmap will be revised.

5.3 Admin Dashboard (Internal UI)

Audit status: ⏳ Pending Detail location: future admin-dashboard/ subtree Anticipated audit scope:

Same as web client (§5.2), plus:

  • Privileged-access controls
  • Admin-action audit logging
  • Provisioning / deprovisioning workflow
  • Sensitive-data handling and masking
  • Whether the admin UI shares a stack/codebase with the web client or is separate
  • Whether admin endpoints share the API or have a separate admin API
  • Role / permission model end-to-end

Findings to be added when the audit completes.

Note on naming: "Admin Dashboard" here refers to the standalone internal UI for staff. This is distinct from the dashboard/ sub-application embedded in the backend (per dashboard-analytics.md), which provides customer-facing analytics endpoints. The two are not the same component; they are documented separately.

5.4 Platform-level maturity rating

The platform-level rating is the lowest of the per-component ratings on each pillar (a chain is only as strong as its weakest link). With only the backend audited, current ratings are equal to the backend ratings in §5.1.

After the other audits land, expect: - Architecture & Modularity to potentially worsen (if the frontend is also a monolithic SPA without modules) - Security & Compliance to potentially worsen (frontend introduces new attack surface) - Observability to remain at 1 unless the frontend has Sentry-style error reporting - Documentation likely the only pillar where adding components will improve the rating, because the documentation effort applies to all of them

6. Risk Register

This is the consolidated risk register across the platform. Risks are tagged by component(s) affected: [API], [WC] (web client), [AD] (admin dashboard), [ALL] (platform-wide).

⏳ The list below is current to the backend audit only. Risks with [WC] or [AD] tags will be added when those audits complete. Existing [API]-tagged risks may be re-tagged [ALL] if they turn out to require coordinated frontend changes.

ID Risk Component(s) Likelihood Impact Mitigation phase
R-1 Hardcoded secrets compromise [API] High Critical Phase 0a
R-2 Double-posting to social platforms under retry [API] High High Phase 0–1
R-3 Auth brute-force / credential stuffing (no rate limit) [API] Medium High Phase 0a
R-4 DoS via 150 MB body [API] Low High Phase 0a
R-5 DB single point of failure [API] Low Critical Phase 1
R-6 OOM under Polotno load [API] Medium High Phase 2
R-7 Failed deploy with no rollback [API] Medium High Phase 1
R-8 Long MTTD due to no observability [ALL] High Medium Phase 1
R-9 Inability to pass enterprise procurement review [ALL] High High Phase 0 + Phase 2
R-10 Schema drift between environments [API] High Medium Phase 1
R-11 Talent retention / single-engineer dependencies [ALL] Unknown High Phase 2
R-12 Vendor lock-in [API] Medium Medium Phase 2+
R-13 Cost run-away on AI features [API] Medium Medium Phase 1–2
R-14 GDPR data-subject request unhandled [ALL] High (if EU) High Phase 1–2
R-15 Supply-chain attack via dependency [API] Low Critical Phase 0
R-16 Reputational damage from a high-profile double-post [API] Medium Critical Phase 0
R-17 Senior engineering hires decline after reading codebase [ALL] High High Phase 1+
R-18 Acquisition / fundraising valuation discount [ALL] High High Phase 1–2
R-19 Hidden blast radius — small change breaks something distant [API] High Medium Phase 2
R-20 Vendor lock-in to specific AI providers [API] Medium Medium Phase 2
R-21 Junior PR introduces a regression to a critical path [ALL] High Medium Phase 1
R-22 Long-running PM2 worker leaks memory and crashes [API] Medium High Phase 2
R-23 Large enterprise customer signs and discovers single-host scaling ceiling [ALL] Medium Critical Phase 1–2
R-24 Plaintext /auth/login token leaks user IDs through logs [API] High High Phase 0–1
R-25 tEmailSchedule silent backlog (single-template filter) [API] Unknown Medium Investigate (Phase 0)

⏳ Risks to be added in v0.2 / v0.3: - Frontend XSS / dependency CVE / CSP risks - Token-storage risks - Admin-action audit-trail gaps - Cross-component identity / session risks

7. Recommendations & Roadmap

The roadmap is in five phases, calibrated for a small-to-mid engineering team (2–4 dedicated senior engineers). Larger teams compress; smaller teams stretch. See enterprise-readiness.md §6 for full detail.

⏳ Component tagging will be added when the other audits land. Currently the work items are largely backend; some will turn out to require coordinated frontend work and will be re-tagged.

Phase 0a — This Week

Effort: under 1 day for one engineer.

Item Tag
Rotate Slack bot token, Polotno key, session secret, AES token-encryption key [API]
Run gitleaks over full git history; rotate any other findings [API]
Add helmet() middleware [API]
Replace open cors() with allow-list [API]
Add express-rate-limit on /auth/* [API]
Audit /uploads static-route exposure [API]

Phase 0 — Stabilize (Months 0–3)

Effort: 12–16 person-weeks. With 2 dedicated engineers in parallel: 6–8 weeks.

Item Tag
Secrets manager + remove all hardcoded secrets from source [ALL]
Idempotency keys on all social-publishing jobs [API]
Structured logging (Winston / Pino) with correlation IDs [ALL]
Validation framework (Zod / Yup / express-validator) on all endpoints [API]
Global Express error handler with envelope discipline [API]
Audit logging for privileged actions [ALL]
Dependabot / Snyk in CI [ALL]
SAST in CI (Semgrep / SonarCloud / CodeQL) [ALL]
Backups + restore verification [API]
Top-5 incident runbooks [ALL]
Resolve /auth/login plaintext token issue [API]
Investigate tEmailSchedule single-template filter [API]

Phase 1 — Foundation (Months 3–9)

Effort: 30–45 person-weeks. With 4 dedicated engineers in parallel: 3–4 months.

Item Tag
TypeScript adoption (incremental, allowJs) [API], possibly [WC]/[AD]
Schema migration tool (Knex / Prisma / Flyway) [API]
Eliminate sync-mysql (127 call sites) [API]
Centralize DB pool in platform/db [API]
Real job queue (Redis + BullMQ); migrate top 10 jobs [API]
OpenTelemetry SDK; logs/metrics/traces flowing [ALL]
SLOs defined and tracked [ALL]
OpenAPI spec for top 50 endpoints [API]
/v1/ versioning + deprecation policy [API]
Test infrastructure + tests on auth/billing/publishing [API]
Containerize (fix Dockerfile); retire one CI pipeline [API]
Terraform for full infrastructure [ALL]
GitHub Actions canonical CI/CD [ALL]

Phase 2 — Modular Refactor (Months 9–18)

Engineering Charter, Wave 3 of practices, must be in force before this phase begins. See engineering-charter.md, engineering-practices.md.

Item Tag
Reorganize backend into src/modules/{identity,content,publishing,analytics,billing,notifications}/ [API]
Module-boundary linter [API]
Polotno renderer pool [API]
Single RAG implementation; resolve the two-implementation drift [API]
Auth consolidation; refresh tokens; resolve dual-path [ALL]
Audit log integrated with SIEM [ALL]
SOC 2 Type I evidence preparation; complete audit [ALL]
Public status page [ALL]
Per-feature cost dashboards [API]

Phase 3 — Selective Service Extraction (Months 18+, optional and trigger-driven)

Extract individual modules into their own services only if a concrete operational pain or compliance requirement demands it. May never happen — that's a valid outcome. See enterprise-readiness.md §6.4.

What gets cut

Per enterprise-readiness.md §6.5, the roadmap explicitly excludes:

  • Multi-region active-active
  • Kubernetes (unless team is already strong on it)
  • Event sourcing / CQRS
  • GraphQL (unless product reason)
  • Polyglot persistence on day 1
  • Per-module databases
  • Event-driven internal communication
  • Anti-corruption layers, sagas

These are common-misadvice items that don't apply to a focused product on a small team.

8. Standards Compliance Cross-walk

8.1 AWS Well-Architected Framework — 6 pillars (backend only)

⏳ Web client and admin dashboard pillars will be added when those audits complete.

Pillar Backend rating Top finding
Operational Excellence Low Manual deploys, two CI systems, no IaC, no postmortems
Security Very Low Hardcoded secrets, no rate limit, open CORS, plaintext login token
Reliability Low No idempotency, no chaos testing, single-DB SPOF
Performance Efficiency Low Polling + sync-mysql block event loop; cross-region DB calls
Cost Optimization Low No per-feature cost attribution; AI spend untracked per-tenant
Sustainability Not assessed (Out of scope for this revision)

8.2 OWASP API Security Top 10 (2023) — backend only

Item Status
API1: Broken Object Level Authorization ⚠ Partial
API2: Broken Authentication ⚠ Partial (dual paths; plaintext login token)
API3: Broken Object Property Level Authorization ❌
API4: Unrestricted Resource Consumption ❌
API5: Broken Function Level Authorization ⚠ Partial
API6: Unrestricted Access to Sensitive Business Flows ❌
API7: Server Side Request Forgery Unknown
API8: Security Misconfiguration ❌
API9: Improper Inventory Management ❌
API10: Unsafe Consumption of APIs ⚠ Partial

8.3 OWASP SAMM — security maturity (backend only)

⏳ Full ratings to be added; backend posture is largely Maturity 0–1 across the 15 practices. Will be detailed when the security-specific sub-report is produced (potentially as part of Phase 0 readiness work).

8.4 SOC 2 readiness

Trust Service Criterion Backend status
Security (CC) Not ready
Availability (A) Not ready
Processing Integrity (PI) Partial
Confidentiality (C) Partial
Privacy (P) Not ready (if applicable)

A formal SOC 2 readiness assessment by a CPA firm is recommended in Phase 1 or early Phase 2.

8.5 ISO/IEC 25010 — software quality (backend only)

Quality characteristic Backend rating Notes
Functional Suitability Acceptable Product works; ships features
Performance Efficiency Low Polling pattern + sync-mysql + cross-region DB
Compatibility Acceptable REST API; standard web protocols
Usability Out of scope (frontend) TBD
Reliability Low No idempotency, no DR plan
Security Very Low See §4.1
Maintainability Very Low 21k+24k-line files; no tests; three DB drivers
Portability Acceptable Container-buildable; dual-platform Node.js

8.6 Twelve-Factor App (backend)

3 of 12 factors fully compliant; 8 partial; 1 non-compliant (Logs). See enterprise-readiness.md §8.

8.7 DORA capabilities

DORA delivery metrics (Deployment Frequency, Lead Time, Change Failure Rate, MTTR) are not currently measured. Establishing measurement is a Phase 1 deliverable. Industry "elite" baselines:

  • Deployment frequency: multiple per day
  • Lead time for changes: < 1 day
  • Change failure rate: < 15%
  • MTTR: < 1 hour

Current state is unknown but almost certainly far from these.

9. Open Questions / [VERIFY] Markers

Items requiring external information or follow-up investigation. The full per-doc list lives in verify-markers.md. Platform-level open questions:

Question Owner Phase
Is the web client repo accessible / what's the audit timeline? Engineering Lead Now
Is the admin dashboard a separate repo / separate stack? Engineering Lead Now
Does the web client/admin dashboard share authentication with the API? Engineering Lead + Security After audit
Is /auth/login's plaintext-token finding a real exposure or is there a separate code path that re-encrypts? Engineering Lead + Security Phase 0
Are there other email-sending workers besides job_send_mail.js? Platform Lead Phase 0
What is the actual Vertex AI corpus configuration (since tAccounts.corpusName doesn't exist)? Platform Lead + ML Phase 1
What is the production deployment process? (Not in this repo) Operations Phase 1
Is there a backup verification process? Operations Phase 0

10. Conclusion (provisional)

The Someli backend is a recognizable B2B SaaS pattern with significant accumulated technical debt and several high-severity security exposures. The remediation path is well-documented and tractable; the cost is real but bounded; the team-size investment required is 2–4 dedicated senior engineers over 12–18 months.

The platform-level conclusion will be finalized in v1.0 of this report, after the web client and admin dashboard audits complete.

Provisional recommendations to engineering leadership:

  1. Apply Phase 0a (this week's items) immediately.
  2. Commission the web client and admin dashboard audits using the same documentation-tree-based approach used here.
  3. Establish the engineering charter and adoption-wave practices (engineering-charter.md, engineering-practices.md) before Phase 2 of the roadmap begins.
  4. Decide the team-size investment level (1, 2, or 4 dedicated senior engineers) — the timeline ranges in §7 are conditional on this.
  5. Plan a SOC 2 readiness assessment with a CPA firm in late Phase 1.

11. Appendices

The detailed component-level findings live in component subtrees. This master document references them by path.

Appendix A — someli-api (Backend)

Subtree location: someli-doc/audit/someli-api/ (audit tree, separate from the cloned source repo).

Index of detailed component documents:

Strategic and methodology documents:

Audit trail:

Appendix B — Web Client

Subtree location: future web-client/ Status: ⏳ To be authored once the web client audit completes.

Appendix C — Admin Dashboard

Subtree location: future admin-dashboard/ Status: ⏳ To be authored once the admin dashboard audit completes.

12. Document evolution

Version Date Component coverage Status
0.1 2026-05 API only DRAFT
0.2 TBD API + Web Client Planned
0.3 TBD API + Web Client + Admin Dashboard Planned
1.0 TBD All components, reconciled, executive-ready Target

Each version after 0.1 will: - Add the new component's appendix section - Revise the Executive Summary - Re-tag risks in the Risk Register by component - Re-tag roadmap items by component - Update the maturity assessment with platform-level (worst-of-components) ratings - Update the standards compliance cross-walk

The intended v1.0 release is the executive-ready, platform-complete TDD report suitable for board consumption, customer security questionnaires, and acquirer due-diligence handoff.