Founder · Product architecture and active implementation · Private product in development
Coverlay Studio
An actively developed browser-based editor for reversible timeline operations, media composition, overlays, and AI-assisted production workflows.
I am designing and implementing Coverlay Studio as a private product. Its current codebase contains a real non-linear editing foundation while public access remains intentionally unavailable during active development.
Private product · Public-safe system view
Editor intent to reversible state and persistence
Editing intent enters one typed state boundary, participates in reversible history, projects consistently into every studio surface, and crosses an explicit API boundary for application-owned persistence.
- Editor intent
Timeline and canvas operation
Timeline and canvas tools express split, trim, ripple, roll, slip, slide, move, selection, and composition intent through typed actions.
- State boundary
Typed editing model
A centralized Zustand project store applies one behavioral contract to tracks, clips, assets, selection, and panel state.
- History boundary
Reversible state transition
Zundo wraps project mutations in shared undo and redo history so destructive-looking operations remain reversible.
- Interface projection
Synchronized studio surfaces
Timeline, canvas, properties, assets, and assembly surfaces read the same project state instead of maintaining competing copies.
- Persistence boundary
Express and PostgreSQL
Persistence commands cross the Express API to Clerk-mirrored identity and Drizzle-managed PostgreSQL records for projects, tracks, clips, assets, and jobs.
- Constraint and context
A browser editor must keep tracks, linked clips, compound clips, selection, and panel state synchronized while making destructive-looking timeline operations reversible and predictable.
- Implemented approach
- I built a typed Zustand project store wrapped by Zundo so timeline changes participate in a shared undo and redo history
- I implemented linked and compound clips plus split, trim, ripple, roll, slip, slide, move, duplicate, mute, lock, visibility, and targeting operations
- I separated the Next.js studio from an Express API with Clerk identity synchronization and Drizzle schemas for users, projects, tracks, clips, assets, and generation jobs
- Engineering decisions and tradeoffs
- I centralized editing state in one typed model, accepting greater store complexity to keep timeline, canvas, properties, assets, and assembly behavior consistent
- I modeled linked and compound clip relationships as explicit data so editing operations update related media deliberately instead of relying on visual conventions
- I separated the browser studio from an Express persistence boundary so interface behavior and application-owned storage can evolve independently while Clerk identity is mirrored into local records
- Resulting capability
- I built a reversible multi-track editing foundation rather than a static timeline mockup
- I established one shared action contract for editing tools consumed across multiple studio surfaces
- I documented verified engineering depth publicly without exposing private source or implying that the product is ready for public use