Reel-Quick: Robustness revisited

Building video tools is never just about generating an output file. The real work starts when users hit the messy parts of production:

a render fails after several minutes
the UI forces them to rebuild everything from scratch
an overlay flow becomes one-way instead of editable
previews do not respond to timing changes

That is exactly what we worked through in Reel Quick.

Instead of treating these as isolated bugs, we tightened the workflow end to end so the app behaves more like a real production tool and less like a brittle demo.

Repo: https://github.com/ronin1770/reel-quick

What We Fixed

1. Stabilized video rendering

One of the biggest failures came from transition rendering. Some clips were being prepared at different dimensions, which caused FFmpeg transition stitching to fail.

We fixed that by normalizing clip output dimensions before the transition step. That removed a whole class of render failures where jobs would spend minutes processing only to die at the final merge.

2. Added retry for failed videos

This was the biggest workflow problem.

Previously, a failed render meant the user had to:

reimport files
recreate segments
rebuild the same video setup again

That is unacceptable for a creator workflow.

We changed the backend so failed videos can be retried using the already stored video metadata and saved clip segments. The system now reuses the existing record instead of forcing a full rebuild.

3. Made retry visible in the UI

Backend retry alone is not enough if the user cannot discover it.

We added a retry action directly on the videos page so a failed video can be re-queued from the same row where the failure is shown. That keeps recovery close to the failure point, which is where it belongs.

4. Fixed a retry response bug

During the retry work, the backend was correctly queueing jobs but returning a broken response because of non-serialized datetime values.

That meant the render could still start, but the frontend would see an error.

We fixed the response serialization so the API now reflects the actual outcome correctly.

5. Reopened the text overlay workflow

The text overlay flow was too final.

If an overlay had already been created, the videos page effectively treated it as done. We changed that so users can re-enter the overlay editor for the same video instead of being blocked by a finished state.

6. Loaded saved overlays back into the editor

Reopening the editor is only useful if the saved work comes back with it.

We added support for loading previously saved overlay definitions, which means reopening a video now restores its overlay setup instead of starting from an empty screen.

7. Let users edit existing overlays

Before this round of fixes, the text overlay page allowed deletion, but not actual editing of an existing item.

That forced a delete-and-recreate workflow, which is slow and frustrating.

Now each overlay can be reopened in edit mode, updated in place, and saved back into the list.

8. Synced the video preview with overlay timing

This was a small UX issue with a big impact.

When choosing the start time for a text overlay, the preview video did not move with the selected timestamp. That made timing adjustments needlessly clumsy.

We changed the editor so the preview seeks as the user selects the overlay start time. That makes timing decisions much faster and much more intuitive.

9. Sorted overlays by start time

Overlay lists get messy quickly if they appear in creation order instead of timeline order.

We updated the page so overlays are shown in start-time order and stay sorted after loading, editing, and adding new items. That makes the list easier to scan and much easier to trust.

Why These Fixes Matter

None of these changes are flashy on their own.

But together they shift the app from:

"something works if everything goes right"

to:

"the workflow stays usable when real things go wrong"

That difference matters a lot in any video pipeline.

Users do not judge a product only by the happy path. They judge it by what happens after a failure, after a revision request, and after they need to change something they already created.

That was the focus of this work.