Built Word Documents (.docx):
Spensara Overview (.docx)
Capability Assessment (.docx)
Brink POS Ingestion Analysis (.docx)
The Borg Ingestion Architecture (.docx)
Categories
Overview & Capability Assessment (4)
Executive system summary, architecture overview, gap analysis, capability assessment, and master file index.
Spensara capability assessment: in-house, Euvic, another firm, or a mix
Prepared 2026-10-23. Based on the gap analysis in SPENSARA-OVERVIEW.md and a read of the KDSAI codebase. The question was left open on purpose; the answer below comes from the evidence, workstream by workstream.
1. What the codebase actually demands
| Measure | Finding | What it implies |
|---|---|---|
| Size | ~119,000 lines of C# (1,029 files), ~14,000 lines in the Laravel/Vue front end, ~2,300 lines of warehouse SQL, 377 Markdown docs on main | Mid-sized product; too big to "just read", small enough for a two-to-three person team |
| Languages | C# / .NET 10 (backend, agents, ETL), PHP 8.3 / Laravel 13 (front end), Vue (dashboard branch), SQL for Redshift | Two very different skill sets; the PHP side matches Tom's existing Slacan and Edge work, the .NET side does not |
| Frameworks | .NET Aspire 13, EF Core, TickerQ, Microsoft Agent Framework, Keycloak, Parquet.Net | Modern and well-structured, but several are niche (Aspire, TickerQ, Agent Framework) |
| Tests | 96 test files, ~458 test cases (TUnit and xUnit), Testcontainers Postgres, live tests for ETL and CDC; CI builds and tests every pull request | Reasonable safety net for the backend; front end is barely tested |
| Infrastructure as code | None in this repo; ECS services, ECR, IAM roles, Redshift, SQS, S3 and Bedrock are provisioned elsewhere (separate devops repos) | Biggest unknown. Whoever runs production must own those repos and the AWS account |
| AWS surface | ECS, ECR, S3, SQS FIFO (cross-account), Redshift Serverless (database per tenant), Bedrock, Athena/Glue (planned), IAM roles assumed from GitHub Actions | Broad. Mistakes cost money and can leak tenant data |
| Data engineering depth | Five-stage ETL framework with checkpoints, replay and quarantine; 31 Brink staging tables to 7 curated; CDC ordering; schema evolution per tenant | Real data engineering. Changing it safely needs someone who understands batches, idempotency and Redshift behaviour |
| Working method | Spec files per feature (specs//TASK.md) and agent guidance (AGENTS.md, .agents/skills/) | Built to be extended by coding agents working from specs. This favours an in-house team that uses the same method |
| Branch state | main frozen since 2026-06-24; five large unmerged branches, one marked "TO REVIEW" | Someone with context has to land or retire this work first |
2. What the in-house team brings
- Tom: product owner and domain expert (POS, KDS, Brink, franchise operators), strong PHP / XAMPP / MariaDB background, owns customer relationships.
- Sage and the other assistants: can read and change code at speed, follow spec files, run tests, write docs, and operate AWS through sanctioned tools. They have already cloned and run the stack on spensara-sandbox and found two upstream bugs.
- Limits: no dedicated senior .NET or data engineer on staff; no on-call rotation; AWS access for assistants is still being set up (durable access is an open item); production infrastructure repos have not been reviewed; Tom's time is the bottleneck for approvals.
3. Recommendation by workstream
| Workstream | Recommended owner | Why |
|---|---|---|
| A. Front-end redesign to Tom's taste | In-house | Laravel/Blade/Vue is the closest match to Tom's skills; the front end is a thin backend-for-frontend with no database, so redesign risk is contained. Tom can iterate visually with the assistants daily instead of through tickets. Keep the API contract unchanged. |
| B. Customer onboarding into the environment | In-house, after a one-time hardening pass | The steps are known (section 4 of the overview) and mostly API calls plus checks. Write them as a runbook and a script, and have the assistants run them. Prerequisite: the async provisioning work (gap 3) merged and working, and durable AWS access. |
C. Land the unmerged branches and stabilise main | Euvic, fixed scope and short | Only the authors can say safely which of life-cycle, extract-raw-xml, kds_cdc_improvments, feature/fleet-import and tenat-admin should merge. Ask for a 2–4 week, fixed-price close-out: merge or retire every branch, green CI, written handover. This is where their context is worth the slowness. |
| D. Brink scheduling to production, curated model completion, more POS sources | Hybrid: Euvic finishes in-flight ETL items; in-house takes new adapters afterwards | The adapter framework is designed for adding sources by catalog. Once one more adapter is done by the book, the assistants can copy the pattern under review. Keep Euvic on call for ETL framework changes, not for each new source. |
| E. AWS infrastructure, security and operations | Outside specialist (part-time) plus in-house | This is the riskiest area and the least visible (no infrastructure as code in this repo). Bring in an AWS-focused contractor or small firm for a short audit: put infrastructure into code, set alarms and cost limits, verify tenant isolation, set up secrets rotation. Then run it in-house with the runbooks. Does not need Euvic. |
| F. Ongoing updates and changes | In-house first, with a retained reviewer | With specs, tests and CI already in place, the assistants can handle most changes. Keep a small monthly retainer (Euvic or the AWS firm) for code review on ETL and infrastructure pull requests until the in-house team has a track record. |
| G. Edge appliance and its sync to the cloud | In-house | Debian, Apache 2.4 + PHP 8.4 FPM, MariaDB and Cockpit on the Intel 9550 is Tom's stack, and it is not in Euvic's codebase. |
4. Overall answer
A hybrid, weighted toward in-house:
- Now (weeks 0–4): Euvic does a fixed-scope branch close-out and handover (C). In parallel, in-house starts the front-end redesign (A) and writes the onboarding runbook (B). An AWS contractor audits infrastructure (E).
- Next (weeks 4–12): In-house onboards the first real customer with the runbook, takes over ETL completion with Euvic reviewing (D), and moves infrastructure into code with the contractor.
- Steady state: In-house owns the product. One retained reviewer for ETL and AWS changes. Euvic only for framework-level changes, by request.
Do not hand the whole product back to Euvic: their pace is the stated problem, and most remaining work (front end, onboarding, edge, new adapters) does not need their context. Do not hire a new firm to take over everything: they would spend months learning what Euvic already knows, and the code is built to be extended in-house from specs.
5. Risks and what would change this answer
- If the infrastructure repos turn out to be fragile or hand-built, increase the outside AWS share (E) and slow onboarding.
- If Euvic will not agree to a fixed-scope close-out, a new firm (or the assistants under a senior .NET reviewer) must triage the branches instead; budget 4–6 extra weeks.
- If more than three customers sign before the hardening pass, bring in temporary data engineering help rather than onboarding by hand.
- Durable AWS access for the assistants is a hard prerequisite for B, D and F.