CASE STUDY 03 • PRODUCT DEVELOPMENT

Building & Securing The Cloud Forge

How I’m designing an AI-powered, project-first cloud security learning platform with security boundaries built into identity, data, evidence handling, application logic and operations.

PROBLEM

Learning security is not the same as proving you can do security work.

The product is built around a recurring career gap: learners may understand cloud security concepts and earn certificates, but still struggle to practise realistic work, receive contextual feedback and produce credible evidence of what they can do.

PRODUCT THESIS

Learn → Build → Document → Demonstrate.

The Cloud Forge combines project generation, guided missions, an AI coach, evidence capture, assessment and portfolio building. The design goal is to make practice more realistic while keeping learner progress and evidence structured enough to review.

01AI Project Generator

Creates practical security missions aligned with role, experience and learning goals.

02Kaffy AI Coach

Provides context-aware hints, review and explanation without replacing the learner’s work.

03Assessment Engine

Checks defined security outcomes and evidence against a rubric.

04Portfolio Builder

Converts completed work into structured evidence learners can explain to employers.

ARCHITECTURE

A lean SaaS stack with explicit trust boundaries.

The V1 architecture uses Next.js and TypeScript for the application layer, PostgreSQL through Supabase for structured data, server-side capabilities for sensitive operations, Vercel for deployment and external services for AI, payments and transactional messaging.

The security design treats the browser, application server, database, evidence storage and external APIs as separate trust zones instead of assuming application login alone is sufficient protection.

SECURITY DESIGN

Protect learner data and evidence at more than one layer.

  • Row Level Security: database policies constrain which records a user can read or modify.
  • Evidence ownership: uploaded artefacts are associated with the correct learner, mission and review context.
  • Server-side boundaries: sensitive business logic and privileged operations remain away from the browser where possible.
  • Secrets management: provider keys and private credentials are stored outside source control and client bundles.
  • Logging and monitoring: operational events are designed to support troubleshooting, abuse detection and security review.
  • Backups: recovery requirements are considered as part of data security rather than an afterthought.
  • CI/CD security: deployment workflows should minimise secret exposure and unnecessary privilege.

AI SECURITY BOUNDARIES

The coach can guide the learner without becoming an unrestricted authority.

AI-generated guidance is treated as application output that requires scope, validation and product controls. The design separates learner context, mission state and authorised product data, with the intention of reducing accidental data disclosure and keeping sensitive actions outside unrestricted model control.

EVIDENCE & IMPACT

Build the public record alongside the product.

As the platform moves from V1 into active usage, this case study should become the longitudinal record of product development: architecture decisions, user research, product screenshots, waitlist growth, learner outcomes, testimonials, partnerships, revenue and external recognition.

Proprietary source code and sensitive infrastructure details should remain private. Public evidence should demonstrate the security reasoning without exposing secrets or creating unnecessary attack surface.