Building an AI Story App: Architecture and Lessons from Inky

When I started building an ai story app called Inky, the goal wasn't to see if an LLM could write a plot. We already know it can. The goal was to build a durable system where AI functions as the operating layer, allowing a solo builder to ship a complex, multi-modal product without a traditional team.

Inky is a digital storytelling platform that generates branching narratives and synchronized visuals. It is one of several products in my studio. Shipping today requires moving past the idea of AI as a simple autocomplete and toward agentic engineering—where the system itself handles the heavy lifting of research, state management, and infrastructure.

The Architecture of a Solo Studio

Most people approach building an ai story app by wrapping an API call in a pretty UI. That is a feature, not a product. To build a studio-grade application, you have to architect for the long term.

For Inky, the stack is chosen for speed and durability. I use a monorepo structure because it allows me to share types and logic across the web app, the background workers, and the agent orchestration layer. I am not an advocate for one specific stack; I am an architect of systems. I use what works.

Currently, that means a TypeScript-heavy environment, but the language is just the instrument. The real work happens in the orchestration. I built a custom layer called VERA to handle agent coordination. When a user starts a story, VERA doesn't just call Claude. It triggers a sequence: a researcher agent defines the world-building constraints, a narrative agent drafts the arc, and an image-gen agent handles the visual consistency.

Agentic Engineering in Practice

I learned the hard way that letting an LLM have free rein over your database schema is a recipe for corruption. In the early builds of Inky, I tried to let the model determine the story state directly. It failed. It would hallucinate IDs or break the JSON structure.

Now, I use agentic engineering to enforce strict boundaries. The AI proposes a change; a validation layer—written in hard-coded logic—verifies it against the schema before it ever touches the production database. This is the difference between a demo and a shipped product.

When you are building an ai story app, you are really building a state machine. The AI is just the engine that moves the state from point A to point B. If you don't control the tracks, the train derails.

Lessons Learned the Hard Way

Shipping Inky taught me several specific lessons about the current state of AI development:

1. Latency is the enemy of immersion. Waiting 15 seconds for a story beat to generate kills the user experience. I had to implement a streaming architecture that delivers the narrative in real-time while the image generation happens in the background.
2. Context windows are not a silver bullet. Even with 200k context windows, models lose the thread of a long-form story. I had to build a vector-based memory system to inject relevant plot points back into the prompt at the right time.
3. Profit before vanity. It is easy to burn thousands on API credits. I architected Inky to use smaller, cheaper models for routine tasks like summarization and reserved the high-reasoning models for the actual creative writing.

Working in public means admitting when a choice didn't scale. I originally tried to use a specific serverless provider for the image processing, but the cold starts were adding 300ms to every request. I migrated to a dedicated container setup and shaved that time off immediately. These are the details that matter when you are the one responsible for the entire stack.

The Money Layer: Building for Durability

Building an ai story app today is a capital-intensive exercise if you aren't careful. My studio operates on a profit-first model. This means every architectural decision is also a financial one.

I don't build for the sake of using new tools. I build to create assets that support my family and my lifestyle. Inky isn't just a software project; it is a test of the studio's operating system. By using AI as the team, I can maintain a high output without the overhead of a traditional headcount.

If you are looking to move from being a developer to being an operator, you have to stop thinking about the code and start thinking about the system. The code is ephemeral; the system is what survives.

I am continuing to refine the Inky engine as part of my broader studio work. If you are interested in the specific implementation of the VERA orchestration layer or how I manage the monorepo, I have documented the process in my resources.

Happy to talk.

Justin Tsugranes