APPLICATION: SENIOR FRONTEND ENGINEER · DAILYMOTION STUDIO

I didn't just apply to Dailymotion Studio. I've spent two years building one.

Yohann Lesueur: 7 years shipping React & TypeScript to production. For the last two, I built creator-grade dashboards where non-technical users drive a complex system. Different industry, same battles. This page is my case study, including what I'd do in my first 90 days.

TC 00:00:00:00 - PAUSED

Studio Candidates Yohann Lesueur NEW UPLOAD Contact
PROCESSING COMPLETE A new creator just uploaded himself to your candidate pipeline.

What I understood
about Studio.

Studio isn't a dashboard. It's the cockpit where creators run their business, and every screen that lags, every number that looks wrong, erodes the trust that keeps them publishing on Dailymotion instead of elsewhere. From the outside, three battles stand out:

TRUST IS THE PRODUCT

A creator who doubts an analytics number once will doubt it forever. Data-heavy UIs live or die on perceived correctness: loading states, edge cases, timezone handling, the honesty of an empty chart.

PERFORMANCE UNDER DATA LOAD

Analytics over months of history, libraries of thousands of videos, real-time metrics: the naive render dies first. Performance here isn't a Lighthouse score, it's an architecture decision made before the first component is written.

COMPLEXITY, HIDDEN

Your users are creators, not engineers. Every feature added is complexity someone else must not feel. The hardest frontend work is making a complex system feel simple, and it never shows up in a diff.

If I've misread any of this, it's the first thing I want to learn in our conversation.

Why me: three proofs, not a skills list

I'VE ALREADY BUILT THIS PRODUCT

Two years on an energy platform: non-technical operators monitoring sensor fleets through dashboards, with filters, thresholds, time-series charts, CSV/XLS/PDF exports, i18n, multi-tenant theming. Swap “sensors” for “videos” and it's a Studio spec.

I'VE DONE THE HARD MIGRATION

Inherited a legacy jQuery front with 557-line components, sparse docs, zero view-layer tests, and rebuilt it into React 18 + TS 5 clean architecture while the product kept shipping. Undocumented codebases are where I've done my best work.

I SHIP LIKE AN OWNER

Co-founded a two-person studio: my own services in production, no ops team behind me. Spec to prod to postmortem, CI contracts, LLM eval harnesses. Autonomy isn't a soft skill on my CV; it's been my survival condition.

I understand the whole chain, from the creator's click to the chart that renders it.

Ten years, compressed into a timeline you can scrub:

CHAPTER 1: 2016

École 42, the C piscine

One month of C, git and shell. The month that decided everything.

2016 / 2026

Content: the proof library, all shipped to production

The dashboard rebuild: legacy jQuery → React/TS clean architecture

ACCENTA · ENERGY PLATFORM · REACT 18 · TYPESCRIPT 5 · REDUX TOOLKIT

A real 557-line-component codebase, sparse docs, zero tests on the view layer. I introduced a framework-agnostic core/: domain models (DDD bounded contexts), ports & adapters, use-cases in TDD, dependency injection down to the date provider. The view became a thin presenter over Recharts. I inherited code nobody fully understood anymore: no docs, no context, and had to reverse-engineer the business logic before I could safely change anything.

Clean architectureDDDTDD · Jest/RTLRedux listener middleware

Time-series dataviz that survives the year view

SENSOR FLEETS · RECHARTS · MONGODB AGGREGATION · PERFORMANCE

Sensor fleets producing readings around the clock, and users asking for 12-month views. Strategy: never render the raw stream; server-side aggregation by user-chosen granularity (minute/hour/day pipelines), adaptive Line↔Bar rendering, dot=false, client-side zoom with no refetch, memoized derived series. Performance as an architecture decision, not a patch.

Web performanceRechartsUX under load

Agentive: an AI-agent platform, built and operated solo

IDEM AGENCY · PYTHON/FASTAPI + REACT · LLM · CI/CD

Co-founded a two-person studio, no ops team, my own services in production. Multi-provider LLM abstraction with fallback, cost estimation and secret masking; pgvector RAG; sandboxed tool execution; architecture contracts enforced in CI. Fullstack autonomy, by necessity.

AutonomyAI in productionCI/CD

Loqua: a privacy-first voice coach that measures itself

SOLO · LLM INTEGRATION · EVAL HARNESS · GDPR

Structured outputs, strict schema validation, typed error handling, and an evaluation harness of 60 reference cases scored by an LLM judge, so model upgrades are measured, never guessed.

LLM evalsProduct sense

Analytics: the mechanism, running live

0years shipping to production
0frontend paradigms migrated
(jQuery legacy → React/TS)
0reference cases in my LLM
evaluation harness
0% of this site hand-reviewed,
built with AI, owned by me

Q&A: the questions you're already asking

  • “He's never worked in video.”True. I've worked in energy, another domain where real-world data streams in 24/7 and non-technical users need it legible. Domain knowledge takes weeks; the instincts for data-heavy product take years. I'm bringing the years.
  • “No GraphQL in production.”Correct, and I won't pretend otherwise. My data layers were REST. But the hard parts (fetching, caching, normalizing client state, typing the payloads) are my daily work. The query language is a bridge, not a wall, and crossing it is written into week one of my 90-day plan below.
  • “Rennes-based; we're in Paris.”Hybrid-ready from day one. Full remote, two days a week in Paris, or two days every other week: whichever rhythm the team runs on works for me. I've spent two years working in a distributed team: async-first habits, written culture, updates shared before you ask.
  • “Another candidate claiming to use AI.”This site is my answer. Built with AI in the loop, reviewed line by line: architecture audit, TDD write-up, and a 37-test suite in the repo. I use AI the way your posting asks: fast, and with known limits. The /guide page shows the receipts.

My first 90 days: a plan, not a promise

Every codebase rewrites the plan that meets it. But here's how I approach the first 90 days, the same way I'd approach a feature: understand, ship small, then compound.

DAYS 1–30

Learn the system, ship anyway

  • Ship to production in week one, however small. A fixed bug beats a perfect mental model.
  • Map the codebase: routes, data flow, state boundaries, test coverage, and your GraphQL layer's schema and conventions. Whatever isn't written down yet, I write down.
  • Sit with creator support tickets and user research. The dashboard makes sense only through the eyes of who uses it.
DAYS 31–60

Own something end-to-end

  • Take a feature from spec to prod: mine to scope, build, test, ship, monitor.
  • Start paying the small debts met along the way (flaky tests, slow renders, missing types) in the margins of feature work.
  • First pairing sessions given, not just received.
DAYS 61–90

Compound

  • A measurable contribution to something the team already tracks: page performance, test reliability, delivery speed. Their metric, not one I invent to look good.
  • A written proposal for one structural improvement: argued, scoped, reversible. The team decides if it's worth it.
  • Fully autonomous on the roadmap. The onboarding investment paid back.

Think this plan is wrong? Good: challenge it with me in 30 minutes.

Ten things I'd want to explore: hypotheses, not recommendations

I haven't seen your codebase, so these aren't recommendations. Each one fits in a sentence, can be tested in under a month, and produces a number. That's how I like to work.

  1. Where the analytics views spend their render time, and whether memoization or server-side aggregation is the cheaper win.
  2. Whether a performance budget in CI (bundle size, route-level vitals) would catch regressions before creators do.
  3. How error states reach creators, and if a triage of the top 10 frontend errors would move a support metric.
  4. Whether long-range charts downsample before rendering, or render raw and pay for it. (I've fought this exact battle.)
  5. What percentage of dashboard components live in a shared design system, and what duplicating the rest costs per feature.
  6. Whether GraphQL fragments are colocated with components, and if typed codegen is fully leveraged.
  7. Which tests the team doesn't trust: flaky suites are more expensive than no suites, because they train people to ignore red.
  8. How accessible the core creator flows are: keyboard, contrast, screen readers. Creators are more diverse than personas admit.
  9. Whether AI-assisted development has guardrails the team agreed on (review norms, generated-code ownership) or just habits.
  10. What the slowest recurring frontend task is for the team, and whether tooling, docs, or deletion fixes it.

Why Studio, specifically: the mirror question

Your posting asks for honest AI usage as a requirement, not a footnote. Your own Chief People Officer has said as much publicly: "AI reshapes how people work, but the human judgment stays the deciding factor". That's not a hope I'm reading into the posting, it's a standard I already hold myself to.

And the product problem is the one I want to spend the next years on: interfaces where real people run real businesses, where a rendering decision has a revenue consequence. I've had a taste of that in energy, dashboards deciding whether an operator catches a problem in time. Your player sits behind 90% of French media and reaches 350 million users; Studio is that same weight of consequence, for creators instead of operators.

I'm not looking for a contract. I'm looking for the team whose product I'll still be proud of in five years.

Six months in: what I want your team to say

He shipped in his first week and hasn't stopped.
New hires ramp faster because he writes things down.
He asks about the creator before he asks about the component.
He picks up the ticket nobody wants and ships it without complaining.
He flags when the AI got it wrong before we do.
Hiring him de-risked the roadmap.

Ready when you are, Dailymotion.

You're looking for a senior who ships complex dashboards, navigates unfamiliar code, and treats AI as a tool with known limits. I'm looking for a team whose product justifies the next five years of my best work.

30 minutes to find out if these two searches end here? I'll bring honest answers to your hardest questions, strong opinions about creator dashboards, and my own questions about yours.

French native · English professional· Rennes, FR, ready for the Paris hybrid rhythm · Available now