← All work

Full-Stack / Mobile / 3D / 2026

Application engineering

From the interface to the data behind it.

I built SceneForge, a presentation builder, and a Flutter records application, connecting interfaces to streamed output and persistent data.

Next.jsFlutterSupabaseThree.js

Private applications

CONTRIBUTION & EVIDENCE
SceneForge / Scene studyInteractive 3D
Drag to orbit · Click to inspect
{ scene: "pavilion", format: "typed objects" }
Preparing sceneLocal sample scenes · No model calls
SceneForge / Local scene editor

Change the scene.

Edit object types, positions, scales, or colors. Apply the description to rebuild the scene.

Local sample data. This preview demonstrates structured scene rendering, without an AI model.

Run the workflow

Follow the data into the interface.

Explore the application paths behind streamed scenes, editable presentations, and mobile reporting. Click a step, connection, or trace to inspect it.

Execution trace / Click to inspect

Start the walkthrough, or inspect any step before running it.

Simplified from the project architecture. Runs locally; no live models, credentials, or external services.

Application engineering / Inspector

Workflow overview

Request

The user describes a scene through the application interface.

Why it matters

These examples demonstrate distinct application paths: typed scene rendering, streamed presentation content, and records-to-document reporting.

Synthetic payloads explain the boundaries. They are illustrative examples, not project API schemas or live production traces.

The engineering

Inside
the decisions.

Connect the interface to the behaviour underneath it.

Different products need different interfaces, but all need a reliable connection between user intent, application state, backend services, and the final result.

01

The design decision

Choose the interaction model around the product: records and reporting in Flutter, streamed presentation generation in Next.js, and typed scenes for Three.js.

02

The trade-off

Streaming changes what the interface must handle. Partial data needs an explicit state, and a scene description needs structure before it becomes something the renderer can use.

03

Records and reporting in Flutter

Built a Flutter faculty-records application with Supabase integration, records and insights screens, PDF tooling, and automated application builds.

04

Streaming a presentation into an editor

Developed a Next.js presentation builder with research, outline, card and image-generation routes, streamed generation, and editing interfaces.

05

Parsing a scene while it arrives

Built SceneForge with typed scene descriptions, incremental JSON parsing, and streamed updates to an interactive 3D scene.

Read the system flow

Application engineering · Public explanation of the implementation boundaries.

  1. User intentDescribe a scene, build a presentation, or manage a record.
  2. Application stateHandle streamed generation, editing, and persistent data.
  3. Structured outputValidate scene objects, presentation content, or reporting data.
  4. Usable resultRender editable geometry, presentation cards, or generated reports.

SceneForge — streamed 3D editor

For someone creating and editing a scene: I built typed scene descriptions, incremental JSON recovery, and streamed updates to Three.js geometry. The live portfolio editor demonstrates object selection, editing, and validated JSON using sample scenes.

Presentation builder — generation into editing

For someone turning a topic into a presentation: I developed a Next.js application with research, outline, card, and image-generation routes. Streamed output becomes editable application state instead of an opaque final response.

Faculty records — mobile reporting

For faculty managing records and reports: I built a Flutter application with Supabase integration, records and insights screens, PDF tooling, and automated builds. The challenge connects stored records to readable reports and a usable mobile interface.

Project context

These are separate private application implementations. Client identities, source, and operational data are not public. No production adoption or deployment scale is claimed.

Private applications

Inspect
the work.

Separate private applications spanning Flutter, Next.js, and Three.js. The engineering connects user interfaces to persistence, streamed generation, structured data, and repeatable builds.

Next project: Polli ↗

Source material

Discuss the application work
Private application implementations. The scene editor runs locally with sample objects and no model calls.

Opening the project index…

Browse all work ↗

Interactive exhibit