On this page
Seventy-two hours
Three weeks ago I announced on LinkedIn that I was building a custom publishing platform for structured maritime content, with the assembly pattern sketched out, a tech stack chosen, and enough conviction to start building in public. The first post on this site, "I Am Building My Own Publishing Platform," went up shortly after, when Manifest was little more than scaffolding, and eight days later, on 18 February, v0.1 went live. The platform you are reading this on is complete enough to call finished, at least for now, and I want to take stock of what it actually took to get here.
The headline number is seventy-two hours, the total active development time from the first commit to production, tracked honestly across three weeks of evening and weekend sessions. It includes everything: writing the software specification, designing the data model, building the API, building the frontend, writing the editor, setting up the deployment pipeline, debugging the inevitable problems, and migrating actual content onto the platform. It does not include the thinking I did away from the keyboard, which was considerable, or the time spent writing the articles that now live on the site.
In the earlier post about the build process, "Building a Full-Stack Application," I described the first day of development and the initial collaboration between myself, Claude, and Codex. That piece captured the surprise of it: a Master Mariner with no professional software background producing a working application in a single session. What it could not capture, because it had not happened yet, was the long middle of a project, the part where the initial excitement fades and you are left with the actual work of turning a prototype into something you would trust with real content.
That middle is where most of the seventy-two hours went. The assembly pattern, which I described in detail in "When Documents Become Data," is elegant on paper, built around content blocks as reusable atoms, documents as trees of references, materialized paths for ordering, and version pinning on publish. In practice, implementing it meant solving a long tail of problems that the architecture implied but did not specify. How do you sort materialized paths correctly when the segments exceed single digits? Lexicographic ordering breaks; you need to cast to integer arrays. How does the frontend request a document tree and render it with the right hierarchy when the API returns a flat list of nodes? How do you handle the editor state when a user is composing a section that might be referenced by multiple documents? None of these problems were individually hard, but there were dozens of them, and each one required understanding the system well enough to know what the right answer looked like.
The tech stack held up, which was not accidental; I had chosen deliberately boring tools for reasons that only became clearer as the build progressed. FastAPI on the backend, Next.js with TypeScript and TipTap on the frontend, PostgreSQL underneath, Docker Compose for orchestration, Caddy as a reverse proxy: nothing fashionable, nothing that would have raised eyebrows at a conference. Well-documented technologies with large ecosystems perform better in AI-assisted development, because the quality of that assistance scales directly with how much training data exists for the tools in question, and choosing FastAPI over something more obscure was less a technical judgment than a bet on the AI's fluency with mainstream choices.
What AI actually did across those seventy-two hours is the question I want to address most carefully, now that I have enough distance to assess it honestly.
AI was extraordinary at collapsing the distance between a design decision and its implementation; once I knew what a database migration should do, or how a Pydantic schema should validate, or what a React component should render, the translation from intention to working code was fast and, for the most part, correct. The exceptions were real, though: I spent entire evenings on issues that arose from subtle misunderstandings, including the Docker container networking problem where the frontend cannot reach the backend via localhost because they are separate services. But even accounting for those detours, the ratio of productive output to time invested was unlike anything I have experienced.
What AI could not do, and what I did not expect it to do, was make the decisions that required knowing the domain: whether to version narrative sections but edit data tables in place, whether published documents should be immutable editions with new permalinks, how to navigate the trade-off between content reuse and editorial simplicity for a single-author system. These are judgement calls rooted in how technical documentation works in regulated maritime industries, and they determined the shape of everything that followed; the AI implemented those decisions with remarkable competence once I had made them, but the making was entirely mine.
Whether AI can help non-developers build software is no longer an interesting question; this project is evidence enough that it can. The more consequential question is what happens when the people who understand a problem most deeply can build solutions for it without a translation layer. For decades, domain expertise and software development have been separated by a gap that only professional engineers could bridge, and the cost of that bridging meant that a vast category of specialised tools that were too niche for commercial products and too expensive for custom development simply never got built. That category is now accessible to anyone willing to engage seriously with the technical side, and I think the consequences of that will take years to play out.
Manifest is not finished, though it is complete enough for now. The admin interface is functional but spartan, and the next iteration will include features that the first did not: better search, richer cross-referencing, more sophisticated diagram support, all deferred in service of getting something real into production with an architecture capable of accommodating them. But v0.1 is live, the content is real, and the platform works well enough that I am publishing this reflection on it right now; for seventy-two hours of work by someone whose professional credentials are in maritime operations, I will take that.