I run Typlog, a hosting platform for blogs and podcasts. Recently, I started a new project, Prosefly. It lets you manage documents and articles in a GitHub repository and write with a visual editor.
\nI had already built Typlog. Why start Prosefly too? This is a golden age for static websites: AI has made them much easier to build. When content lives in Markdown and MDX files alongside the website’s code, AI can read and edit it directly, and work on articles and pages together.
\nStoring data in files and writing articles are two separate things, though. I still want a friendly visual editor. Formatting and inserting images feel more comfortable there, so I don’t have to edit source every time.
\nAI has also made it easier to build your own theme. You can change the website to suit your ideas and define its frontmatter fields along with it. For a book review, for example, you could add an author and a rating to the schema.
\nIn Typlog, those fields are predefined by me and are not easy for users to change. Prosefly reads the frontmatter schema defined in the project’s text files and generates the editing interface from it. When making a new template, I don’t have to start by checking whether the platform supports the fields I want.
\nI spent a long time designing the visual editor before starting the complete platform. Most of my attention was on the editor: the files would be Markdown and MDX, but I wanted a visual writing experience. I wanted that part to be mostly ready first.
\nOnce the editor was close to complete, I started working on Prosefly. Even then, I did not jump straight into the web app. I created a GitHub organization, made several Astro themes and templates, and then started building the Prosefly platform.
\nWorking on templates first gave me actual websites in which to organize content, define frontmatter, and see how the editor fit. By the time I started the platform, I already had content to edit and websites that used it.
\nI’m building Prosefly with Cloudflare Workers and need to isolate each organization’s data. I initially chose Workers for Platforms. It can deploy and run users’ Worker code, and it can provide that data separation too.
\nThe project became much more complicated. I had already spent a lot of time on the editor and made several templates, but building the platform kept getting harder. At one point, I considered giving up.
\nLater, I realized that Durable Objects could handle the data separation I needed. Each organization’s data could live in its own Durable Object. It would still be one application, without deploying and managing separate Workers for that purpose. Switching to this approach made the platform much simpler, and I kept going.
","date_published":"2026-10-11T00:00:00.000Z","language":"en","tags":["Prosefly"]}]}