Full-Stack
Developer& Team Lead

Context

Renders were slow and expensive. Every job ran start-to-finish on a single machine, so a two-minute video meant a two-minute wait and a full instance held hostage for the duration. Cost scaled linearly with length, and a queue of long videos blocked short ones behind it.

Options considered

• Scale the render box vertically

  Buys headroom, not throughput. Cost per render keeps climbing and one long job still blocks the queue.

• Persistent worker pool on ECS

  Better parallelism, but we pay for idle capacity between bursts and the traffic is spiky.

• Fan frames out across Lambda, stitch at the end

  Rendering is embarrassingly parallel at the frame level — concurrency scales with the work, and we pay only for frames actually rendered.

Decision

Re-architected the pipeline so each render is chunked into frame ranges, fanned out across concurrent Lambda invocations writing to S3, then stitched into the final file. Wall-clock time became a function of concurrency rather than video length, and billing became per-frame instead of per-instance-hour.

Outcome

Render time and render cost both dropped by half. Long videos stopped blocking the queue, and the platform could absorb bursts without pre-provisioning capacity.

Context

The catalog needed to go from nothing to hundreds of templates. Built the obvious way — one Remotion composition per template — that is hundreds of near-duplicate files, and every change to a shared behaviour becomes a hundred edits.

Options considered

• One hand-built composition per template

  Fastest for template #1 and unbearable by template #50. Duplication compounds, fixes don't propagate.

• JSON-configured single mega-template

  Every new visual idea becomes a config flag. The schema grows faster than the feature set and nothing is type-safe.

• Typed, composable motion primitives

  Templates become composition, not code. Shared behaviour lives in one place; TypeScript catches misuse at build time.

Decision

Built a TypeScript + Remotion component library of typed motion primitives — transitions, text reveals, layout frames, timing helpers — so a template is assembled from vetted parts rather than written from scratch. New templates became composition work; fixes to a primitive propagated to every template using it.

Outcome

The production catalog went from zero to 500+ templates, and the marginal cost of a new one collapsed to something a non-specialist on the team could take on.

Context

Client work needed production Chrome extensions on Manifest V3. MV3 splits code across service worker, content scripts and popup, each with its own bundle, lifecycle and messaging rules — and no hot reload out of the box.

Options considered

• Custom Webpack/Vite MV3 config

  Full control, but weeks of build plumbing per project and a config only I could maintain.

• CRXJS

  Good HMR story, thinner conventions — more of the MV3 structure still lands on us.

• Plasmo

  Opinionated MV3 conventions, live reload, React-first, and messaging handled — build time goes into the product, not the bundler.

Decision

Standardised on Plasmo for extension work. File-system conventions handled the MV3 surface split, live reload removed the reload-the-extension loop, and the React code shared patterns with our web apps instead of being a separate dialect.

Outcome

Extensions shipped on client timelines with build configuration that stayed boring, and the same team could move between web app and extension work without relearning the toolchain.

Context

Earlier projects ran on MongoDB and Mongoose, which was quick to start but leaked into runtime: shapes drifted from what the code assumed, and multi-step writes — order placed, stock decremented, payment recorded — had no transactional guarantee.

Options considered

• Stay on MongoDB + Mongoose

  Familiar and fast to prototype, but relational data modelled as documents means hand-maintained integrity.

• Postgres with a raw query builder

  Full SQL control, no generated types — the schema-to-TypeScript gap stays open and has to be hand-synced.

• Postgres + Prisma

  Real constraints and transactions in the database, with types generated from the schema so the compiler enforces them upstream.

Decision

Moved transactional products onto PostgreSQL with Prisma as the data layer. Relations, constraints and transactions became the database's job; the generated client made the schema the single source of truth from migration all the way up to the React component.

Outcome

A whole category of runtime data bug turned into a build error. Schema changes surfaced every call site that needed updating instead of failing in production, and multi-step writes stopped being able to half-succeed.