The site you are reading right now runs on software I wrote. So does swiftrics.com, the platform's own site, and so does nomadsamor.com, the travel site my wife Fabiola and I keep while we travel the country. Building your own website platform is the kind of project that needs explaining, because on paper it sounds like a solved problem. WordPress exists. Wix and Squarespace exist. Static site generators exist. Why write another one?
Because none of them fit the actual shape of the problem, and the shape of the problem is smaller and more specific than the tools built for it.
The itch
Most small business websites are the same site. A home page, an about page, a services or products page, a contact page, and a blog. Maybe ten pages total, updated a few times a month, read by people who want an answer and want to leave.
The tools available for that job split into two camps, and both bother me.
The first camp is the traditional CMS. You get a database, a theme, a plugin ecosystem, and a server that assembles every page on demand. For a ten page site, that is an enormous amount of running machinery. Every request goes through a stack that has to be patched, updated, and watched, and the pages come out slower than they need to be. You are paying an ongoing operational tax so that software can do, at request time, work that could have been done once at publish time.
The second camp is the fiddly one. Static site generators produce exactly the fast flat output I want, but getting there means config files, build pipelines, and a workflow that assumes the person publishing is comfortable in a terminal. That is fine for developers. It is not fine for someone who just wants to post an article about their business.
So the itch was simple: I wanted the output of the second camp with the day to day experience of the first. I make the longer version of this argument on the Swiftrics blog, including a piece comparing static HTML against WordPress, but the short version is that a few pages and a blog should be served as flat files, full stop.
Publish means export
That belief became the core design decision in Swiftrics. Publishing a site does not mean flipping a flag in a database. It means exporting the entire site as plain static HTML, and those flat files are what visitors get. There is no database lookup or server-side rendering sitting between a reader and the page.
The consequences fall out naturally. Pages load fast because there is nothing to compute. There is no runtime stack to patch or babysit, because there is no runtime. And the workflow is draft-first by construction: every change starts life as a draft, and nothing goes live until a publish run regenerates the export. The editing environment and the live site are cleanly separated, which turns out to be a calmer way to run a website than editing something that is already public.
Components instead of a blank box
The other half of the design is how pages get built. In Swiftrics you assemble pages out of components: rich text blocks, images, video embeds. Layouts come with rules about which components can nest inside which, so you cannot accidentally wedge a page into a shape the design never intended.
Around that sit the pieces a real site needs. Blog sections have categories and tags, so an article lands on the right listing pages without any manual wiring. A media library handles image uploads, and each page can carry a thumbnail and a hero image that feed the blog cards. Video embeds for YouTube and Vimeo render as responsive players in the static export.
None of this is exotic. That is the point. The feature list is scoped to what a small site actually uses, and each piece is built to survive the export to flat HTML.
The dogfooding loop
Here is the part that has shaped the platform more than any design document: I run my own sites on it, and I publish real content through it constantly.
Everything the editor can do is also available through a REST API. Creating pages, uploading media, managing categories and tags, triggering publishes, all of it. My own writing workflow runs entirely through that API: articles are drafted as markdown, converted to components, posted, and published the same way. Most of what I write never touches the visual editor. This post got onto the site exactly like that.
Because the content is real and the deadlines are mine, gaps do not survive long. When I hit a missing feature or a rough edge while publishing an article, I am both the annoyed user and the developer who can fix it, usually the same day. That loop, hit the gap in the morning and ship the fix in the afternoon, has done more to shape Swiftrics than anything I planned up front.
Where it stands
I want to be straight about the current status. Swiftrics is in closed beta. It powers my own web properties, this site included, while the product hardens in production. I am not going to dress that up with customer counts or growth numbers, because the honest description is a working platform being proven on real sites, mine, every day.
That is also the pattern I trust most in my own work: build the tool, then run real things on it until it holds up. Swiftrics has been holding up, and every article I post is another rep.
If you want more detail on the platform itself, I keep a Swiftrics project page here on this site, and the full pitch, including the comparisons against WordPress, Wix, and Squarespace, lives at swiftrics.com.