About

My name is Derrick Houger. I’m a professional software engineer who has worked in the industry since 2009. I want to explain why I started building Scriptri and some of the principles guiding its development.

Why I Built Scriptri

If you spend much time on this site or read my articles, you will probably see this story retold more than once because it is core to why the project exists.

Scriptri actually started as a project called NovelArc several years ago shortly after I got into writing. I was working on a novel that is tentatively titled “Coming Home”. The narrative is closely tied to a major event in the protagonist’s past. When I started writing the manuscript, I set the event at just under 4 years in the past. Then as I made progress through my draft, I kept finding reasons I needed to tighten the timescale. It came down to 3 years. Then it was reduced to “just under 3 years”.

Along the way, that timescale had cascading effects. It changed the ages of a key character (a child who was born after that event). It changed how that character behaved (If you have kids, you know there’s a massive difference between a 2 year old and a 3 year old). It changed other facts about the world I was building, like other events that were time-bound in the world. And changing the timescale changed how characters spoke to each other.

That last point was what really highlighted how deep the problem I had created for myself was. There were places in dialogue where characters mentioned that event and how much time had passed since. It was (and still is) a mess.

The Gap I Was Trying to Solve

And that problem formed the core concept for Scriptri: What if software could bind worldbuilding and changing story state directly to the manuscript?

In my profession as a software engineer I could already see the messy web of data and semantic links. If you are a technical person and have interacted with a relational database… you know. It gets messy. Fictional worlds do not fit neatly into rigid data models. The problem becomes even harder when the information needs to change over time, preserve where it came from, and remain connected to the manuscript.

There are solutions for adding notes to a manuscript. There are deep relational worldbuilding tools out there. I have not been able to find anything that allows you as an author to build out your world and its current state while surfacing relevant information to you as you are drafting.

Scriptri started out trying to bridge that gap. As I have built Scriptri and used it with my own manuscripts, I have continued finding more depth in the problem. It began with the idea of “solving continuity.” That remains one of its core purposes, but the larger goal is to surface the state of the story without flooding the writer with information.

Why Scriptri Is Local-First

When I started designing Scriptri, the topic of how it’s used came up as a foundational issue. Should it be a native application? Should it be mobile first? Should it be a cloud service? Should it have a robust backend that archives everything?

That’s a set of questions that every software designer has to answer at some point. And the answer is not really about what I as an engineer prefer. It really boils down to two questions:

1. What do writers need from the application?
2. What tradeoffs come with the way it is built?

For Scriptri, the answer to those questions in my estimation is this: First, writers take their work and their control over it very seriously, whether they are professional authors with several novels behind them or hobbyists working on their first stories. Second, building Scriptri for the web avoids the need for platform-specific versions.

The second is a purely practical answer to the problem. I want people to be able to use Scriptri wherever they want, within reason. I’m probably not supporting smart-fridge based text editing in the near future.

But more importantly, the answer to the first question is why Scriptri is local-first. As a core principle, it means that your data belongs to you. And I don’t just say that as some vapid or hollow statement that makes you feel good but has no real meaning behind it. Keeping Scriptri local-first means that your manuscript is stored locally in your browser on your device. Scriptri does not send that manuscript text to my servers or store it in a shared database.

It is my intention to keep that as a firm principle, regardless of how Scriptri develops and expands. There will always be a free, local-first version of Scriptri that does not require an account.

Now, does that mean I will never support cloud backups or accounts or paid features? Not at all. I think there are a bunch of features like cloud backups that could be useful, optionally. In terms of charging for Scriptri, I hope it eventually becomes useful enough, and earns enough trust, to support optional paid features and allow me to work on it full time.

But, again, that will not be at the expense of a rich and useful free, local-first version of Scriptri.

What I Am Not Building

With that framing, I think it’s useful to talk about a few things that I plan to not do and are not on the roadmap for Scriptri in any way.

• Scriptri will not transmit or analyze manuscript text for product analytics.
• Scriptri will not generate prose for you.
• Scriptri will not require an account.
• Scriptri will not force you to abandon the tools and workflows you already use.
• Scriptri will not pressure you to return through engagement mechanics such as writing streaks.

Note on AI

When it comes to AI, I am very firm that Scriptri will never become a prose writing solution. That’s just not the tool I want to write. There are also tons of solutions out there for doing AI prose writing.

That said, I can imagine narrow, optional uses for Large Language Models within Scriptri. I may eventually explore optional analytical tools that help writers search or organize their own projects, but any such feature would need clear privacy boundaries, manual review, and an explicit opt-in. Manuscripts will not be used for model training.

Note on Engagement Pressure

Engagement mechanics can pressure users to return to software regularly, even when doing so is not useful. I have experienced firsthand how easily a streak can turn meaningful work into maintaining the streak itself. I do not want Scriptri to create that kind of pressure. If you miss a day of writing, you should not feel guilty about it. Rest can also be useful to the creative process, and Scriptri will avoid features designed to punish or shame you for stepping away.

How I’m Building Scriptri

Right now Scriptri is entirely independent. The design decisions, data handling standards, limitations, and development all go through me. Because Scriptri handles work that may be unpublished and irreplaceable, I try to make conservative decisions around imports, synchronization, and data changes.

To determine what to build, I use Scriptri in my own writing and get feedback from other writers and editors. A conversation I had with an editor about Scriptri led me to implement an entity renaming feature. If you have feedback or a feature you’d like to see, I’d love to hear from you.

What I Hope Scriptri Becomes

As I continue to build Scriptri I am slowly developing a clearer vision for what I hope it becomes. I want Scriptri to help writers whose projects have become too complicated to hold entirely in memory by surfacing the characters, relationships, objects, locations, and other story information relevant to the part of the manuscript where they are working.

Some of that future work is visible on the public roadmap.

Most of all, I want this to be a long-running project. I find working on it personally very fulfilling already and I hope that as a writer you find it useful for your project.

If you are reading this as a new user, give Scriptri a try. Tell me what you find useful, what feels confusing, and what you wish it could do.