Independent Delivery Audit · Confidential
Scope, Delivery & Traceability Assessment
Subject: “Tender Manager” — B2B purchasing-optimization & tendering platform (EXTECO optimization s.r.o.)
A substantial, working tender-management platform exists and is verified in code, frequently with passing automated tests. The complete tender lifecycle is delivered end-to-end. Measured against the original grant text, delivery is uneven — the grant’s flagship “AI avatar” is not evidenced, while substantial AI was delivered in a different shape — and the majority of delivered effort (~55 %) traces to scope defined after grant approval. The project’s own status documentation is the weakest artifact of the engagement.
Sources: 01_requirements_timeline.md · 02_traceability_matrix.md · 04_extra_scope.md §1 · 06_executive_summary.md §1–2
A real product exists: ~82,000 hand-written lines across two codebases implementing tender creation, supplier offers, negotiation rounds, AI-assisted evaluation, winner selection and document generation, plus a supplier ecosystem, admin back-office, multi-tenancy and two-language support. Against the original grant: 4 of 14 themes delivered, 6 partial, 3 not evidenced, 1 not verifiable. ~55 % of delivered engineering effort traces to scope defined after the grant. Documentation overstates and understates delivery, conflicts with itself, and cannot express the frontend/backend split-states that proved to be the most important delivery facts. A fully clean verdict is blocked by a defined, resolvable set of ambiguities (phase 05).
Derived: 4 delivered + 6 partial (×0.5) of 13 code-verifiable grant themes. 03 §1
Derived: 11 delivered + 19 partial (×0.5) of 47 register rows; 12 of 17 missing rows carry the register’s own deferral marker. 03 §2–3
Qualitative estimate from audit findings: clean backend architecture, 76 test files, 6 live integrations — against zero frontend tests, convention-based tenant scoping, and isolated dead code. 03 §G · 06 §3
Qualitative estimate from audit findings: status errors in both directions, 6 self-conflicting rows, no dates/approvals, format cannot express FE/BE split. 02_high_risk_findings · 06 §7
A measure, not a score: 43% planning docs + 10% Trello-only + 1% untraceable, by weighted effort. 04 §4
Source: 06_executive_summary.md §1 (Headline Findings), figures from 03/04.
The project’s scope passed through four documented layers — each adding definition the previous one lacked — plus a small undocumented layer found only in code. The grant-mandated technical specification (due 04/2025) is absent from the audit corpus, which made the undated register the de facto specification.
Original grant 8% · Decomposition 37% · Planning 43% · Trello 10% · Untraceable 1%
Method: feature weights S=1 / M=3 / L=8 / VL=20 over ~40 implemented features. Source: 04_extra_scope.md §2–4.
Counts only capabilities the grant text explicitly names (market pipeline, AI recommendation, multi-language). The right lens for literal grant-text compliance; low mainly because the grant names so little.
Accepts the tender platform, evaluation suite and dashboards as natural concretizations of grant themes. The right lens for judging whether the funded intent was pursued.
Both readings support the same conclusion from different directions: the delivered system is far more specific than the approved text, and more than half of delivered effort is documented only in artifacts created after approval. Note the complement: original scope is simultaneously a minority share of what was built and itself incompletely delivered — independent facts, both true. 04 §4 · 06 §6
What was built that the approved grant text does not cover: ~55 % of delivered effort by weighted estimate — ~43 % from in-project planning documents (register / working doc), ~10 % from board-only Trello scope, ~1 % with no documented source at all. Per the audit charter this is a traceability statement, not a judgment — most of this work was plainly necessary to ship a working product.
| # | Feature | Scope source | Size | Footprint (evidence one-liner) |
|---|---|---|---|---|
| 1 | Admin CRM (companies, verification, users, contacts) | Planning | Very Large | ~3,000+ LOC: 687-line controller, 8 admin pages, 5 test files — register recorded it “Nie” |
| 2 | Auth & onboarding (sign-up wizard, OTP, invitations, profile) | Planning | Very Large | ~3,500+ LOC FE wizards + BE auth controllers + 8 test files; documented only as the word “Login” |
| 3 | Personal meetings module | Planning | Large | 2 tables / 3 migrations, scheduled deadline job, 950+ FE LOC, 2 test files |
| 4 | Sample testing module | Planning | Large | 5 migrations, 6 mailables, ~900 FE LOC, 2 test files (lifecycle later reduced) |
| 5 | Document generation (DOCX/XLSX) | Planning | Large | 791 LOC of custom generators + 3 binary templates + closed-screen UI + winner-mail attachment |
| 6 | Target-price rounds | Planning | Large | Dedicated round type + action + mails + customer/supplier UI + 2 test files |
| 7 | MERK registry enrichment + validity check | Planning | Large | 469-line API client, cache table, 4 trigger points, admin UI |
| 8 | Multi-tenancy / company context | Planning | Large | Middleware + pivot + cross-cutting scoping of every query (working doc: two words) |
| 9 | In-app notification center | Planning | Large | Table + 5 endpoints + 12 trigger sites + page + unread badge |
| 10 | Group templates / catalog | Planning | Large | Template tables, 2 controllers, save/apply UI, 2 test files |
| 11 | Alternative offers | Trello-only | Large | Dedicated controller/action/flags woven through offers, results & samples; 5 test files — the largest board-only effort |
| 12 | Subscriptions / tiers / feature gating | Trello-only | Large | 6 migrations, 20-feature entitlement enum enforced in 3 controllers, pricing/plan pages |
| 13 | Marketing website | Trello-only | Large | 1,008-line landing + reCAPTCHA contact pipeline + admin inbox |
| 14 | Admin global overview + create-for-company | Planning | Medium | Cross-company project lists + admin tender creation — register recorded it “Nie” |
| 15 | Public tenders + category matching | Planning | Medium | Visibility flags + matching query + category UI |
| 16 | Geo/country supplier targeting | Planning | Medium | Geo-unit tables + tree select + invite filter |
| 17 | Attachments/media infrastructure | Planning | Medium | Media library on 4 models + download/stream controller + dialogs |
| 18 | Roles & member management | Planning | Medium | Role enum + pivot flags + dialogs + endpoints |
| 19 | Savings predictions | No trace | Medium | ~700 LOC feature with no documented requirement anywhere |
| 20 | Offer autosave (backend only) | Planning | Medium | 249-line action + migration + passing test; frontend never calls it |
Ranked by weight, then measured footprint. “Outside” = planning + Trello-only + untraced (everything not traceable to the grant text even as a decomposition). Next in line: magic-link access, reference data, notification preferences. Source: outputs/04_extra_scope.md §3.
Savings predictions appears in no grant text, register row, working-doc line or Trello card — yet it is the most direct code use of the “12 years of historical data” asset the grant emphasizes. Smaller untraced items: multi-company-per-user, responsible-user assignment, the 8-state company status model.
The two largest out-of-scope deliveries — the admin CRM and global overview — plus the backend autosave are recorded as “Nie” in the register. Out-of-scope delivery and documentation understatement overlap heavily (see Documentation Reliability).
Source: outputs/04_extra_scope.md §2–§5 · outputs/06_executive_summary.md §6.
Fifteen capability areas, each verified by opening the implementing code (never by file names alone). Status chips reflect the traceability matrix; frontend and backend were assessed independently.
Customers build structured, validated tenders (basic data, item groups with parameters, terms, supplier targeting) and save drafts or publish.
1,492-line editor component; draft + publish endpoints with typed DTO; dedicated feature tests. FE Done / BE Done.
02 §2 (U05) · 03 §2
Suppliers price tenders item-by-item — fully or partially — with notes, attachments and terms; save drafts and submit.
1,319-line offer form; send-offer / save-draft actions; partial-offer support (nullable prices, “will deliver” flags). FE Done / BE Done.
02 §3 (D03, D06)
Interim results, per-item and per-supplier comparison, best-combination computation, and a rule-based advisor suggesting next steps.
667-line evaluation controller; 793-line rule engine; combinations unit-tested. Graphs not present (tables + PDF only). FE Partial / BE Done (U18).
02 §2 (U18) · 06 §4
Two live OpenAI integrations — an evaluation narrative on the winner-selection screen and an AI market-research tool with live web search — plus a statistical savings predictor.
941-line AI recommendation service (queued, cached); streamed market research; real API client and config. Caveats: the input-stage avatar is absent (see Gaps); one supplier-search dialog is a deliberate stub.
02 §1 (OS-06) · 02_high_risk §4.4
Customers set per-item target prices and re-engage chosen suppliers in a new negotiation round; suppliers see color-coded targets.
Dedicated round type, offer-copy mechanics, notification mails, two feature tests. FE Done / BE Done (U19).
02 §2 (U19)
Suppliers may propose alternative items where the customer allows it; alternatives flow through results, samples and pricing.
Dedicated controller/action, enable flag per tender, five dedicated test files; woven through offer form, results and sample requests. Board-only scope — no register row.
02 §5 · 04 §2d
Back-office for companies (create, verify, statuses, responsible users), users, contact inbox, and a cross-company project overview.
687-line admin controller, 8 admin pages, 5 admin test files. The register records both areas as “Nie” (not done) — delivery is understated in documentation.
02 §4 (A03, A08) · 02_high_risk §2
Slovak/English UI at locale parity with a language switcher; counterparty messages translatable on demand via DeepL with caching.
2,106/2,104-line locale files; translation endpoint + cache table; translatable content models. Czech backend locale only partially present.
02 §1 (OS-04) / §3 (D12)
Per-company context on every request, multiple companies per user, roles, OTP e-mail verification, team invitations, password recovery.
Company-context middleware + pivot with role flags; 8 auth test files. Caveats: scoping is per-query convention (see Risks); public registration currently disabled in code.
02 §4 (A01) · 03 §G
Role-aware dashboards (customer, supplier, superadmin) across new/ongoing/closed stages; three PDF export types.
Two dashboard controllers + filters; PDF endpoints with dedicated data service and templates. Known rendering gaps on large tables were tracked on the board (one still open).
02 §1 (OS-07) / §2 (U02)
Own supplier lists + global registry, blacklists, country targeting, public-tender category matching, magic-link invitations; MERK business-registry enrichment with validity checks.
MERK client (469 LOC, cached) is live; Finstat absent; distance filtering absent; magic-link frontend page not located (backend verified). Core supplier DB: FE Done / BE Done.
02 §2 (U09, U11, U12) · §5
Contract and contract-addendum DOCX plus a terms-confirmation XLSX, downloadable on the closed-tender screen and auto-attached to the winner e-mail.
Custom DOCX/XLSX generators with static repo templates. Not evidenced: a “framework order with guarantee” document (term never defined) and any template editor. FE Done / BE Partial (U21).
02 §2 (U21) · 05 I-09
In-app meeting slot proposal/confirmation with deadline automation; sample requests with supplier confirm/reject and status cards.
Working modules with tests and mails. Not evidenced: calendar/Teams integration, online-vs-person type; the extended sample lifecycle was removed in late May (residual dead code remains). Both register rows said “Nie”.
02 §2 (U16, U20) / §3 (D08, D09)
Daily commodity sync (Yahoo Finance), volatility detection, e-mail + in-app alerts; full in-app notification center with unread tracking.
Backend pipeline complete and scheduled; no user-facing market view and no opt-out control. Digest frequencies (daily/weekly) are stored but never acted on — no sending job exists. FE Missing–Partial / BE Done.
02 §1 (OS-02/08) · §3 (D07)
Stripe/Cashier plumbing, tier model and a 20-feature entitlement system enforced server-side; pricing and plan pages.
Gating active in three controllers; plan-page submit is a stub and no checkout endpoint exists; every company is hard-assigned tier 1, whose contents live in production data. Board-only scope.
02 §5 · 03 §G · 05 T-04
Public landing page, pricing page, reCAPTCHA-protected contact pipeline with an admin inbox, privacy policy; product-analytics instrumentation.
1,008-line landing page; contact controller + admin resolve flow + test; PostHog module shipped in the frontend. Board-only scope — no register row.
02 §5 · 04 §2d
Statuses from outputs/02_traceability_matrix.md; capability grouping from 04 §2 and 06 §4.
All fourteen grant themes (OS-01…OS-14), judged at theme level with frontend and backend evidence assessed independently. The grant text is outcome-oriented — these are themes, not feature specifications.
| ID | Requirement (theme) | FE / BE | Status | Evidence summary |
|---|---|---|---|---|
| OS-01 | AI avatar / assistant guiding user input | FE ✕BE ✕ | Missing | No avatar/assistant/hint engine in either repo; delivered AI operates at the evaluation stage instead. |
| OS-02 | Market-trend & commodity-price notifications | FE ◐BE ✓ | Partial | Complete scheduled backend pipeline (sync → volatility → mail + in-app); users see only generic notification rows, no opt-out. |
| OS-03 | Platform connecting suppliers & buyers | FE ✓BE ✓ | Delivered | Full tender/offer domain: creation, offers, rounds, invitations incl. signed magic links, dashboards. |
| OS-04 | Multi-language / language-barrier removal | FE ✓BE ✓ | Delivered | sk/en locale parity, switcher, DeepL message translation with caching, translatable content models. |
| OS-05 | Standardized data entry + validation | FE ✓BE ◐ | Partial | Full client-side validation gate; server validates types only — no completeness gate on publish. |
| OS-06 | AI evaluation & strategy recommendation | FE ✓BE ✓ | Delivered | 793-line rule engine + OpenAI narrative + AI market research + savings predictor (the latter undocumented). |
| OS-07 | Statistics / data outputs / dashboards | FE ◐BE ✓ | Partial | Dashboards, evaluation tables, 3 PDF exports; graphs absent — no charting library installed. |
| OS-08 | Centralized real-time market data | FE ✕BE ✓ | Partial | Daily Yahoo Finance sync stores ticker history; no frontend reads it. |
| OS-09 | Automation of repetitive steps (umbrella) | FE ◐BE ◐ | Partial | Rounds engine, scheduled jobs, 20 event mailables; follow-up/sequencing automation not evidenced. |
| OS-10 | Ecological supplier preference | FE ✕BE ✕ | Missing | Zero hits in code and in every post-grant document. |
| OS-11 | Transparency / process control | FE ✓BE ✓ | Delivered | Activity timelines both sides, auditing on 16 models, 3-dimension status badges, verified-supplier badge. |
| OS-12 | SME accessibility / commercial model | FE ◐BE ◐ | Partial | Tier/entitlement system live; purchase path not evidenced (stubbed plan page, no checkout endpoint). |
| OS-13 | Hardware modules / sensors | FE ✕BE ✕ | Missing | Zero trace anywhere; flagged in phase 1 as likely grant-template language — but present in the approved text. |
| OS-14 | Delivery plan (5 work packages, end 03/2026) | — | Not verifiable | Process requirement; code cannot evidence it. Documents show board activity 2–3 months past the planned end. |
Source: outputs/02_traceability_matrix.md §1 · outputs/03_missing_vs_done.md §1. FE/BE legend: ✓ done · ◐ partial · ✕ missing.
Status distribution per scope tier. Frontend and backend were scored independently in the matrix; the tier summaries below use the combined per-requirement judgment from phase 03.
Original: 29% delivered / 43% partial / 21% missing / 7% n.v. — Register: 23% / 40% / 36% — Trello: 31% / 11% / 57% open.
The three missing themes are strategic, not incidental: avatar, eco-preference, hardware.
Of the 17: 12 carry the register’s own “Po termine” deferral, 3 were never prioritized (“???”), 2 are Must-Have (U01, D11).
Board state and code agree almost everywhere — open cards genuinely correspond to missing code. Counts are feature clusters/cards from 03 §4 (estimate-level granularity).
Source: outputs/03_missing_vs_done.md §1–4 (Trello tier counts aggregated from §4 lists).
The six most consequential gaps, selected for strategic significance — not an exhaustive list (phase 03 holds the full tables). Neutral framing: “not evidenced in code” asserts absence of evidence, not intent.
Also notable (phase 03): per-company e-mail branding (U15, Must-Have — static platform logo only), notification digests (setting exists, sender does not), market-data visibility (built pipeline invisible to users), and server-side publish completeness (client-side only).
Source: outputs/03_missing_vs_done.md §5/§A–C · outputs/02_high_risk_findings.md §1.
The project’s status documentation proved unreliable in both directions and is the weakest artifact of the engagement. It remains valuable as a scope inventory; it is not reliable as a status record.
Usable as the only feature-level scope inventory that exists; not reliable as a status record in either direction. Any contractual, grant-reporting or planning use of current statuses should be preceded by re-baselining — the audit’s corrected per-row matrix (phase 02) can serve as the starting point.
Source: outputs/02_high_risk_findings.md §1–3 · outputs/06_executive_summary.md §7.
Highest-priority items for management attention. Likelihood reflects how probable it is that the risk materializes in the product’s next stage (go-live); impact reflects severity if it does. Ratings are audit estimates derived from the phase-03 risk register.
| Finding | Likelihood | Impact | Basis |
|---|---|---|---|
| Public registration disabled in code — sign-up wizard live, endpoint throws; hardcoded, owner/exit condition unrecorded | High | Critical | 03 §E/§G · 05 T-03 |
| Tenant isolation by convention — per-query company scoping, no structural guard; superadmin header bypass. No leak observed; unprobed | Unverified | Critical | 03 §G · 05 T-02 |
| Market e-mails on default-on flag — no user opt-out exists; consent basis unconfirmed | High | High | 03 §G · 05 T-05 |
| Tier gating without purchase flow — entitlements enforced; every company hard-assigned tier 1 whose contents live only in production data; checkout stubbed | Medium | High | 03 §G · 05 T-04 |
| Production dependencies unverified — AI keys, market-ticker seeds, schedulers/queues; flagship features may be live or inert | Unknown | High | 05 T-11 |
| Sample-lifecycle dead code — action classes reference removed enum states; unrouted today, fatal if ever wired | Low | Medium | 02_high_risk §4.1 |
| Server-side publish gap — API accepts incomplete tenders that the UI would block | Low–Med | Medium | 02 §1 (OS-05) |
| “AI” supplier search stub live in UI — simulated results presented under an AI label (tracked honestly as open backlog) | High | Medium | 02_high_risk §4.4 |
| No mail-failure handling — invitation/winner mails can vanish silently; one such incident in board history | Medium | Medium | 03 §G |
| Zero frontend tests — vs 76 backend test files; FE regressions of the autosave class have no safety net | Medium | Medium | 03 §G · 04 §1 |
Source: outputs/03_missing_vs_done.md §G & final lists · outputs/05_ambiguous_edge_cases.md §3 · outputs/06_executive_summary.md §8.
Yes
A two-sided tender-management platform of roughly 82,000 hand-written lines, with the complete tender lifecycle implemented end-to-end, 76 backend test files, six working third-party integrations, and pilot user-testing activity documented in May 2026.
Yes — with a qualification
Delivered capabilities cover the procurement-optimization workflow the project exists to serve, including genuinely advanced elements. Qualification: part of the built value is currently locked — invisible to users, unwired, stubbed, or dependent on unverified production configuration — so realized value is presently smaller than implemented value.
No — in both directions
Three of fourteen approved themes are not evidenced at all (including the flagship avatar concept, delivered instead as evaluation-stage AI); six are partial; the approved timeline was exceeded. Simultaneously, the system contains substantially more than the approved text describes — a majority of implemented effort traces to scope defined after approval.
Substantially delivered; records did not keep pace
Neither “delivered as approved” nor “not delivered” is accurate. A working product was delivered whose composition differs significantly from the approved description; the differences are largely documented, but across later artifacts that overstate, understate and contradict one another.
Pilot-stage software with a solid delivered core — not yet a go-live product. The gap between those two states consists of specific, enumerated items: a small set of stakeholder confirmations, one production-environment verification, a cross-tenant probe, four pilot-mode toggles needing owners, and a documentation re-baseline. The remaining distance to a clean delivery verdict is a defined, resolvable list (phase 05), not an open-ended investigation.
Source: outputs/06_executive_summary.md §9.