← Back to showcase

Showcase / Architecture & Operations

Enterprise Form Platform

The secure data funnel and door for the outside world to connect to Salesforce. A schema-driven form platform architected entirely on the platform, so logic runs on-board with no external service to build, host, or pay for.

Live at Manabie Salesforce-native AES-256 encrypted Zero external API surface

The thesis

The door to Salesforce, built on Salesforce

Most form platforms bolt on a separate frontend host, a middleware API, and a datastore, then spend the rest of their life securing and paying for the seams between them. I built this one as the direct door: the entire data funnel lives on Salesforce, so there is nothing external to integrate, secure, or bill for, and the data never leaves the platform it already trusts.

The AI Council and agent-dispatch workflow that runs on top of this platform is a separate case study: AI Council.

What ships today

Stable platform capabilities

  • React 19 and TypeScript frontend deployed as a Salesforce Static Resource through Visualforce.
  • Apex @RemoteAction backend for guest-user compatible form operations.
  • AES-256 encrypted URL tokens for controlled access.
  • JSON-schema-driven forms with conditional logic, repeaters, pre-fill, and draft save or resume.
  • Multi-object creation and update flows with asynchronous processing and transaction rollback.
  • Real workflows such as event registration, targeted health surveys, and enrollment or RFI flows.

Architecture

Why it is all on Salesforce

  • No external API to build or pay for. Apex @RemoteAction serves the form logic on-platform, so there is no middleware tier to host, scale, or bill.
  • Data residency by default. PII and health data stay inside the Salesforce trust boundary rather than crossing into a separate service.
  • Encryption at the access layer. AES-256 encrypted URL tokens gate targeted, contact-specific links without a custom auth service.
  • Guest-user safe. The whole flow works under strict guest-user security constraints, so public distribution never widens the attack surface.
Fewer moving parts is the security story and the cost story at once: nothing to integrate is nothing to breach and nothing to invoice.

Constraints

Why the architecture matters

  • Salesforce Sites and Visualforce hosting environment.
  • Guest-user access with strict security constraints.
  • PII-sensitive workflows including health-related data.
  • Need to support both public distribution and targeted contact-specific links.
  • Business pressure to ship the platform before the AI layer.

Proof points

Measured outcomes

  • Powers production enrollment, event registration, RFI, and targeted health-survey workflows for enterprise education customers.
  • 3 major releases with zero critical production incidents in the current role.
  • Queue-based asynchronous delivery with scheduled auto-processing, tuned for reliable high-throughput submission under concurrent load.
  • Repeatable, recipe-based deployments and structured production logging for fast troubleshooting.
  • Distributed delivery across Singapore, Japan, Vietnam, and the Philippines.

Operations

Run, not just shipped

Shipping to production is the start of the job, not the end of it. The platform is built to be operated: every deploy is repeatable, every failure is traceable, and troubleshooting starts from evidence rather than guesswork.

Deployment as a recipe
Documented, repeatable runbooks. Releases follow a fixed recipe rather than tribal memory, so any release is reproducible and reviewable.
Same steps every time. Predictable deploys are what make zero-critical-incident releases repeatable instead of lucky.
Logging and troubleshooting
Production-level logging. Form operations and multi-object flows emit enough signal to reconstruct what happened, on-platform.
Evidence-first debugging. Issues are triaged from logs and the failing transaction, not reproduced by guesswork, which keeps time-to-fix low.

The AI Operating Model

Building scalable systems, not managing one-off escalations

Most teams use AI as a one-off tool: summon a session, explain context, get a result, repeat. I architected a different approach: an AI-augmented operating model embedded directly into how the platform ships.

AI-readable knowledge infrastructure

Documentation that orients AI tools

A 35+ file markdown knowledge graph with structured frontmatter serves as both a human-readable knowledge base and a machine-consumable context layer. AI tools orient themselves without manual project scanning, eliminating the "cold start" problem for every session.

Embedded AI workflows

AI as part of the pipeline, not a separate tool

Integrated AI tooling (Claude, Cursor) directly into the CI/documentation pipeline with automated documentation sync, changelog generation, and a self-improving loop where the system learns and updates project rules after each task.

Cross-functional coordination engine

Systematic team alignment

Engineered workflows between engineering, product, and vendor teams across Singapore, Vietnam, and Japan. Translated business needs into technical tasks with systematic issue triage, capacity forecasting, and roadmap planning.

The shift

From firefighting to operating models

Instead of managing one-off customer escalations, I built a scalable way of working that leverages AI consistently across the entire development lifecycle. Production stability for major learning centers and remote schools across Japan, with AI embedded throughout.

Roadmap

Where this case study goes next

This case study grows alongside the platform. Coming next: an architecture visual, a milestone timeline, screenshots, and before-and-after evidence from the debugging flow, documentation sync, and rollout decisions.

The AI workflow on top: AI Council Discuss the work