Purpose
I built this application to explore what digital transformation changes across software delivery, reliability, security, data, developer experience, and organizational culture. It connects those ideas to an explainable assessment while giving me a concrete application to package and operate.
Completed application work
A React and TypeScript frontend connects to three focused FastAPI services over HTTP/JSON. PostgreSQL stores content and assessment data; Redis supports recommendation retrieval. Versioned questionnaires produce deterministic scores and prioritized recommendations that can be revisited using a stable result identifier.
These scores are part of an educational application. They are not independently validated measures of business maturity or predictions of organizational outcomes.
Design decisions
I selected FastAPI for request validation and API testing. The three services make ownership explicit. Separate PostgreSQL schemas and database roles limit direct data access between services while keeping one database instance practical for the lab. Redis stores data that can be reconstructed.
Kubernetes deployment
The repository records Phase 2 as complete: an application-owned Helm chart, deployment to the local Kind cluster, persistent PostgreSQL storage, migration and seed Jobs, health probes, resource controls, metrics, a Grafana dashboard, and operating runbooks.
Application deployment validation
- What was built?
- I built a React and TypeScript frontend, three FastAPI services, PostgreSQL, Redis, and an application-owned Helm chart.
- Why this design?
- Make service and data ownership explicit. Use shared platform ingress and monitoring instead of installing duplicate systems.
- What was tested?
- Validate API contracts, scoring, frontend components, service behavior, Helm deployment, and a complete assessment through ingress.
- What happened?
- The Phase 2 record reports successful validation and deployment. Prometheus discovered six healthy API metrics targets.
Create assessment → answer questions → complete assessment → revisit resultPhase 2 used locally loaded images and a single-replica database. A later platform record documents Argo CD onboarding and centralized logging. This is not a production deployment or a measured business outcome.
Read the Phase 2 validation recordPhase 2 completion evidence · Architecture decisions
Application and platform ownership
The application owns its Helm package, contracts, migrations, and workload configuration. The Enterprise Platform Lab owns shared cluster capabilities. Keeping that boundary explicit makes it possible to evolve the application without duplicating the platform.
Current limits and next steps
The Phase 2 record, dated 30 August 2026, uses images loaded directly into Kind. The later platform validation, dated 2 September 2026, reports Argo CD onboarding with the application Synced and Healthy, plus Alloy collection and a successful Loki query for the application namespace.
Those later results establish platform integration. They do not establish a complete application-specific image publication and promotion pipeline. The single-replica PostgreSQL deployment and local storage also remain lab limits.
Read the later platform integration record
What this demonstrates
Service boundaries, versioned contracts, repeatable deployment, and explicit completion criteria connect application architecture with platform operations. The repository includes validation evidence; this case study does not claim a live production deployment or business impact.