01 / Context
The workflow crossed more systems than one operator should have to remember.
Content moved through source websites, chapter files, Google Drive folders, a story backend, audio generation, and publishing status. The challenge was not one isolated algorithm; it was making a long-running, failure-prone workflow understandable from one place.
CreateStory grew during my internship from a development task into an internal operations platform deployed on a company-controlled Windows host.
02 / My role
I worked across the interface, service boundaries, deployment, and handover.
I developed the React and TypeScript operations interface, connected it to a FastAPI gateway and worker services, evolved crawling, Drive synchronization, TTS, and auto-audio workflows, and diagnosed failures across frontend, database, service, and external API boundaries.
I also performed controlled updates on the company host and wrote separate management and operations documents so another developer could continue without depending on my access.
03 / Architecture
Service boundaries followed different failure and resource profiles.
A same-origin React application communicates with a central FastAPI gateway. Behind it, crawler, text-to-speech, Drive synchronization, and auto-audio services own their workflows and protected internal APIs.
Crawler jobs depend on external pages and browser sessions. TTS is CPU-intensive. Drive synchronization has a different credential and network profile. Separating them reduced the chance that one failed worker stopped every other operation, even though production still ran on one physical host.
04 / Production reality
A passing build was only the beginning of a safe update.
Production did not have complete CI/CD. Before an update, I checked for active crawl or audio jobs, prepared an export, transferred it to the host, rebuilt or restarted the affected containers, and smoke-tested the changed workflows.
That experience changed my definition of done. A system must be operable, diagnosable, recoverable, and transferable—not merely functional on a development machine.
05 / What shipped
Operators gained one surface for a fragmented production workflow.
The deployed tool supported crawling and inspecting content, monitoring long-running jobs, generating chapter or story-wide audio, validating content before synchronization, creating or updating stories through a controlled queue, and detecting missing audio.
I do not publish productivity numbers because I no longer have the company analytics required to verify them. The evidence I can defend is the deployed workflow, the operational responsibility, and the completed handover.
06 / Public boundary
The public version will be a reconstruction, not a copy of company production.
Any portfolio demo will use synthetic stories, personal test folders, non-production credentials, and generic service labels. It will not include company stories, accounts, tokens, Drive identifiers, internal logs, analytics, endpoints, or production screenshots.
A local source copy is not permission to publish company data. The case study documents my contribution while keeping the operational environment private.
07 / Lessons
Shipping taught me to look beyond the feature I was implementing.
Long-running jobs need persistence, visibility, and cancellation behavior. Deployment risk depends on operational state. Secrets and backups are part of system design. Documentation becomes part of the product when someone else must take over.
The stack also had real limitations: one Windows host, manual production updates, limited centralized monitoring, and incomplete automated rollback. Recognizing those limits is part of the production experience I am taking forward.
