The route in one picture

catalogue --> transcripts --> drafts --> checks --> preview site
                                                        |
                          claim: GitHub sign-in + proof of channel
                                                        |
  creator's GitHub organisation <-- "Move my site" <----+
                |
        publish at the new address, search engines on

Catalogue in, transcripts out

We list the channel's uploads and filter them. Shorts, videos under a minimum length, live streams and members-only videos are skipped. For the demo we take the three most-viewed long videos. The rest of the catalogue waits until the creator agrees to go further.

Each video needs a transcript in the language it was spoken in. The tool prefers manual captions in that language, then automatic captions in that language, and falls back to a speech-recognition model only when there are no captions. The order exists because of a mistake of ours: an earlier version of the tool could pick an automatically dubbed track in another language, and 36 transcripts came out in the wrong language. It now never takes such a track, and a test keeps it that way.

Onboarding from a channel is operator-run today. We run these steps ourselves, on a machine we operate, and a creator cannot start them on their own.

Drafting from the creator's own words

A language model writes each article from its transcript, following rules we keep in a versioned file. We wrote the rules down from the three samples on the demo site. The three articles on the demo were written by hand first, and the rules below came from them. We have not yet regenerated them with the pipeline to see whether they pass every check; that run waits for the next creator who says yes.

• Only what the video says. No outside facts.
• First person, in the creator's voice.
• A "Watch from m:ss" link at each section, and a link to the full video.
• Names the captions misheard are corrected and listed in a notes file, and uncertain ones are marked "confirm".
• Figures worth a second look are listed. Only crude phrasing is softened, and every softening is listed.
• References that only make sense on screen, such as "this map", are left out.

There is no length target.

Checks before anything is landed

A draft must pass automatic checks. The front matter validates against our schema. Every timestamp link falls inside the video's length. Every figure appears in the transcript. The article's length relative to the transcript sits inside set bounds, which catches truncated and runaway drafts. No Markdown is left over, and links go only to YouTube and the creator's own pages. A second pass with a cheaper model flags sentences the transcript does not support, and above a threshold the video is held. A failure stops that video and leaves the others alone.

What a reader sees

Open the demo and, under the site name, there is a notice that it is a preview built from the channel's videos, not yet claimed, and hidden from search engines. That last part is real. Crawlers read robots.txt only from the root of a host, and every demo shares one host, so a single file disallowing everything covers all of them. When a site moves to the creator's account it leaves that host and the block stops applying, with nothing to flip. A blocked address can still appear as a bare link if someone links to it publicly.

The home page has Home, Journal and About, a tag list with counts, search, a light and dark switch, an RSS link, and the three articles as cards with a summary and a reading time of 16, 20 or 27 minutes. An article opens with its summary, author and reading time, then an outline of its sections. The one we opened has seven, a line crediting the original video with a link, and a "Watch from 1:09" style link at each section. The video's thumbnail is the hero image. The video is a link, not an embedded player, because our render policy strips iframes. At the foot are a Like button, a conversation area that says it needs JavaScript, and newer, older and related articles.

Who approves what

The three sample articles go live on a demo address that Galascribe owns, with no per-article approval from the creator at this stage. Our automatic checks are the only gate in the software: a draft that fails is not landed at all. We also read the drafts ourselves before a demo goes live.

The step after a claim is not built. The pipeline design imagines new videos arriving as drafts for the creator to review and publish, but today nothing in Galascribe proposes new articles to a creator once a site is claimed. From then on the site is the creator's to write in.

Claiming the site

The operator command prints a claim link once. The creator opens it, signs in with GitHub and proves they own the channel. The preferred proof is Google's read-only YouTube permission: we use the access once to ask which channel the person owns, compare it with the channel the site was built from, and revoke it. We do not store the token. The fallback is a one-time code, valid for 24 hours, that the creator pastes into their channel description for us to check through the YouTube Data API.

Accepting makes the creator the owner of the organisation that holds the demo, after a recent GitHub authentication.

Moving it into their repository

The creator makes a GitHub organisation (we recommend one just for Galascribe), installs the Galascribe GitHub App on it and clicks "Move my site". The site repository itself is transferred, not copied. We re-link it only when a handover is expected for that exact owner and a live read through the new installation shows it is the same repository, never on a webhook alone.

The change that sets the new address, rewrites the description to a neutral default and removes the preview notice from the About page is planned and confirmed in the creator's own session. A change should stay a person's act. Likes and comments are tied to the publication and article rather than to a web address, so the ones left on the preview survive the move.

The result we test for is a site at the creator's own github.io address, with canonical links, sitemap and og:url on the new address, no preview notice, search engines allowed, and the next publish working from their account. A creator can then move the site to a domain they own from its Domain page, which shows the exact DNS records and checks them; a later post covers that. We have run the claim and the move end to end on demo sites for a channel we own; no creator has done it yet.

Where it runs out

A transcript is speech. Maps, diagrams, on-screen text and demonstrations are gone, which is why the rules drop "this map" and why the notes record what was left out. Readers who need the visuals have to follow the link back to the video.

Captions mishear proper nouns. We list corrections and mark uncertain ones, but we cannot always tell a mishearing from the speaker's own slip. A check that every number appears in the transcript cannot tell whether the speaker misspoke, and the second pass is one model grading another's work. It flags; a person decides.

Softening crude phrasing is an editorial hand on someone else's words, which is why every change is listed. Math is not rendered. And creators cannot start the route on their own.

To start a site of your own, the start flow is at https://app.galascribe.com/

TL;DR: One night in July 2026 I lost three hours to a feed, and Galascribe began as the fix: a slow place for writing, with no feed, built to respect attention. Months in, our pitch had drifted to "articles from your videos". A video by Sandeep Swadia on writing with AI brought me back, and gave us our motto: Sound like no one else. A writing platform should build healthy habits, not chase virality.

It was the last week of July 2026. I had just flown back from India, I was jet-lagged, and at 10 PM I opened X. When I put the phone down it was 1:15 AM.

The next morning I drove to work on too little sleep. Somewhere on that drive I asked myself a question I couldn't shake: why did I do that? I knew the scrolling was bad for my head. I knew a tired drive is a dangerous one. I did it anyway, for three hours.

The honest answer is that the product worked as designed. A feed that never ends, ranked to keep you there, paid for by advertisers who want your time. Knowing that doesn't protect you from it, and especially not at midnight with a jet-lagged body clock.

So I tried to fix it from first principles, at two levels. At the platform level: what would a place for reading look like if it were built to respect attention instead of harvesting it? At the content level: what would people write if the reward were being useful instead of being loud? Galascribe came out of that drive.

What I wanted to build

I wanted something slow and organic. A platform that is happy to serve readers less, on purpose, because a limit on quantity forces you to work on quality. Galascribe is bootstrapped from my own pocket, which means there are no investors to please and no ad commitments to honour. That is the only reason the slow version is possible at all.

Here is what that means in the product today, without dressing it up:

• There is no feed. No timeline, no trending list, no recommendations. Readers follow an author and hear from that author. Nothing ranks one writer's work against another's to keep you scrolling.
• Posts can arrive on a schedule. Staggered release lets an author write several posts at once and have them go out on dates they choose, instead of all at once.
• We practise the pace ourselves. This blog publishes two posts a week, Sunday and Friday. Not because we can't write more, but because nobody needs more from us than that.

What it does not do yet is judge quality. I have ideas about how to measure it and what to lift up or push down, but I won't claim any of them until they're tested on real writers and proven to work. A platform that says it rewards quality and can't show how is just another marketing line.

How I drifted

Building a product pulls you towards whatever is easiest to explain. For a while our pitch was "Articles from your videos, on a website you own." It described one feature well. It was also narrow, and it didn't give anyone much reason to try us. Worse, it had quietly moved me away from why I started. That line is about producing more content faster, with AI doing the work and the person tidying up after it. I set out to do the opposite: to help people's own work, and let AI serve it.

The video that brought me back

Then I watched Sandeep Swadia's Everyone Can Spot AI Writing, Here's How To Fix It. Galascribe already existed; the video didn't start it. What it did was give the project its direction back, and help me put into words what I believe about writers in 2026.

His point is simple: AI can write everything for you, and that is exactly why everyone sounds the same. In his words, AI gives you an accent. He sets out a five-step check that spells VOICE: is it verified, is it owned (built from your own experience), is it insightful, is it clear, is it engaging. He opens by promising writing that is "clearer, more insightful, and unmistakably yours".

That phrase stayed with me, and it's where our new line comes from. We changed what Galascribe says about itself to:

Sound like no one else. Write clearly. Share insights that are unmistakably yours.

The debt is plain, and I'd rather say so than pretend we got there alone.

His VOICE steps changed how we work too. This post was written that way: I was interviewed one question at a time about what actually happened, my answers were checked against our own code and records, and every claim about the product that couldn't be verified was cut. Further out, I'd like Galascribe to offer authors a VOICE-style review of their own drafts. That is a plan, not a feature, and it will stay a plan until it's built and tested.

What I believe

Most people believe a writing platform should chase engagement: help you go viral overnight, change the world, please everybody.

I believe it should build healthy habits instead. It should not turn readers into test subjects for attention-hungry feeds, or writers into editors of whatever a model produced. It should be gentle, and it should carry knowledge that is actually worth someone's evening.

The difference comes down to a few things:

• Not everything is about money. That doesn't mean free. Galascribe has to keep the lights on and feed my family. But I hold to a simple rule: hunger has a limit; ego doesn't. Charge enough to keep going, and be ambitious only where it helps the people using it.
• Ordinary is fine. A moderate, simple post that teaches one person one useful thing is a good post. Not every piece has to perform.
• Try things anyway. I'd rather encourage people to be a little shameless, publish the idea, and see what happens, than wait until it's perfect.

None of this asks writers to give up reach. Post your links wherever your readers are. We are just not going to build another place that rewards stunts over substance. We are not trying to please every audience either. A handful of readers and writers at first is enough, if a few of them spend one fewer evening the way I spent that one in July.

Where this leaves us

Sandeep closes his video with a line I keep coming back to: you don't write just to find words, you write to find out what you think. Writing this post, I found out what I think. Galascribe exists so that night in July happens to fewer people, and so the writing they find instead sounds like a person.

To start a site of your own, the start flow is at https://app.galascribe.com/

A preview site is how we pitch. Galascribe turns a creator's YouTube videos into articles on a site they own, and an example from someone else's channel does not show a creator what their own would look like. So we pick three of their videos, write an article from each full transcript, have a second model check every draft against the transcript, publish the three as a small site that search engines are told to ignore, and email a link that says it was built for them. The email also says one email takes it down. On 2026-10-23 we had decided to build one of these for every prospect before the first email. On 2026-10-24 we automated it. On 2026-10-25 we changed the order.

The evening in numbers

Each preview costs the same set of model calls, with retries:

We did not pay those API prices. There was no API budget, so the work ran on the subscription, where the unit is not a bill but a weekly limit, and half of it was gone in four hours. For scale: the seven agents that wrote the automation that day used about 750,000 tokens between them, and the first evening of running what they wrote used five to seven times that. The session directing those agents ran four hours and several hundred tool calls on the most capable model available to us, which is its own lesson about who should do the typing and who should only review.

Three things went wrong, and one went right

Two runs were wasted on our own mistakes before anything useful was built. The first started from a fresh clone of the repository that had never had its packages installed. Every article the model wrote failed the front-matter check, not because the front matter was wrong but because the checker could not load its YAML package. The writer was shown one word, FAIL, so it rewrote the article, up to three times, and failed the same way each time. The second mistake followed from the first. A run's results are cached, failures included, so when we fixed the clone and ran again, the cached failures came straight back and the same articles failed before anything had been checked. We found that only after clearing the cache. A failure caused by a broken environment is not a verdict on the text, and caching it as one poisons every later run.

Those two were bugs, and bugs get fixed. The third problem was the design, and it would have cost the same amount every evening. We generated ahead of interest. A minority of cold-email recipients open the email, and fewer click the link. At those rates most of the 23 sites would have been taken down unvisited, after costing 150,000 to 250,000 tokens apiece. "Automate everything" and "generate before anyone asks" each sound like sound engineering. Together they multiply the waste by the number of people who never open the email.

What went right was the faithfulness check. Each draft goes to a second model with the transcript and one question: does the article say anything the video did not? That night it rejected three drafts. One claimed the creator had called a configuration file "bloated", a word the video never used. One misread a figure from a chart in the video. Those three sites were not published. A preview that misquotes the person it is trying to impress is worse than no preview, and the pipeline knew that when we did not.

Build it when they click

The fix is obvious in hindsight, and we decided it on 2026-10-25: generate the site when the creator clicks, not before. As of that date it is designed and not yet built, and the scheduled job that pre-built sites is switched off.

The nightly job shrinks to the cheap steps. Pick three videos, fetch the transcripts, write the email naming those videos rather than articles that do not exist yet, and register the creator's page with a small Cloudflare Worker. The email links to that page. Before anyone clicks, it is a waiting page that names the three videos and says the site is being built from them.

The first click starts generation on the Mac, which is always on and polls the worker for requests. The three articles are written in parallel and appear on the page as they finish, the first in about a minute, so the person reads an article instead of watching a spinner. The faithfulness checks run, the site publishes in the background, which takes four to seven minutes today, and the page redirects when it is live. If they leave before then, we email them the link.

Tokens are spent only on creators who clicked. Unclaimed sites stop existing, because they never existed, and there is nothing to take down. And the click becomes the engagement signal we did not have: at a 10 to 30% click rate, twenty emails a day turn into two to six generations a day, and 70 to 90% fewer generation tokens for the same outreach volume.

Rules we keep now

• Estimate tokens before a batch the way you would estimate dollars, and print the estimate before the run starts. Nothing runs more than three generations without a person saying yes.
• Put the expensive step behind the first signal of interest. A click is cheap to detect, and it is the only evidence that anyone wants what you are about to build.
• A failed check caused by the environment is a failed check, not a verdict. Clear it with the fix, and show the writer the reason, not one word.
• Keep the check that says no, even when it costs tokens. The three drafts it rejected were the only ones that would have embarrassed us.

To build a site from your own videos, the start flow is at https://app.galascribe.com/

What is in the repository

A repository that Galascribe creates is generated from the repository template, the layout every new site starts from, and the repository template's README says the repository is the publication: your settings, your author profile, and every article and page. Articles and pages are single Markdown files in content/. Each begins with a short block of settings, the front matter, between two --- lines:

---
schemaId: urn:gala:schema:content-frontmatter:2.0.0
schemaVersion: "2.0.0"
id: <a stable id — do not change once published>
kind: article
title: My new article
language: en-US
authors:
  - <your author id, from gala/authors/>
tags: []
status: published
createdAt: "2026-01-01T00:00:00.000Z"
slug: my-new-article
redirects: []
extensions: {}
---

Write your article here, in Markdown.

That is the repository template's own example, trimmed to one line of body, with the placeholders left in. kind is article for a dated piece that goes in your feed, or page for something like an About page. The author is a reference to a file in gala/authors/, so a biography is written once.

The rest is plain files too. gala/publication.json holds the name, description and base address. gala/navigation.json holds the header and footer links, gala/appearance.json the theme, and gala/modules/interactions.json whether likes and comments are on. Images live in assets/. Two files, gala/repository.json and gala.lock.json, are managed by Galascribe, and the README says you generally will not touch them.

Edit it anywhere

You can write in the Galascribe app, which commits for you. You can also clone the site repository, edit in any text editor and push. The README puts it in one sentence: both ways work, because everything Galascribe needs is in the files themselves.

A push you make by hand is safe but does not publish anything. It moves the head of the repository, and the next accepted publish deploys whatever the head is.

Hosting you also own

The default destination is GitHub Pages. Publishing is done by the publish workflow, a file in your site repository at .github/workflows/gala-publish-v2.yml. It runs in your GitHub account on GitHub's build minutes, not on our servers. The README also says nothing there runs code you wrote or installs anything on your behalf: the tool only reads your articles, settings and images and turns them into a website.

Our design for a second destination, DigitalOcean Spaces, has the same shape: two buckets in your own account, one serving the site and one private for staging. The README lists it as not offered yet. One decision from that design is worth recording. We chose not to build a "verify my buckets" check, because we hold no credential for that account and a check that reports success without being able to look would be lying.

Who creates the repository

If the site repository does not exist yet, Galascribe can create it, but as you rather than as us. Creation uses your own GitHub authorization, never an installation token or the Galascribe GitHub App's own key. GitHub therefore decides what you may create and where, and we add no authority of our own. The repository is generated from the repository template using that same authorization, and it comes with a default branch already in place, because linking reads the default branch and an empty repository has none. Creating and linking are two separate confirmations. We never delete, rename or change the visibility of a repository.

What this costs us

We would rather list these than have you find them.

• We cannot keep anyone. There is no export step for your writing because there is nothing to export: the writing and its history are files in your repository, while likes and comments are held by our service and have no export today. A creator can leave with a clone of the site repository. We hear about changes to a repository from GitHub's events. A rename updates our record. An archive or a delete ends our authority over it, and so does a transfer to an owner who has not installed the Galascribe GitHub App. We react afterwards. We do not get a say.
• We do not serve the site. GitHub Pages answers the reader's request, so the serving side is not ours to change.
• Publishing is something Galascribe drives. The README says that when Galascribe builds and publishes your site, the work runs in your GitHub account. What you hold outright is the content: plain Markdown files with front matter in a repository you own, and the renderer that turns them into a site is published as versioned packages. There is no documented way to build and publish without Galascribe yet. We are focused on the minimum product, on measuring real traction, and on earning product-market fit before we invest in second-priority features, and a build-it-yourself guide is one of those. The files are still plain Markdown in your repository today, so nothing stops you rendering them another way. We have just not written the guide.
• Your readers' replies are not in the repository. Likes and comments need a server, so Galascribe's service holds them, tied to the publication and the article rather than to a web address. interactions.json only switches them on or off. There is no export for them today. That is a real limit of the thesis of this post: "nothing to export" is true of your writing, and not true of what your readers add to it.
• Hand edits can break a build. A file edited by hand can be wrong in a way the app would have refused. When a build fails, the error shown usually names the file and the setting. We cannot stop the edit.

Put together, that is fewer levers. We cannot hold your content, we cannot hold the serving, and we cannot make leaving awkward.

Why we chose it anyway

The constraint is also a discipline. If everything Galascribe needs is in the files, then the files are the source of truth, and any feature that needs hidden state has to justify itself. Likes and comments are the one place we had to, and we say so above rather than burying it. I built it this way for the reason in our tagline: you should own every word you write, and I do not want your archive to depend on whether Galascribe is still around.

A post is a long-lived thing. Plain Markdown and JSON in a git repository can be opened by any editor, with or without us. To us that seemed a more durable thing to hand a writer than an export button.

It also narrows what you have to trust us with. GitHub holds the repository and enforces who can touch it, and GitHub's own build minutes do the publishing. What you grant us is a set of permissions for the Galascribe GitHub App in your own account, not custody of your work.

To start a site of your own, the start flow is at https://app.galascribe.com/

Begin with the question

Before choosing a cadence or polishing a logo, write down the question you want to keep exploring. A durable question gives readers a reason to return and gives you somewhere honest to begin when the blank page feels too large.

A publication becomes distinctive through accumulated attention, not a single perfect launch.

For the first month, keep the practice deliberately small:

1. Publish one useful observation.
2. Explain the evidence behind it.
3. Invite a thoughtful response.

Make the place your own

You can write in the Galascribe app, or edit the files in this repository directly and commit them with git — both work, because everything Galascribe needs lives in plain files.

Change the publication details, replace the author profile, and rewrite this article in your own voice. The Editorial theme will use the same content across its home, article, archive, series, and author views without locking it into a page-builder format.