🏦 NeoCore — Delivery Plan¶
Tier-1 Core Banking Go-Live for a Kerala Service Cooperative Bank — 8-Person Team, 16 Weeks
Supersedes the 10-Person / 3-Month Plan (NeoCore_3Month_Delivery_Plan.md)
Internal Document — Team Implementation Guide
Date: 2026-07-02
🎯 Purpose¶
This plan is a full replacement of the earlier 10-person / 3-month delivery plan. Two things changed at once, and both invalidate the prior plan rather than merely adjusting it:
- The client delivered the official legacy-to-microservice module mapping (34 modules), which becomes the single source of truth for scope and is reproduced in full below.
- The team shrank from 10 to 8 people — and critically, it lost its dedicated DevOps, Security, and DBA specialists. Those responsibilities now fold into a single Developer role. The timeline extends from 3 months to 4 months (16 weeks) to absorb this.
The client is a Service Cooperative Bank — a small, member-owned cooperative bank (PACS-class) in Kerala offering deposits, loans, share capital, and chit funds to local members. It is not a large commercial bank, and this plan is deliberately scoped to what such an institution actually needs to open its doors, not to the full 65-service catalog.
What 'go-live ready' means in this plan
All 18 Tier-1 modules built, integrated, regression-tested for financial accuracy, and demonstrated in a pilot-branch go-live demo by end of Week 16. Tier-2 is groomed and estimated for the next engagement; Tier-3 is explicitly parked.
📊 Executive Summary¶
| Dimension | Previous Plan | This Plan |
|---|---|---|
| Team size | 10 people | 8 people (1 Developer, 6 Domain Experts, 1 Tester) |
| Specialist roles | Dedicated DevOps / Security / DBA | None — all folded into the single Developer role |
| Timeline | 3 months | 4 months / 16 weeks |
| Scope basis | Internal service inventory | Official client module mapping (34 modules) |
| Go-live scope | Broad | 18 Tier-1 modules only |
| Deferred | Implicit | Explicit: 7 Tier-2 (Phase 2), 9 Tier-3 (parked) |
| Hardware | Unconstrained assumption | 8 laptops: 6× 16GB, 2× 8GB — shared-dev-server workflow |
| Observability | Full stack planned | Actuator only; Prometheus/Grafana is a Month-3 stretch goal |
pie title Module Distribution by Tier (34 modules)
"Tier 1 — Go-Live Core" : 18
"Tier 2 — Phase 2" : 7
"Tier 3 — Parked Backlog" : 9🧭 Module Tiering — The Core Judgment Call¶
The tiering below is the central decision of this document. It is driven by one question: what does a small Kerala Service Cooperative Bank actually need on day one to serve its members? — not by what a generic core-banking checklist says a bank should have.
Why these 18 modules are Tier 1¶
Tier 1 — Go-Live Core (18 modules): the non-negotiables
A Service Cooperative Bank cannot operate without:
- Membership & share capital — cooperative membership is share-based by law.
Share_msis not an optional product; it is the legal basis of every member relationship.Customer_msholds the member master. - Deposits — SB/CA (
Sbca_ms) and Time Deposits (Deposit_ms) are the daily bread of a cooperative society's liability side. - Lending — including KCC and paddy procurement —
Loans_advance_mscovers Kisan Credit Card, subsidy schemes, and paddy procurement financing. For Kerala's agricultural cooperative banks this is a defining, high-volume product line, not a niche feature. It goes live day one or the bank cannot serve its farming members. - Chit funds (MMBS/GDS) —
Chitty_ms. Chitties are an extremely common and expected product at Kerala cooperative societies; member demand is high and its absence would be conspicuous. It earns a Tier-1 slot that it would never get at a commercial bank. - Daily operations — teller/cashier (
Teller_system_ms), transactions (Transaction_ms), general ledger (Generalledger_ms), day-end and periodic interest processing (Periodic_Activity_ms). - Configuration & structure — product definitions (
Product_ms), interest rate and charges configuration, branch/HO structure (Bankandbranch_ms), system setup. - Security & reporting — RBAC (
security_ms) because this is a financial system, andReport_msbecause the Registrar of Cooperative Societies and RBI-aligned reporting obligations apply from day one. - Common/shared module —
Common_msunderpins everything above.
Tier 2 — Important but not blocking (7 modules)
Valuable, but a small society can open its doors without them and bring them online
once Tier 1 is stable. The clearest example: RTGS/NEFT (Payment_gateway_ms) —
many small societies route interbank payments through a sponsor bank initially,
so an in-house payment gateway is a Phase-2 improvement, not a launch blocker. The
same logic covers Clearing, Bills, Suspense, Alert/SMS, Inventory, and Supporting
Modules.
Tier 3 — Parked beyond this plan (9 modules)
Institutional and back-office functions that are not central to a small cooperative bank's member-facing operations, or that apply only to larger societies: Investment, Lockers, Borrowings, Trading/Indend, Room Rent, Board Administration/CRM, Fixed Assets, Accounts with Other Banks, Payroll. No commitment is made on these in this engagement.
📋 Official Module Reference Table¶
Reproduced from the client's legacy-to-microservice mapping spreadsheet, with two columns added: Tier (classification above) and Build Status.
Build Status is a first-class effort signal: modules whose old DB schema carries the
_db-linux suffix map onto services that already exist with real business logic in
the codebase today. The rest are net-new builds — either currently-empty scaffolds or
functionality that must be split out of existing services — and their effort estimates
are materially less predictable.
| Sl No | Module ID | Legacy Micro Service | New Micro Service Name | Old DB Schema (MS Old) | Module Name | Tier | Build Status |
|---|---|---|---|---|---|---|---|
| 1 | 1 | Generalledger_ms | ms_generalledger | generalledger-service_db-linux | General Ledger | 1 | Existing |
| 2 | 3 | Product_ms | ms_product | product-service_db-linux | Product Management | 1 | Existing |
| 3 | 17 | security_ms | ms_security | Security | 1 | New Build | |
| 4 | 19 | Interest_Rate_Configuration_ms | ms_interest_rate_configuration | Interest Rate Configuration | 1 | New Build | |
| 5 | 20 | Charges_configuration_ms | ms_charges_configuration | Charges Configuration | 1 | New Build | |
| 6 | 21 | Inventory_ms | ms_inventory | Inventory | 2 | New Build | |
| 7 | 16 | Alert_Management_ms | ms_alert_management | Alert Management, SMS | 2 | New Build | |
| 8 | 13 | System_Setup_ms | ms_system_setup | system-setup-service_db-linux | System Setup, Service Tax | 1 | Existing |
| 9 | 14 | Periodic_Activity_ms | ms_periodic_activity | periodicactivity-service_db-linux | Periodic Activity | 1 | Existing |
| 10 | 18 | Bankandbranch_ms | ms_bankandbranch | bankandbranch-service_db-linux | HO, Bank & Branch | 1 | Existing |
| 11 | 2 | Customer_ms | ms_customer | customer-service_db-linux | Customer | 1 | Existing |
| 12 | 7 | Payment_gateway_ms | ms_payment_gateway | RTGS/NEFT | 2 | New Build | |
| 13 | 9 | Teller_system_ms | ms_teller_system | Cashier System | 1 | New Build | |
| 14 | 10 | Clearing_ms | ms_clearing | Clearing | 2 | New Build | |
| 15 | 15 | Share_ms | ms_share | share-service_db-linux | Share | 1 | Existing |
| 16 | 4 | Sbca_ms | ms_sbca | SB/CA | 1 | New Build | |
| 17 | 6 | Deposit_ms | ms_deposit | deposit-service_db-linux | Time Deposits | 1 | Existing |
| 18 | 5 | Loans_advance_ms | ms_loans_advance | Loans/Advances, KCC/Subsidy, Paddy Procurement | 1 | New Build | |
| 19 | 8 | Transaction_ms | ms_transaction | transaction-service_db-linux | Transaction | 1 | Existing |
| 20 | 25 | Chitty_ms | ms_chitty | MMBS, GDS | 1 | New Build | |
| 21 | 27 | Suspense_ms | ms_suspense | Suspense | 2 | New Build | |
| 22 | 12 | Bills_ms | ms_bills | Bills | 2 | New Build | |
| 23 | 22 | Investment_ms | ms_investment | Investment | 3 | New Build | |
| 24 | 29 | Borrowings_ms | ms_borrowings | Borrowings | 3 | New Build | |
| 25 | 23 | Lockers_ms | ms_lockers | Lockers | 3 | New Build | |
| 26 | 11 | Supporting_modules_ms | ms_supporting_modules | Supporting Modules | 2 | New Build | |
| 27 | 30 | Trading_ms | ms_trading | Indend | 3 | New Build | |
| 28 | 34 | Roomrent_ms | ms_roomrent | Room Rent | 3 | New Build | |
| 29 | 37 | Board_administration_ms | ms_board_administration | CRM Modules | 3 | New Build | |
| 30 | 38 | Fixedassets_ms | ms_fixedassets | FIXEDASSETS | 3 | New Build | |
| 31 | 39 | Otherbank_casb_ms | ms_otherbank_casb | Accounts with Other Banks | 3 | New Build | |
| 32 | 41 | Payroll_ms | ms_payroll | Payroll | 3 | New Build | |
| 33 | 99 | Report_ms | ms_report | Reports | 1 | New Build | |
| 34 | — | Common_ms | ms_common | common-service_db-linux | Unclassified / Common | 1 | Existing |
Tier-1 build-status breakdown — 10 Existing vs 8 New Build
| Build Status | Tier-1 Modules | Effort implication |
|---|---|---|
| Existing (real business logic today) | General Ledger, Customer, Product, System Setup, Periodic Activity, Bank & Branch, Share, Time Deposits, Transaction, Common | Extension and hardening work — comparatively predictable |
| New Build (empty scaffold or split-out) | Security, SB/CA, Loans/Advances, Teller/Cashier, Interest Rate Config, Charges Config, Chitty, Reports | Ground-up build — estimates carry materially more uncertainty (see Risk 5) |
👥 Team Structure — 8 People¶
Leaner team, no specialists — read this before the org chart
This is a smaller team than the previous 10-person plan, and it has no dedicated DevOps engineer, no dedicated Security engineer, and no dedicated DBA. All three of those responsibilities fold into the single Developer role. This concentration is the single biggest delivery risk in this plan — see the Risks section.
flowchart TB
DEV["🔧 Developer<br/>Full-stack / Integration Lead<br/>security_ms · api-gateway · shared-libs<br/>CI/CD · Flyway/orafce · shared dev server<br/>ALL screen-to-API integration"]
T["🧪 Tester<br/>E2E regression · financial accuracy<br/>GL postings · interest · loan schedules<br/>UAT facilitation (Month 4)"]
subgraph DE["6 Domain Experts — AI-assisted screens + business logic"]
DE1["DE-1 Member & Foundation<br/>Customer · Security screens · Common"]
DE2["DE-2 Deposits & Accounts<br/>SB/CA · Time Deposits"]
DE3["DE-3 Loans & Advances<br/>Loans/Advances · KCC · Paddy Procurement"]
DE4["DE-4 Transactions & Teller<br/>Transaction · Teller/Cashier"]
DE5["DE-5 Ledger, Share & Product Config<br/>GL · Share · Product · Interest Rate · Charges"]
DE6["DE-6 Setup, Branch, Periodic, Chitty, Reports<br/>System Setup · Bank+Branch · Periodic Activity · Chitty · Report"]
end
DE1 -->|hand off for integration| DEV
DE2 --> DEV
DE3 --> DEV
DE4 --> DEV
DE5 --> DEV
DE6 --> DEV
DEV -->|integrated builds on shared dev server| T🔧 The Developer (full-stack / integration lead)¶
Owns everything infrastructure-adjacent, because nobody else can:
| Responsibility | Scope in this plan |
|---|---|
security_ms build-out |
JWT + RBAC engine (Domain Experts own only the screen/policy side) |
| API gateway & shared libraries | Cross-cutting plumbing for all Tier-1 services |
| CI/CD | Deliberately lightweight: GitHub Actions build + single shared dev-server deploy. No elaborate multi-environment pipeline |
| Database governance | Flyway migration governance; orafce-extension verification; package-schema gaps — AI-assisted, flagged as a risk given no dedicated DBA |
| Integration | Wires every Domain Expert's screens to their service APIs |
| Shared dev server | Runs the one Docker Compose dev/integration server that mirrors the full Tier-1 stack |
🧪 The Tester¶
End-to-end regression across all Tier-1 modules, with financial accuracy first: GL postings, interest calculation, loan repayment schedules, deposit maturity/interest. Facilitates UAT in Month 4.
🧑💼 The 6 Domain Experts¶
Each owns a cluster of Tier-1 modules and does AI-assisted screen + business-logic work following the established team pattern — explain → validate → implement → verify — then hands off to the Developer for integration.
| Modules | Customer_ms (2) · security_ms (17) · Common_ms |
| Build status | Customer & Common: Existing · Security: New Build |
| Role split | Owns the screen/policy side of security — the Developer builds the JWT/RBAC engine |
| Why this cluster | Member master data and shared foundations that nearly every other Tier-1 module depends on — this work front-loads Month 1 |
| Laptop | 16GB |
| Modules | Sbca_ms (4) · Deposit_ms (6) |
| Build status | SB/CA: New Build · Time Deposits: Existing |
| Why this cluster | The liability side of the balance sheet — savings/current accounts plus time deposits, the society's daily bread |
| Laptop | 8GB — smallest owned-service count makes the lightest local footprint |
| Modules | Loans_advance_ms (5) — sole module, sole owner |
| Build status | New Build |
| Why single-owner | The highest-complexity, highest-regulatory-sensitivity module in the plan: KCC, subsidy schemes, and paddy procurement financing. It warrants one person's undivided focus |
| Risk note | Single-owner also means no backup — see Risk 3 |
| Laptop | 8GB — one owned service, lightest concurrent local load |
| Modules | Transaction_ms (8) · Teller_system_ms (9) |
| Build status | Transaction: Existing · Teller/Cashier: New Build |
| Why this cluster | The transaction engine and the cashier front end are the most integration-chatty pair in the system — every other module posts through them |
| Laptop | 16GB — that chattiness demands headroom for local integration debugging |
| Modules | Generalledger_ms (1) · Share_ms (15) · Product_ms (3) · Interest_Rate_Configuration_ms (19) · Charges_configuration_ms (20) |
| Build status | GL, Share, Product: Existing · Interest Rate Config, Charges Config: New Build |
| Why this cluster | The accounting spine plus the configuration layer that prices every product — five services, the most owned by any Domain Expert (tied with DE-6) |
| Laptop | 16GB — five owned services means the most concurrent local processes |
| Modules | System_Setup_ms (13) · Bankandbranch_ms (18) · Periodic_Activity_ms (14) · Chitty_ms (25) · Report_ms (99) |
| Build status | System Setup, Bank & Branch, Periodic Activity: Existing · Chitty, Report: New Build |
| Why this cluster | Foundational master data (Month 1) plus the day-end/interest engine, the chit-fund product Kerala members expect, and the Registrar/RBI-aligned reporting — five services |
| Laptop | 16GB — five owned services, same reasoning as DE-5 |
💻 Hardware & Environment Strategy¶
Available hardware: 8 laptops — 2× 8GB RAM, 6× 16GB RAM.
The constraint, stated plainly: 8GB is not enough to comfortably run a multi-service Docker Compose stack — Postgres + Kafka + Redis + multiple JVM services + an IDE — at the same time. The environment strategy must route around this, not hope it is fine.
Environment policy — the shared-server workflow
- ONE shared Dev/Integration server (the existing demo/dev server) runs the full Tier-1 stack at all times.
- Only the Developer's 16GB laptop mirrors the full stack locally, for integration debugging.
- Every Domain Expert runs only their own owned service(s) + the frontend locally, and points every other dependency — other services, shared Postgres, Kafka, Redis — at the shared dev server.
- Result: an 8GB laptop is workable for any module, because nobody except the Developer ever runs the whole stack locally.
Laptop allocation¶
| Laptop | Assigned to | Rationale |
|---|---|---|
| 16GB | Developer | Must mirror the full Tier-1 stack locally for integration debugging |
| 16GB | Tester | Runs substantial parts of the stack for regression testing |
| 16GB | DE-1 | Foundation cluster (Customer, Security screens, Common) touches everything |
| 16GB | DE-4 | Transaction + Teller — the most integration-chatty service pair |
| 16GB | DE-5 | Owns 5 services — most concurrent local processes among Domain Experts |
| 16GB | DE-6 | Owns 5 services — same reasoning as DE-5 |
| 8GB | DE-2 | Owns 2 services — light local footprint even before the shared-server policy |
| 8GB | DE-3 | Owns 1 service — the lightest local footprint on the team |
Dependency created by this policy
The shared dev server becomes load-bearing for the whole team's daily work — and entirely load-bearing for DE-2 and DE-3 on 8GB machines. See Risk 2.
🗓️ Timeline — 16 Weeks, 4 Monthly Phases¶
The previous plan's 3-month timeline assumed 10 people including specialists. With 8 people and the specialist roles folded into one Developer, the timeline extends to 4 months (16 weeks): 2026-07-06 → 2026-10-23.
gantt
title NeoCore Tier-1 Delivery — 16 Weeks (2026-07-06 to 2026-10-23)
dateFormat YYYY-MM-DD
axisFormat %d %b
excludes weekends
section M1 Foundation
Shared dev server + env policy (Dev) :m1a, 2026-07-06, 2w
Branch consolidation (Dev) :m1b, 2026-07-06, 1w
Build-only CI - GitHub Actions (Dev) :m1c, 2026-07-13, 2w
security_ms JWT-RBAC skeleton (Dev) :m1d, 2026-07-13, 3w
orafce + Flyway package-schema gaps (Dev) :crit, m1e, 2026-07-20, 2w
Customer + Common master data (DE-1) :m1f, 2026-07-06, 4w
System Setup + Bank and Branch (DE-6) :m1g, 2026-07-06, 4w
Legacy analysis + module specs (DE-2/3/4/5) :m1h, 2026-07-13, 3w
section M2 Core Accounts and Ledger
SB-CA + Time Deposits (DE-2) :m2a, 2026-08-03, 4w
GL, Share, Product, Interest, Charges (DE-5) :m2b, 2026-08-03, 4w
Loans-Advances build begins (DE-3) :m2c, 2026-08-03, 4w
Transaction + Teller build begins (DE-4) :m2d, 2026-08-03, 4w
Auto-deploy to shared server + Actuator (Dev) :m2e, 2026-08-03, 2w
Integrate DE-1 and DE-6 modules (Dev) :m2f, 2026-08-17, 2w
Financial-accuracy test design (Tester) :m2g, 2026-08-10, 3w
section M3 Transaction Engine and Periodic
Complete Transaction + Teller (DE-4) :m3a, 2026-08-31, 3w
Complete Loans incl KCC + Paddy (DE-3) :crit, m3b, 2026-08-31, 4w
Periodic Activity, Chitty, Report (DE-6) :m3c, 2026-08-31, 4w
Regression pack - GL, interest, loans (Tester):m3d, 2026-08-31, 4w
Security hardening - RBAC + audit log (Dev) :m3e, 2026-09-07, 3w
Prometheus + Grafana STRETCH GOAL (Dev) :m3f, 2026-09-14, 2w
section M4 Hardening and Go-Live
Full regression + defect fixing (All) :m4a, 2026-09-28, 3w
UAT across Tier-1 (Tester + DEs) :m4b, 2026-10-05, 3w
Prod deploy workflow + approval gate (Dev) :m4c, 2026-09-28, 2w
Tier-2 backlog grooming (Dev + DEs) :m4d, 2026-10-12, 2w
Pilot-branch go-live demo :milestone, m4e, 2026-10-23, 0dMonth 1 (Weeks 1–4) — 🏗️ Foundation¶
| Role | Deliverables |
|---|---|
| Developer | Shared dev server stood up under the hardware policy; branch consolidation — collapse the current sprawl (NeoCore, develop, Dev, Dev-Nithya, QA, shared) to main / develop / feature; security_ms JWT/RBAC skeleton started; build-only CI (GitHub Actions, no deploy yet) across the repos; orafce-extension verification and Flyway package-schema gap work begun in parallel |
| DE-1 | Customer + Common foundational master data — nearly every other Tier-1 module depends on these |
| DE-6 | System Setup + Bank & Branch foundational master data — same dependency logic |
| DE-2 / DE-3 / DE-4 / DE-5 | Legacy analysis and module specifications for their clusters (explain → validate phase of the team pattern) |
| Tester | Test-strategy groundwork; familiarization with financial flows |
At-risk from day one
The orafce/Flyway work is AI-assisted with no dedicated DBA. It is scheduled in Month 1 precisely so that if it slips, there is runway — but it is flagged at-risk from the outset (see Risk 6).
Month 2 (Weeks 5–8) — 💰 Core Accounts & Ledger¶
| Role | Deliverables |
|---|---|
| DE-2 | SB/CA + Time Deposits built |
| DE-5 | General Ledger, Share, Product, Interest Rate Configuration, Charges Configuration built |
| DE-3 | Loans/Advances build begins |
| DE-4 | Transaction/Teller build begins |
| Developer | Basic auto-deploy on merge to the single shared dev server; Spring Boot Actuator health/metrics endpoints turned on everywhere (already a dependency in every pom) |
| Tester | Financial-accuracy test design (GL postings, interest computation, schedules) |
Observability decision — named, not silently dropped
Actuator is the only observability this cycle. There is explicitly no Prometheus/Grafana/ELK stack in Month 2 — that is out of scope for a one-developer team and is a deferred item stated out loud, not an omission.
Month 3 (Weeks 9–12) — ⚙️ Transaction Engine & Periodic Activity¶
| Role | Deliverables |
|---|---|
| DE-4 | Transaction/Teller complete |
| DE-3 | Loans/Advances complete, including KCC and paddy procurement financing logic |
| DE-6 | Periodic Activity (day-end/interest run), Chitty (MMBS/GDS), and Report complete |
| Tester | Regression pack running — GL postings, interest computation, and loan repayment schedules first, since those carry the highest financial-correctness risk |
| Developer | Security hardening pass: RBAC enforced per screen, audit logging on every financial transaction |
Stretch goal — explicitly not a commitment
Only if bandwidth allows, the Developer stands up a single lightweight Prometheus + Grafana instance on the shared server in Weeks 11–12. This is a stretch goal. If it does not happen, Months 1–4 run on logs + Actuator alone.
Month 4 (Weeks 13–16) — 🚀 Hardening & Go-Live Readiness¶
| Role | Deliverables |
|---|---|
| Tester + all 6 DEs | Full regression pass and UAT across all Tier-1 modules — each Domain Expert fixes their own module's defects |
| Developer | Production deploy workflow with a manual approval gate |
| Whole team | Pilot-branch go-live demo (Week 16 milestone) |
| Developer + DEs | Tier-2 backlog groomed and estimated for the next engagement: Payment Gateway (RTGS/NEFT), Clearing, Bills, Suspense, Alert Management/SMS, Inventory, Supporting Modules |
| — | Tier-3 modules explicitly parked — no commitment |
⚠️ Risks¶
Risk 1 — No dedicated DevOps / Security / DBA role (THE top risk)
The single Developer is simultaneously the CI/CD engineer, the security engineer, the DBA, the integration lead, and the shared-server operator. This makes one person a bottleneck and a single point of failure for every infrastructure-adjacent workstream at once. If the Developer is unavailable for even a week, integration, deployment, security, and database governance all stall together. This is the single biggest risk in this plan and the primary reason the timeline extended from 3 to 4 months.
Risk 2 — Hardware ceiling forces shared-server dependence
The 2× 8GB laptops make a full local stack impossible for DE-2 and DE-3, so the whole workflow leans on the shared dev/integration server. If that server goes down, two team members are blocked entirely and everyone else is degraded.
Risk 3 — Loans/Advances is a single-owner module
DE-3 solely owns the most regulation-sensitive product line in the system — KCC, subsidy schemes, paddy procurement financing. There is no backup if DE-3 is unavailable.
Risk 4 — No observability stack until (at best) a Month-3 stretch goal
Any production-like issue in Months 1–3 gets diagnosed with logs and Actuator endpoints only. Mean-time-to-diagnose will be longer than anyone will enjoy.
Risk 5 — Eight Tier-1 modules are net-new builds
security_ms, Sbca_ms, Loans_advance_ms, Teller_system_ms,
Interest_Rate_Configuration_ms, Charges_configuration_ms, Chitty_ms, and
Report_ms are not extensions of working code — they start from empty scaffolds
or must be split out of existing services. Effort here is materially less
predictable than for the ten Existing modules.
Risk 6 — Inherited database-migration gaps
The orafce extension is unverified, several PL/pgSQL package schemas are not yet in Flyway, and 640+ financial functions have zero automated test coverage. These gaps predate this plan and are not fully solved by it — they are inherited risk now carried by a leaner team with less specialist bandwidth to close them, not more.
Mitigations
- Risk 1: CI/CD kept deliberately minimal (build + one deploy target) so the Developer's infrastructure load is bounded; heavy platform work explicitly descoped (see next section). Everything the Developer builds is scripted and documented so it is at least transferable in an emergency.
- Risk 2: Shared server treated as production-grade from Week 1 — scripted rebuild via Docker Compose, nightly DB dumps, and the Developer's laptop as a documented warm fallback for the two 8GB users.
- Risk 3: DE-3's explain → validate artifacts (module specs, business-rule docs) are written down and reviewed by DE-2 as a reader, creating a minimal cold-standby understanding of the loans domain.
- Risk 5: New-build modules get their specs done in Month 1 (analysis phase) so scope surprises surface with 12 weeks of runway, not 2.
- Risk 6: orafce/Flyway work is scheduled in Month 1, AI-assisted, and its status is reported weekly so a slip is visible immediately rather than at day-end testing in Month 3.
🚫 What This Plan Deliberately Does NOT Include¶
Explicit, communicated trade-offs of the 8-person team — not oversights
| Descoped item | Why it is out | Where it lands |
|---|---|---|
| Full observability stack (Prometheus/Grafana/ELK, distributed tracing) | Out of reach for a one-developer infrastructure role; Actuator suffices to reach go-live | Prometheus+Grafana is a Month-3 stretch goal only; the full stack is a future engagement |
| Dedicated security engineering (SAST, dependency scanning, penetration testing) | No security specialist on the team; the Developer's Month-3 hardening pass covers RBAC + audit logging only | Future engagement, ideally with a specialist |
| DBA-led schema completeness work (orafce closure, full package-schema migration, test coverage for 640+ DB functions) | No DBA; Month-1 work is AI-assisted triage, not closure | Inherited risk, carried visibly (Risk 6); needs specialist time later |
| All Tier-2 modules (7) | Not blocking go-live for a small society | Groomed and estimated in Month 4 for the next engagement |
| All Tier-3 modules (9) | Not central to member-facing operations of a small cooperative bank | Parked — no commitment |
Internal Document — NeoCore Delivery Planning. Supersedes NeoCore_3Month_Delivery_Plan.md (2026-07-02, 10-person plan). Scope authority: client legacy-to-microservice module mapping spreadsheet, received 2026-07-02.