Kiddom 2022 – 2025

Kiddom - On Demand Ingestion

Context

Kiddom is an education platform that delivers high-quality curriculum content through online experiences designed to support teachers. The platform includes both open-source and proprietary curricula, and each content provider distributes materials in a different format. To make this content easier to navigate in a digital classroom, Kiddom instructional designers reshape and enrich source materials. This work also includes creating custom lessons, activities, and learning experiences that align with Kiddom’s enhanced classroom model.

Source formats vary by provider and are normalized through instructional design into a consistent classroom experience.

Problem

Like many CMS platforms, Kiddom includes a Builder for entering curriculum content. At the time, however, the Builder did not support revision history or versioning. This created friction for curriculum developers and instructional designers, who needed collaborative editing and feedback. Their workaround was to draft content in Google Drive (for comments and revisions), then manually copy it into the Builder section by section. The process was slow, repetitive, and error-prone.

Constraints

Project constraints limited the solution space:

As the assigned developer, I could not create a standalone tool outside the existing internal stack.
The first milestone required mapping Google Drive content structures (defined with instructional designers) into Kiddom’s platform data model.
Google Drive folder structures were inconsistent across teams and providers.
Due to permission and access policies, the solution had to live inside an existing internal tool.

Decision

For the initial release, we used a generalized fixed content structure for mapping. We implemented the workflow inside an existing internal tool that already handled user permissions and access control.

Initial ingestion design optimized for delivery speed while preserving auditable stages for non-technical users.

UI Design Decisions

Add a component for the folder/files naming configuration.
Because this is an on-demand process used by non-technical users, the UI exposes each step so users can adjust file naming and folder structure as needed.
The flow provides three auditable stages: Loading, Parsing, and Transforming.

Technical Decisions

At the time, to reduce implementation friction and meet timeline constraints, I handled loading and parsing on the frontend. If I were implementing this today, I would use a backend-first ingestion pipeline: queue jobs, parse and transform in workers, and expose progress/status APIs to the UI.

Tradeoffs

We focused on optimizing loading and parsing in pure TypeScript.
Because the workflow is frontend-dependent, rendering thousands of files can block the UI.
To mitigate this, we limited visible file output, kept imported payloads lightweight, and discarded unnecessary data early.

Outcome

The tool was adopted enough to justify a roadmap for Version 2.

What I Would Do Now

Future architecture: asynchronous backend ingestion with retries, validation, and full run-level traceability.

Move loading, parsing, and transformation to asynchronous backend jobs for reliability at scale.
Keep the frontend focused on orchestration: submit ingestion requests, surface progress, and show import validation results.
Add robust retries, failure recovery, and audit trails for each ingestion run.
Add clear versioning and revision support to reduce dependence on external editing tools.
Define and enforce a canonical folder/file convention before ingestion starts.