When I built the first Premiere subtitle service, a lot of the work was not really “building the feature.”
It was learning the territory.
That first project started from a simple need: generate MOGRT subtitles in Adobe Premiere from a structured text document. In practice, that meant opening .prproj files, figuring out how Premiere stores timing, finding where text actually lives inside MOGRT payloads, and then wrapping all of that in a workflow that an editor could use without feeling like they had accidentally enrolled in a systems programming course.
That service eventually became mogrt.zinchuk.online, and I wrote about its longer arc here:
From a Premiere hack to a cloud subtitle service
The new project, Subtitle Lab, is in some ways a sequel.
It is also a bigger thing.
The first service had one main direction: take text and turn it into a Premiere project with styled MOGRT subtitles.
The second one had to do three different jobs:
- turn subtitle MOGRT tracks into
.srt, - restyle subtitle MOGRT clips into other MOGRT clips,
- take
.srtplus a template project and turn that back into MOGRT subtitles inside Premiere.
That is a broader, messier, more realistic roundtrip problem. It touches export, rewrite, re-import, style reuse, track selection, timing preservation, and all the tiny places where a seemingly innocent subtitle workflow can quietly break.
And yet it reached MVP much faster.
That was the interesting part.
The second project was more complex, but much less mysterious
The first service spent a lot of time teaching me what kind of problem this really was.
It was not “just parse a file.” It was not “just replace text.” It was not even “just understand Premiere.”
It was a product made out of many smaller truths:
.prprojis not friendly, but it is understandable.- MOGRT text is usually there if you know where to look.
- Timing bugs are much more dangerous than text bugs.
- Interface simplicity matters more when the internals become more complicated.
- The difference between a demo and a tool is often just the boring operational work around it.
- Deployment friction is product friction.
By the time I started Subtitle Lab, those lessons were already paid for.
So the second project did not begin with panic. It began with a map.
I already knew the places where things usually go wrong:
- duplicate sequence names,
- internal helper sequences that should not be shown to users,
- text parameters stored in slightly different ways,
- timeline overlaps between tracks,
- multiline text getting flattened by external tools,
- Cloud Run upload constraints,
- the difference between “the service runs” and “the workflow is actually safe for editors.”
That changed the whole pace of the project.
The product itself became more editor-shaped
The first service was very much about one powerful workflow.
Subtitle Lab is more editor-shaped.
Instead of asking one system to do one clever transformation, it accepts that subtitle work in Premiere often moves in multiple directions:
- sometimes you need to get MOGRT subtitles out as proper
.srt, - sometimes you already have the timing and text, but want a different MOGRT style,
- sometimes you have subtitles in
.srtand want them back inside Premiere with a timeline-ready visual style.
That is not three random features. It is one family of annoyances.
The bigger pattern is this: subtitle work gets trapped between formats, and editors waste time moving text manually between those formats when the software should be doing it.
That is what Subtitle Lab is trying to fix.
The first service built the muscles
I do not think the second project would have reached MVP this quickly without the first one.
Not because I could copy the old code directly, although some of that helped.
Mostly because the first project built the right habits.
I already had a feel for:
- how to inspect a Premiere project safely,
- how to keep the interface from leaking too much internal complexity,
- how to test on real fixture projects instead of idealized toy examples,
- how to separate local workflow assumptions from hosted-service assumptions,
- how to deploy a Python service to Cloud Run without turning it into a small personal tragedy.
That meant the second project could start from a much calmer place.
When a bug appeared, it was more often a known class of bug than a total surprise. When a workflow felt awkward, the UI adjustments were more obvious. When the service needed a public home, the Cloud Run and custom-domain path was already familiar.
The first project had already turned a lot of unknown unknowns into known annoying things.
That is a very valuable kind of progress.
MVP came faster because the decisions came faster
One of the most useful differences this time was not technical. It was decisional.
The first service spent a lot of time answering basic product questions:
- local tool or hosted tool?
- panel or web?
- what should users upload?
- what output is actually useful?
- what is too much complexity to expose in the first version?
By the time I was building Subtitle Lab, I had much less appetite for vague possibility space.
That helped.
So the second project moved more directly:
- keep it local-first in spirit, but make the hosted version easy to use,
- keep the UI scenario-based,
- let users choose sequences and tracks explicitly,
- prefer clear outputs over diagnostic noise,
- keep timing exact where exactness matters,
- let the tool feel simple even when the engine underneath it is not.
Those are not glamorous decisions, but they are the ones that let an MVP become real instead of eternal.
The work was still hard, just different
This does not mean the second project was easy.
It just means the difficulty shifted.
Instead of spending most of my time figuring out whether something was possible at all, I spent more time refining behavior:
- preserving subtitle timing instead of drifting away from the original clips,
- keeping multiline text intact,
- deciding how overlapping tracks should merge,
- handling template tracks generated by earlier tools,
- splitting long subtitle cues without breaking words into ugly fragments,
- making the service useful across multiple real Premiere projects instead of one “good” example.
That kind of work is less dramatic, but it is closer to the real shape of product development.
The first project is often about discovery. The second one is often about discipline.
Subtitle Lab felt much more like the second category.
Deployment was almost boring, which is a compliment
Another nice moment was infrastructure.
The first Premiere subtitle service went through the full indie pilgrimage: local scripts, launchers, panels, home-server experiments, logs, port forwarding, dynamic DNS, and eventually Cloud Run with a custom domain.
Subtitle Lab arrived later, when a lot of that groundwork was already done.
So when it came time to deploy it, the job was pleasantly boring:
- package the bundle,
- make runtime config environment-driven,
- deploy to Cloud Run,
- create a second service instead of replacing the old one,
- add a CNAME in GoDaddy,
- wait for certificate provisioning,
- watch the new domain come alive.
That is exactly how I want infrastructure to feel once the painful lessons have already been learned.
Not magical. Just calm.
The result now lives here:
And the older service still exists separately at:
I like that arrangement. It reflects the real history of the work instead of pretending every version of a tool must instantly replace the previous one.
What I like about the second project
What I like most about Subtitle Lab is that it feels like a more honest tool.
The first service was built around one very useful path. The second one acknowledges that real subtitle workflows are messy, bidirectional, and sometimes annoyingly improvised.
Editors export things. They re-import things. They borrow style from one timeline and text from another. They try an external tool, regret it, then need to rebuild the result in Premiere without manually copying a hundred captions.
That mess is not a failure of the user. It is just what real work looks like.
So I think the second project is better not because it is cleaner, but because it accepts the mess more directly.
It is still only MVP, and that is fine
Right now Subtitle Lab is still an MVP.
That means it is already useful, but not yet graceful in every situation.
There are still things to keep tightening:
- more real-world project testing,
- better UI polish,
- more edge-case coverage for timing and template detection,
- cleaner messaging around hosted limits,
- more confidence around the longer tail of Premiere project variants.
But the important thing is that it is alive.
It is not a concept page. It is not a half-demo. It is not a private script that only makes sense on one machine.
It is a real service with a real URL, a real set of workflows, and a real relationship to the first project that made it possible.
Final thought
I think this is one of the nicest kinds of follow-up project.
Not a sequel that simply repeats the first success, but one that starts from harder requirements and still gets to a working product faster because the earlier pain was not wasted.
The first Premiere subtitle service taught me how strange this territory could be.
The second one let me move through that territory with much less drama.
And that is a satisfying kind of progress.
If you want to try the tool itself, it is here:
And if you want the longer background on the first service that made this one easier, that story is here: