Scribeflow: drafting, revising and finishing in one place.
A writing platform built with Python, Django REST Framework, Angular, Redis, GraphQL and GCP, for writers who had been working across several tools and screen tabs to complete a single project. Drafting, revision and finalisation live in one environment, so the manuscript and the work of shaping it stay together.
The challenge.
- Long-form writing had been split across a word processor, notes, research tabs and outlining tools, so the project existed as fragments with no authoritative version.
- Writers move constantly between structure and prose, and tools that force a choice between the two interrupt exactly the state the work depends on.
- The editor had to stay immediately responsive on documents that grow to book length, where naive implementations begin to lag noticeably.
- Nothing may ever be lost, which makes durability and revision history a foundational requirement rather than a feature to add later.
Our approach.
- Built the editing surface in Angular, treating perceived latency as the primary quality metric — in a writing tool, input lag is not a performance detail, it is the product failing.
- Used GraphQL so the client fetches exactly the slice of a large document tree it needs, instead of over-fetching an entire manuscript to render one section.
- Put Redis in front of the hot path for session and document state, keeping the interactions a writer performs constantly fast regardless of overall document size.
- Modelled documents in Django REST Framework as structured trees rather than flat text, which is what makes outlining and prose two views of one object instead of two files.
- Deployed on GCP with autosave and revision history designed in from the start, so recovering earlier work is a normal action rather than an incident.
The outcome.
- Drafting, restructuring and revision happen in one environment instead of across several tools.
- The editor stays responsive as documents grow to full manuscript length.
- Structure and prose are two views of the same document, so reorganising does not mean rewriting.
- Revision history makes earlier versions retrievable as a routine action.
Related education work.
EducationFinlearn: finance & operations academy.
Admins run cohorts in a fraction of the previous effort.
React · Django · Wagtail · PostgreSQL
EducationMoneymaze: financial literacy for a credit union's members.
Learning comes from consequence rather than presentation: participants see how earlier decisions constrain later ones.
React Native · Django · Django REST Framework · Python
EducationCrescendo: scheduling for a music school's teaching staff.
The timetable is maintained by the people who hold the information rather than relayed to an administrator.
Angular · Django · Python
Where AI fits in education.
Tutoring assistants grounded in your course material, feedback drafts that teachers review before release, and course content generated to your curriculum.
Explore AI developmentOur journey with them has been nothing short of exemplary, far exceeding our initial expectations.
Questions about this build.
Still wondering something? Ask an engineer
By never loading or re-rendering more than necessary. The document is modelled as a tree so the client can request only the sections in view — GraphQL suits this well — and hot state sits in a fast cache rather than being recomputed. The measurement that matters is keystroke-to-render latency at realistic document length, not with a short test file, because that is where naive implementations fall apart.
Persist continuously and keep history as an append-only record rather than overwriting. The failure mode to design against is not the server going down; it is a bad client state overwriting good saved work. So saves are incremental, history is immutable, and restoring an earlier version creates a new state rather than deleting what came after it.
Because document-shaped data is a tree, and clients need different slices of that tree depending on what the user is doing. Under REST that tends to become either many round trips or a growing set of special-purpose endpoints. GraphQL lets the editor ask for the outline in one view and a full section in another against the same schema, which keeps the API stable as the interface evolves.
The editor dominates the estimate. Document storage, accounts and export are well-understood work; a text editing surface that stays fast, handles structure, and never loses anything is where the real effort goes, and it is consistently underestimated. We scope the editor separately from the rest of the product for that reason rather than treating it as one feature among many.
Let's build from here.
Thirty minutes with an engineer who builds. No sales, no drip campaign. If we're the wrong fit we'll tell you and point you somewhere better.