Delivery Response

From: Ketan Khairnar To: SecComply Technologies Re: Proposal response for SRS_Overwatch.md v1.0 (Draft — Greenfield), 2026‑04‑10 Date: 2026‑04‑13 Ask on table: Deliver all 17 systems in the SRS in 2 months, agent‑assisted development.

Source documents (SRS_Overwatch.md, AUTH_MODULE_DESIGN.md, AUTHZ_MODULE_DESIGN.md) provided by SecComply on 2026-04-10 are treated as authoritative and unmodified throughout this response.

1. Executive summary (read this first)

The honest answer: all 17 systems at the quality bar stated in the SRS is not a 2‑month delivery — not at any team size, and certainly not at ours. Our team is 2 senior engineers (Ketan Khairnar + 1 senior architect with similar experience), augmented by 1–2 mid/senior contractors for the connector + scanner phase. We're not a 13-FTE consultancy; we won't price a 13-FTE proposal that we can't actually staff. With this team we can commit to:

• Auditable v1.0‑Core (12 weeks, W0–W12) — production‑grade, deployable, covering the auth/authz backbone the rest of the platform depends on, plus the compliance engine that makes the product say what it does on the box. Owned end-to-end by the two seniors.
• v1.0‑Extended (W7–W14, overlapping) — connector and scanner work, with 1–2 contractors joining at W7 once the connector framework contract is frozen. Total programme: 12–14 weeks.

The driver is not lines of code — agents ship code fast. The driver is:

1. Security‑sensitive surface. Auth, AuthZ, session revocation, tenant isolation, crypto, audit. These are not where we trade thoroughness for speed. They need design review, threat modelling, and a human in the loop.
2. External integration breadth. AWS + GCP + Azure + GitHub + GitLab + Entra + Google Workspace + Okta + generic OIDC/SCIM + SMTP + LLM. Every one has credential flows, rate‑limit behaviour, and failure‑mode quirks that swallow more calendar time than code time.
3. Seed‑data content. 93 ISO controls, 61 SOC 2, 30 DPDP, atomic control library, Vendor Library (15+ vendors with pre‑verified due‑diligence), Policy Library (12+ templates with merge fields). This is GRC content work, not engineering — it needs a security/compliance SME, not an agent.
4. Air‑gapped on‑prem. Helm + Docker Compose + air‑gapped mirror + backup/restore + upgrade procedure + observability catalog. Every Appendix‑C TBD is weeks of operator‑facing work.

Recommended shape below.

2. Scope interpretation — what we counted

2.1 Systems in SRS (17 modules)

Total functional REQs: 252 (excludes NFRs, safety, security, performance).

2.2 What you also asked us to build (platform floor)

These are non‑negotiable dependencies of every module. The SRS calls them "first‑party platform services":

• BFF (Backend‑for‑Frontend) — stateless JWT/session verify, RBAC enforcement, CORS, rate limiting, audit logging, request‑ID propagation.
• Self‑hosted document DB (MongoDB) — replica set and shardable. With per‑tenant isolation, migrations, seed loader.
• Self‑hosted S3‑compatible object store — evidence, policies, reports. With malware signature scan on upload (REQ‑SEC‑11/REQ‑EVID‑9).
• Transactional email service — SMTP dispatcher, template engine, bounces, reminders, tokenised links.
• Observability stack — structured logs, metrics, traces, error telemetry, secret scrubbing (REQ‑SEC‑7). Catalog is a C‑11 TBD.
• KeyStore — file‑backed default with pluggable HSM/KMS interface (REQ‑AUTH‑32, REQ‑SEC‑5, C‑9 TBD).
• Shared design system — light + dark mode, command menu, WCAG 2.1 AA primitives, empty/loading/error states.
• Seed‑data runtime — versioned, replayable loader for frameworks, atomic controls, CSPM checks, SCM checks, vendor library, policy library.
• Deployment artefacts — OCI images, reference Helm chart, reference Docker Compose, air‑gapped mirror instructions, backup/restore, upgrade playbook (C‑6/C‑7/C‑12 TBDs).

The platform floor is roughly 30% of the total build. Most clients under‑count it. We are not.

3. Gaps, ambiguities, and decisions needed from client

These block or distort estimates. We cannot finalize a fixed‑scope commitment without answers.

3.1 Blockers (must resolve before week 0)

3.2 Appendix C items still open (we inherit these)

C‑1 upload size, C‑2 i18n loader, C‑3 WCAG audit, C‑4 framework roadmap, C‑6 on‑prem reference arch, C‑7 backup/DR playbook, C‑8 rate limits, C‑9 KeyStore adapter spec, C‑10 browser matrix CI, C‑11 observability catalog, C‑12 migration runner. Each is 0.5–2 dev‑weeks of documentation + artefact, not just REQ text.

3.3 Ambiguity we will resolve ourselves (flagging for visibility)

• Tenant data model per module. SRS defines scope rules (cascaded vs instance) but not concrete collections/indexes per module. We will write the data‑model spec during implementation; client review welcomed but not blocking.
• Connector SDK surface. We will pick a connector framework (likely gRPC service contracts + versioned manifest) so all scanners share rate‑limit, retry, and credential‑handling primitives. Out‑of‑scope to specify in SRS.
• Frontend framework. Keeping TS as you confirmed. Default: Next.js (App Router) + React 19 + shadcn/ui + TanStack Query. If you have a standing preference, name it by week 0.

4. Technology stack recommendation

User guidance captured: TS is acceptable on the web side; containerised deployment; Go or Java preferred on the backend for stability.

Full stack research: See our internal research layer — 14 MECE capability buckets (buckets/01..14_*.md), plus four synthesis docs in synthesis/ (our internal stack reference, our internal integration notes, our internal stack matrix, our internal integration blueprint). The research is canonical; this section summarises.

4.1 Recommended stack (v2 — research-backed)

Aggregate-distribution licence notes (posture documented in release memo): MinIO (AGPL-3 sidecar — §13 network-copyleft does not trigger because we ship MinIO unmodified and interact only via the standard S3 protocol), ClamAV (GPL-2 sidecar — no source-level linkage; ClamAV clamd runs as a separate process and we communicate via the documented INSTREAM TCP protocol), Percona Server MongoDB (SSPL-1 + Percona additional grant — the additional grant nullifies SSPL §13 for our deployment shape because PSMDB powers the customer's own workload rather than being offered as a third-party database service). All three shipped as unmodified upstream OCI images, standard-protocol-only interaction, LICENSE/NOTICES preserved. This is the standard industry posture used by GitLab self-hosted, Gitea, Forgejo, and Harbor; no public legal challenge has been brought to date. Full legal analysis with grant text inline: LEGAL_POSTURE.md.

Explicitly rejected (for the record). Redis 8 (AGPL-3 licence complication → Valkey) · Grafana Labs stack Loki/Tempo/Mimir/Grafana (AGPL-3 bundling risk → VictoriaMetrics) · CloudQuery core (CQ Community Licence 2024) · Steampipe runtime (AGPL since v0.21) · Bitnami production charts (Aug-2025 relicence) · Sentry self-host (FSL/BUSL → GlitchTip) · Dragonfly (BSL). Details in our internal stack matrix.

4.2 Java alternative (as you mentioned)

Java (Spring Boot 3 + Spring Security + Micronaut) is equally stable and has deeper SAML/SCIM enterprise libraries. Trade: larger container images, slower cold start, heavier resource footprint for air-gapped deployments. Go wins on ops ergonomics; Java wins on library maturity in the identity space — but Keycloak is Java, so we already get that maturity as a sidecar without the footprint cost. Recommendation: Go, unless your team has deep Java and you plan to hire Java engineers for maintenance.

4.3 What we build in-house

pkg/tenancy (ancestor-ID resolution, scope inheritance) is folded into the BFF skeleton in §5.1 below.

5. Effort estimate — module by module

Assumption. Agent‑assisted team, senior engineers. "Engineer‑week" = 1 senior engineer × 5 working days, with agents pair‑coding. Estimates include: implementation, unit tests, integration tests against real services where possible, module‑level docs, and BFF route wiring. They exclude: seed‑data authorship (tracked separately), external threat modelling, WCAG audit, security pen‑test.

What changed in v2 (post-research). The research reconciled ~224 eng-weeks of OSS adoption savings against ~28.75 eng-weeks of in-house platform code. Adoption savings landed in the platform floor (now 22 ew vs original 22.5 — effectively flat; we didn't save much here, but we found gaps we would otherwise have hit in W7) and the summary modules (reduced by ~3 ew each for CSPM/SCM/IAM/observability-wiring thanks to official-SDK reuse + OSV/Prowler metadata donors). Net effect: total engineering is roughly unchanged (~80 ew), but risk is materially lower — we enter W0 with named libraries, pinned versions, signed container bases, and no "we'll figure this out" gaps.

5.1 Platform floor (shared, unavoidable) — v2

5.2 Detailed modules (SRS provides full spec) — v2

Savings from Keycloak adoption (~20 ew protocol implementations we don't write), TipTap + Gotenberg + prosemirror-changeset (~22 ew editor+diff+export we don't write), and Prowler metadata donor (~33 ew of rule content we don't author — savings land mostly in §5.3 Extended modules and seed-data SME, not here).

5.3 Summary-only modules (SRS is thin — design emerges) — v2

These are "summary depth" in the SRS. We need to design as we build. Estimates still carry 20% design overhead — but OSS leverage in CSPM/SCM/IAM/Supply-Chain reduces per-module effort ~25–40%.

5.4 Seed‑data authorship (GRC SME, not engineer)

5.5 Cross‑cutting not yet counted

5.6 Grand total — v2 (post-research)

Calendar implication (v2 — corrected to actual team shape):

The original SRS asked for "2 months, agent-assisted". Honest accounting requires we tell you the team shape we are bringing — not a hypothetical 13-FTE shop.

• Core team (W0–W14): 2 senior engineers — Ketan Khairnar (delivery + backend lead) and 1 senior architect (similar experience profile, security + backend). Both write production code; both review each other's commits. No project manager layer; no separate QA/DevOps headcount.
• Extended-phase addition (W7–W14, overlapping with later Core weeks): +1 to +2 mid/senior engineers brought in for the connector + scanner work, where the per-provider SDK shims parallelise cleanly. Peak team during W10–W14: 3–4 engineers.
• GRC SME (6 SME-weeks across the full programme): SecComply-named, not on our headcount.
• External security review (2 person-weeks): independent firm, fractional engagement at W11 + W14.

Eng-week math against this team:

• v1.0-Core (W0–W12): 80 ew / 2 engineers ≈ 40 weeks straight-through. Compressed to ~12 weeks via (a) 0.75× agent-assistance multiplier on mechanical work — CRUD, BFF wiring, seed loaders, test scaffolds, connector shims (~25 ew of the 80 net to ~19), (b) parallelisation of platform-floor and product-module streams (the gold-seam interfaces are designed for this — see §4.3), (c) extension contractors joining at W7 to start Extended work in parallel.
• v1.0-Extended (W7–W14, overlapping): 32 ew. Contractors ramp from W7, peak parallelism W10–W14. Most Extended modules complete by W14.
• Total programme: 12–14 weeks (Core ships RC at W12; Extended completes W14 at the latest), versus the original ask of "8 weeks for everything".

Why we are not committing to the original 8-week ask. Ketan + 1 architect, even agent-paired, cannot honestly deliver 80 ew of Core plus 32 ew of Extended in 8 weeks. Sustained 5 ew/wk per person is possible for short bursts, not across 8 weeks against security-sensitive code (crypto, session, authz, tenancy, audit-chain — all no agent autonomous commit zones per §11). Offering 8 weeks would be the kind of commitment that gets re-negotiated mid-build; we'd rather price the honest 12–14 week calendar now.

What this gives up vs. a hypothetical 13-FTE engagement: schedule float. If W6 surfaces an unanticipated load-test issue, we can't backfill with a fresh engineer the next Monday. The trade we make: the same two people own every line of the platform floor + Auth + AuthZ + audit-chain — no handoff cliffs in the security-sensitive zone. Extension contractors only touch the contractor-safe zone (per-provider SDK shims, CRUD modules) where the framework contracts they consume are frozen by W4.

What the research savings buy us at this team size: they become risk reduction rather than headcount reduction. We enter W0 with named libraries + pinned versions + signed bases, aggregate-distribution legal posture documented (no W11 legal surprise), tamper-evident audit log specified at mechanism level (closes REQ-SAFE-3), air-gap mirror patterns named, frozen interface boundaries for OSS-churn insulation, and a simplified-alternative observability stack for single-node customers.

6. Recommended delivery plan (12 weeks, v1.0‑Core)

This is what we can commit to with the 2-engineer core team. The original SRS asked for 2 months; honest delivery at this team size is 3 months for the Core scope below. Anything beyond is best‑effort.

6.1 Scope inside 12 weeks (v1.0‑Core, audit‑ready)

In:

• Full platform floor (§5.1)
• Item 1 — Auth + AuthZ (detailed, full spec)
• Item 6 — Vendor Management (detailed, full spec)
• Item 7 — Document Control / Policies (detailed, full spec, AI enrichment feature‑flagged off)
• #2 Compliance Readiness + #3 Atomic Control Library + #4 Evidence + #5 Risk — these are the compliance engine core. Without them, items 6/7 have nowhere to write auto‑evidence.
• #17 Integrations Management — the central control plane; needed even if only 1–2 providers light up in Core.
• #16 Dashboard & Action Items — thin v1 over whichever modules shipped.
• WCAG AA pass on shipped modules.
• Helm chart + Docker Compose + backup/restore playbook.

Out (moved to v1.0‑Extended, weeks 7–14, overlapping with later Core weeks):

• #9 CSPM (3 cloud connectors — each is a mini‑project)
• #10 SCM Security
• #11 Supply Chain
• #12 Vulnerability Assessment
• #13 Incident Management
• #14 IAM Governance / UAR
• #15 Internal Audit
• #8 Awareness Training
• Air‑gapped tarball + mirror instructions (Core ships online‑installable first)
• AI policy enrichment (feature‑flag off)

Defensible rationale. The client gets a deployable ISMS that: onboards an org, issues identities, enforces RBAC, runs compliance assessments against seeded frameworks, manages vendors with external questionnaires, manages policies with acknowledgements — the auditable core. Scanners and extended operational modules are easy to prioritise after Core is breathing.

6.2 Week‑by‑week (v1.0‑Core, 12 weeks at 2 senior engineers)

6.3 Weeks 7–14 (v1.0‑Extended, overlapping with later Core weeks)

Extension engineers join at W7 — once pkg/connector framework contract is frozen (W4 G-AuthZ gate) — and work in parallel with Core's W7–W12 module wave. They touch only the contractor-safe zone: per-provider SDK shims, CRUD modules, scanner check libraries. They do not touch crypto, session, authz, tenancy, or audit-chain code. Peak team during W10–W14: 3–4 engineers.

Why overlapping works. The platform-floor + Auth + AuthZ + Compliance Engine Core (W1–W6) produces frozen contracts: pkg/connector v1, pkg/audit event schema, RBAC middleware, evidence emit() API. Once those are frozen at W4–W6, contractors can build CSPM/SCM/IAM/VA modules against them without touching the security-sensitive code. The two seniors keep building Core (Vendor + Policy + Integrations + Dashboard) on the same locked contracts — no merge conflicts, no API churn.

Why this is not 8 FTE × 2 weeks. It's 2 seniors for 12 weeks plus 1–2 contractors for 8 weeks (W7–W14). Same eng-week budget, very different headcount profile, and crucially: same two people own every commit in the security-sensitive zone the entire programme.

7. Team shape

A small senior team for Core. A small contractor extension for the Extended phase. No project manager layer; no separate QA/DevOps headcount — those responsibilities sit on the seniors and are agent-paired where the work is mechanical.

Honest commitments at this team size:

• No headcount fall-back. If one of the two seniors is unavailable for an extended period (illness, family emergency), the calendar slips. We carry no bench.
• No QA team. Tests are written by the engineers writing the feature. Load test + WCAG audit are scheduled events at W11, owned by Ketan.
• No DevOps team. Helm + Compose + air-gap packaging owned by the architect, paired with Ketan for the air-gap tarball at W14.
• Design system + WCAG. Bootstrapped on shadcn/ui (WCAG-native) at W2; no separate designer headcount until W11 polish pass (where we contract in for ~3 days if needed).

What this is not: a 13-FTE delivery team. What it is: two senior engineers who own every line, plus contracted hands for the connector wave where the work is well-scoped.

8. Risk register (top 10)

9. Commercials — three options, sponsor-pickable

Not a formal SOW — scaffolding for the commercial conversation. All three options ship the same scope and the same team; they differ in how risk is shared between SecComply and us and how payment is sequenced. Blended senior engineering rate, programme-management uplift, and external security review fee are placeholders to be filled in once the sponsor names the rate band.

9.1 The volume being priced

Same in all three options.

The three options below differ on payment shape and risk allocation, not on this scope.

9.2 Option A — Fixed-bundle pricing

Two pre-priced bundles, simple PO, scope-locked.

Payment milestones tied to gates (see §6.1): 20% on G-Foundation (W2), 20% on G-AuthZ + G-Compliance-Core (W6), 20% on G-Module-Wave (W10), 20% on G-UAT + RC1 (W12), 20% on Extended sign-off (W14, only if Extended is contracted).

Risk shape. SecComply gets a known total cost. We carry the overrun risk: if W11 security remediation or load-test tuning eats more than the budgeted float, we absorb the cost. Scope changes are change-orders against the PO.

When this fits. Sponsor procurement requires a committed PO number, finance prefers cost certainty, sponsor doesn't want to track weekly invoices.

9.3 Option B — Monthly retainer

Predictable cost, mutual flexibility within the cap.

Each month is invoiced and paid in arrears (Net 14 from month-end). Scope is renegotiated at each month boundary — SecComply can flex modules in/out, or pause Extended after Month 2 if Core is enough.

Risk shape. Both sides share. SecComply pays for actual work done each month and can stop at any month boundary if the project is no longer needed.

When this fits. Sponsor wants flexibility on Extended scope (some modules may be deferred), procurement is comfortable with monthly recurring spend, both sides expect mid-stream scope conversations.

9.4 Option C — Bi-weekly deliverable + bi-weekly payment (recommended for trust-build)

Maximum de-risk for the sponsor. Every two weeks, a named shippable lands. Sponsor pays in arrears for the previous fortnight's accepted delivery. Sponsor can cancel at any fortnight boundary; their maximum exposure is two weeks of team cost.

Why bi-weekly, not weekly: with a 2-person core team, a one-week cycle is too tight to land meaningful security-reviewed work and prepare acceptance evidence and invoice cleanly. Two-week cycles match the natural rhythm of paired senior development against security-sensitive code.

Per-fortnight shippable (Friday delivery at the end of each two-week block):

Invoicing. Every other Friday: we submit the fortnight's deliverable + acceptance evidence. Sponsor reviews over the weekend and pays Monday at the agreed bi-weekly rate. If a fortnight's deliverable is rejected, we rework on the next fortnight's clock; the rejected fortnight is not paid until accepted.

Risk shape. Sponsor carries two weeks of exposure at any time. We carry the team-availability risk: the team is dedicated and cannot be redeployed mid-fortnight if the sponsor cancels, so we bear the cost of the fortnight already underway when cancellation lands.

When this fits. First engagement between SecComply and us, sponsor wants to verify delivery quality before committing to a long PO, sponsor's procurement allows fortnightly invoicing.

9.5 Why this team size, this calendar, this price shape

The honest answer: the team size is what we have, and the calendar is what that team can deliver. We're not a 13-FTE consultancy pricing a 13-FTE engagement; we're two senior engineers (plus contracted hands for the Extended phase) pricing what two senior engineers can ship.

The trade we make: you get senior eyes on every line in the security-sensitive zone — crypto, session, authz, tenancy, audit-chain — across the whole programme. No handoff cliffs, no junior engineer learning your domain on your time. The cost: 12–14 weeks instead of 8, and no headcount fall-back if a senior is unavailable for an extended period.

9.6 Our recommendation

Lead with Option C (bi-weekly deliverable + bi-weekly payment) for a first engagement. It maximises trust-build, makes the "show me you can ship" criterion explicit, and limits sponsor exposure to two weeks at any time. Fall back to Option A (fixed bundle) if sponsor procurement rigidly requires a committed PO number. Option B (monthly retainer) is the middle ground if the sponsor wants flexibility on Extended scope but doesn't want fortnightly invoicing overhead.

Apply your senior engineering rate to senior person-weeks and your contractor rate to contractor person-weeks. Add the GRC SME at SecComply's internal rate (or our GRC consultant rate if SecComply prefers). External security review is a fixed pass-through.

10. What we need from client to start W0

1. Answers to G-1 through G-10 (§3.1).
2. Signed-off stack (§4.1). Default is Go/TS + Keycloak + PSMDB + Valkey + MinIO + shared-postgres (Keycloak+GlitchTip) + TipTap + Gotenberg + ClamAV + VictoriaMetrics stack, per research. Java alternative available (§4.2).
3. Named GRC SME for seed-data authorship (§5.4) — 6 SME-weeks.
4. Access to at least one sandbox tenant per integration target (AWS, GCP, Azure, GitHub, GitLab, Entra, Google Workspace, Okta) by W7 (when contractors join for the Extended phase).
5. Design system source or confirmation we bootstrap shadcn/ui + Tailwind v4 (G-10).
6. Reference deployment target: single-node Docker Compose (SigNoz observability alt) or multi-node k8s (VictoriaMetrics stack) — for RC1 demo.
7. Licence-posture acknowledgement for aggregate-distribution of MinIO (AGPL-3), ClamAV (GPL-2), and Percona Server MongoDB (SSPL + Percona grant) — one-page legal memo in release (full text in LEGAL_POSTURE.md).
8. Scope commitment: v1.0-Core only (12 weeks, audit-ready) vs Core+Extended (12–14 weeks, overlapping). The original "all 17 modules in 8 weeks" ask is not deliverable at our team size and we won't commit to it — see §1 and §6 for the honest math.

11. our honest recommendation

• Commit to v1.0-Core in 12 weeks. This is deliverable at 2-senior-engineer pace, securable, and demos the platform's identity + compliance engine + vendor + policy spine — the parts that prove the architecture works. The original 8-week ask cannot be met honestly at this team size.
• Treat v1.0-Extended as weeks 7–14 overlapping, with 1–2 contractors joining at W7 once the connector framework contract is frozen at W4. Total programme: 12–14 weeks.
• Do not compress Auth/AuthZ. Everything else depends on it being right. Every week shaved here costs four weeks later.
• Adopt, don't build, where the protocol/corpus/library surface is broad. Keycloak for auth protocols, TipTap for rich-text, ClamAV for malware signatures, MinIO for S3, official SDKs for cloud APIs — 14 picks documented in our internal stack matrix with runner-ups and swap triggers.
• Build, don't adopt, where the rules are ours and the interface is narrow. pkg/authz, KeyStore, connector framework, mailer — ~28.75 eng-weeks of in-house code that insulates us from OSS churn via frozen interface boundaries.
• Two seniors own the security-sensitive zone end-to-end. Crypto, session, tenancy, authz, audit-chain — every commit reviewed by the other senior. Contractors only touch the contractor-safe zone (per-provider shims, CRUD modules) where the framework contracts are already frozen.
• Agents accelerate, but do not substitute. We will use them heavily for CRUD, BFF wiring, seed loaders, test scaffolds, docs, per-provider connector shims. We will not use them autonomously for crypto, session lifecycle, tenant isolation, authz pipeline, or audit-chain writer. Those stay human-owned, agent-paired.
• All numbers traceable. The eng-week counts, deployment topology, and licence posture in this document are sourced from internal research that we can walk through on request.

Done. Documented. Defended.

— Ketan Khairnar

Appendix A: Traceability quick‑map