Cases

Every course goes through a pipeline with five fronts: Projects (client relationship), Content/Instructional Design, Audiovisual (shooting), Creative (assets) and Post-production (editing and finishing).

In a short time, the team went through Notion, ClickUp, back to Notion, plus trials with Jira. The migrations happened mid-operation, with clients and deadlines running. The turning point was realizing that the problem was not which tool to choose, but trying to fit the Versa process into a structure designed for another kind of company.

The problem was not missing features. It was their data model: everything became a task of the same size, and Versa does not work that way.

Versa work changes size as it moves along the pipeline. Content handles each lesson individually; Audiovisual and Creative can work with blocks of information; in Post-production, work goes back to one lesson at a time.

Off-the-shelf tools pick one granularity and impose it on everyone. VERSA OS keeps a single card that travels through every team, but each team sees it and distributes it at the size it actually works.

The decision to build was approved by leadership in September 2026, after an open presentation to the team. The market path had been tried more than once; what changed was the cost of building: with AI-assisted development, a custom system no longer required a dedicated engineering team.

VERSA OS replaces manual handoffs with triggers: when a stage ends, the next one is released on its own. A client approval releases Shooting and Assets at the same time; a rejection goes back to the script and counts as a new version.

During testing, anyone can leave a suggestion at the exact spot in the interface where they felt friction: a pencil appears on hover, and the suggestion stays attached to the button or screen where it was born. An AI classifies the suggestions and recommends what should go into the next sprints; the responsible team decides and implements.

VERSA OS was written 100% with Claude Code, by a team with no dedicated engineering. The human role was deciding what to build and why; the AI wrote the code. Scripts, videos and sensitive data stay on Google Drive: the system only organizes, shows and embeds them.

Building with AI does not replace product work. Without a clear model of how work flows, AI only speeds up building the wrong tool.

The presentation to the team showed what discovery had missed. Nothing was rebuilt, but much of the system changed shape: importing the proposal became optional, a button to add a deliverable mid-project appeared, a client page started releasing material only after internal approval, and the delay alerts were revised after scaring people who opened the alpha.

The biggest learning: the right question was not "which tool to use", but "what is the unit of work of each team".

Final stage of development, in parallel testing with representatives of each team; fully in production in January 2027. There are no result numbers yet. Measurement is already built in: time with the client, queue and execution time per team, internal adjustments vs. client versions and capacity per island.

Client and people names are blurred in the screens.

Problem: review feedback arrives unstructured and goes through a manual translation between email and Notion. That creates extra versions, hides new requests inside adjustments and lets approvals block other stages without anyone seeing it.

Solution: the client reviews directly in the product and marks each point as a correction, a new request or a question, with a timecode and saying whether it blocks a stage. The system splits the paths on its own.

Versa produces corporate education courses, and every client comes with its own brand, language and criteria. I coordinate post-production, a team of 9 people across editing, motion and design, and more than one area takes part in each delivery: Content writes the script, Creative defines the visual proposal and Post assembles the videos.

Over the last year, I standardized processes that ran disconnected. The lead time of a 1-hour project dropped from about 14 to 8 days, and versions per delivery dropped from 4 to 2.4. Still, 2.4 versions is a lot of back and forth, and review was the part of the flow I had not yet tackled head on.

Client and people names are anonymized in this case.

I started by separating what I knew from what I thought I knew. I narrowed the scope early: instead of the whole production management, only review and approval, because that is where lead time gets stuck. One of my assumptions fell early on: I thought the comments lacked timecodes.

The problem was not missing timecodes: it was feedback having no shape, and a single person bridging the client and the team. I got there through three paths.

Four profiles touch the same delivery, each with a different pain. The project manager is the first user: she suffers the most from the problem and is where it takes shape.

How might we get feedback to the makers already split by type, with the client criteria at hand and with what blocks what visible to everyone?

With the client outside, the manager would keep receiving feedback by email and log it in the structured format. It would be easier to adopt, because changing client habits is the hardest part. With the client inside, they review through a link and leave the feedback already classified, which removes the manual translation.

I chose the client inside. Manual translation is the root of the three insights, and keeping it would only make the problem more organized. To reduce adoption risk, the client comes in through a link, with no account, and each point type comes with a short sentence explaining what it means.

On a screen full of versions, deadlines and comments, the interface has to disappear so the decision can show. That is why Crivo has a minimalist language: black and white as the base, plenty of breathing room, generous corners and a single brand color (navy), with state colors for new request, approved and blocked.