Build record / first-party work
Journey operational workspace
First-party product work for visible ownership, evidence and decisions in complex service delivery.
Implementation record
What was built
Journey is apprenticeship management software for UK training providers, published at journeyapp.co.uk. Journey Core is free forever for verified UK providers with up to 50 counted apprentices, subject to application review. Journey Advanced adds Journey AI, also known as Talk to Journey. This record covers the TechGeek-owned build behind it and the actual operational-workspace interface used as first-party public evidence. It is not a statement that a named customer has deployed Journey, achieved an outcome or endorsed the product.
The product direction starts from a practical operating problem: important delivery work, evidence, exceptions and decisions are often split between spreadsheets, shared folders, inboxes and disconnected systems. Journey's implementation programme focuses on making role-specific work, permissions, reviews, quality activity and hand-offs visible without collapsing every organisational process into a generic dashboard. Any live adoption still needs a separate decision about workflow, data, integrations, support and deployment model.
- 01
Role-aware operational interfaces for programmes, learning plans, delivery plans, cohorts, invitations, reviews, submissions, evidence, quality work, audit activity and governance. The documented product intent is to show the work, evidence, ownership, exceptions and next decisions appropriate to a role rather than report an undifferentiated activity total.
- 02
A controlled authoring and enrolment path. The programme status record describes centre-manager and learner-support creation of programmes, learning plans and delivery plans; active delivery-site ownership across cohorts and learners; and invitation records that preserve an intended site boundary. The code programme treats cross-site/cross-team learner references as failure conditions rather than silently accepting them.
- 03
A data-access and evidence-handling direction that includes tenant-scoped permissions, audit records, attachment ownership checks and opaque download handling. The local reliability release candidate records that legacy ambiguous attachment records fail closed, approved downloads are forced as attachments, and access is audit-bound with a path hash instead of a raw storage path.
Architecture and boundaries
The system and its constraints
- 01
Journey's repository names GitHub as the source of truth, Vercel as the runtime direction, a standalone Supabase project for database/storage and Clerk for authentication. It explicitly excludes Replit from the current canonical production route. Production cutover remains conditional on role-dashboard sign-off, tenant isolation, upload security, CORS, audit gates, CI and browser smoke checks.
- 02
The local roadmap treats sensitive multi-tenant behaviour as a hard boundary. It identifies a non-owner runtime database role and effective row-level-security proof as a separate gate before a broad sensitive multi-tenant rollout. This is important: an implementation of tenant filtering is not presented as exhaustive proof against every write-path or operational misconfiguration.
- 03
The domain carries sector-sensitive language in local documents. That is a product-design and test context, not a public claim that Journey is regulator-approved, compliant, accredited, funded, ready for every provider or suitable without client-specific assurance. The public product page retains this boundary.
Release discipline
What the delivery and QA record can show
- 01
The local Wave 1A reliability record states that a release candidate was implemented and locally verified on a named branch, while exact-SHA CI, hosted certification, protected merge and production smoke remained pending for that candidate. It records focused programme, submissions, ILR, custom-role API and affected-UI suites, plus local browser and full QA runs. This is local release evidence, not a universal statement about the current live deployment.
- 02
The operational authoring/delivery-site release record documents local database, migration, role, frontend, typecheck, browser-matrix, production-build and bundle-budget evidence. It also records an additive migration strategy intended to preserve explicit assignments and existing audit records rather than recreate tenant or learner data. The same source names separate dependencies such as the EPA-gateway boundary.
- 03
The audit record documents a 14-role API breadth sweep, targeted integration tests and static analysis. Its own caveat matters: coverage was parameterless GET breadth plus targeted deep reads, static analysis and console capture; it was not exhaustive POST/PATCH/DELETE state-machine fuzzing or a scripted per-role browser click-through. The public record should preserve that caveat rather than turn the suite into a blanket security claim.
Evidence boundary
What this record does not establish
- 01
The canonical programme status records outstanding or in-progress production-readiness work, including an effective-RLS proof gate for broad sensitive multi-tenant rollout and limitations in observability-provider ingestion/correlation. Those are explicit reasons not to infer a comprehensive production-security conclusion from the available records.
- 02
The public workspace image intentionally reveals interface direction, not customer data. It cannot demonstrate data migration quality, user adoption, response times, support performance, accessibility across every device, financial outcome or any regulator's assessment of a client organisation.
Build judgement
Decisions and lessons carried forward
- 01
The product decision is to organise around accountable work rather than a generic executive dashboard. The role model makes the relevant queue, evidence, review and exception visible to the people expected to act. This improves the quality of a product discussion because the buyer can identify their own ownership and information boundaries before asking for a larger platform replacement.
- 02
The implementation lesson is to make failure and scope visible. Invitation-site capture, cross-site checks, attachment ownership and fail-closed behaviour address cases where a convenient default could misroute sensitive work. In evidence-heavy systems, an apparently successful screen is not enough; the source, owner, permission and exception route must be designed and tested too.
- 03
The commercial lesson is to keep first-party product evidence distinct from client authority. A buyer can inspect the product direction, codebase discipline and test records, but should expect an engagement-specific conversation before data is migrated, integrations are promised or a regulated/assurance conclusion is drawn.
Inspectable material
Evidence sources used for this record
These are the first-party files and artefacts used to write this public summary. They are recorded here to make the basis of each statement legible; they are not a substitute for a buyer's own project-specific review.
- 01
`journey-app/README.md` and `AGENTS.md`: canonical source, intended runtime, role sign-off scope, production gates and evidence/status rules.
- 02
`journey-app/docs/programme/STATUS.md`: dated implementation, local verification, release, observability and unresolved-gate records.
- 03
`journey-app/docs/enterprise-delivery-goal.md` and `docs/production-remap.md`: intended platform architecture, role boundaries and production-cutover conditions.
- 04
`journey-app/docs/audit/findings.md` and `docs/role-governance-ui-qa-2026-07-05.md`: scoped audit method, fixed findings, test caveats and role/governance QA evidence.
- 05
`techgeekuk-site/src/content/proof.ts`, `src/content/product-details.ts` and `public/assets/journey-dashboard.png`: public first-party framing and the actual product-workspace image used by the TechGeek site.
Direct answers
Questions about this build record
01Is Journey a live customer case study?
No. This is a first-party build record. The public record does not claim a named customer's deployment, outcome, endorsement or live-user count. Journey itself is published at journeyapp.co.uk.
02Does the product support every Journey role in production?
The repository defines and tests role-specific workspaces and records particular verification evidence. The canonical programme also names remaining production gates, so current fit and rollout status must be confirmed for the relevant organisation and role set.
03Does the audit evidence prove complete tenant security?
No. It supplies useful scoped evidence, including role/API checks and targeted tests, but the audit itself states that it was not exhaustive write-path fuzzing or scripted browser coverage. Effective-RLS proof is also a documented separate gate for broad sensitive multi-tenant rollout.
04Can Journey replace our existing operational platform?
That is a discovery question. The first step is to determine which current systems remain authoritative, what data and evidence must be handled, what integrations are possible and whether a focused workspace is more appropriate than a replacement.
05What can a prospective buyer inspect now?
The public site shows a real TechGeek-owned workspace image and this build record describes bounded source and programme evidence. A deeper evaluation can be planned around the buyer's workflow, confidentiality requirements, users, controls and acceptance criteria.
A practical next step
Start with the work that needs a decision.
Share the operating problem, the outcome you need, the systems involved and the constraints that matter. We will help establish a credible next route.
Start a conversation