Boloop-made explanatory illustration: the layers connecting a prototype to a maintainable live website.
Boloop is where I keep my experiments with AI images, project development and personal agents, alongside software, Skills and reading I recommend. Building it gradually made one thing clear: a finished page still leaves a lot of website to build.
A visible hero and clickable menu answer “does something appear?” The next questions are more specific. Where do I edit the content? Who can see it after I save? Can someone still download an attachment after its content is taken down? If my session expires, do I lose what I was writing? Once the site is live, how do I know anyone actually used it?
This account follows the order in which Boloop added those connections. It explains why we needed them, rather than recommending a complete administration system for every personal website.
Changing content needs a stable source of truth
Boloop started with articles, software and Skills, then added project case studies. Their public information differs. An article needs a body and an author; software needs a link to the original project; an original Skill may offer a download; a recommended Skill must retain its third-party source.
Treat them all as attractive cards and those distinctions are easy to erase. Someone else’s software can look like your own product. An outbound click can look like a download. A template can quietly fill an empty author field with the site owner’s name.
For us, the CMS first had to make each item’s identity explicit. The interface takes its title, summary, author and source from published fields, leaving missing information empty. The editor saves a working draft; public pages read a separate published snapshot.
That distinction solves an everyday problem: I can keep editing a live article without showing readers a half-written revision. In early isolated browser acceptance checks, we changed a draft title, refreshed its public page and confirmed the public title stayed unchanged. Restoring an earlier revision also restored a draft, without publishing it automatically.
An upload button needs a complete file lifecycle
Article images and Skill ZIP files both pass through upload, but the server receiving bytes is only one step. Files also need format validation, association with the right resource and public access determined by the content’s status.
In early isolated acceptance testing, we followed one complete path: upload a test ZIP, save its association, publish, download it publicly and compare the downloaded file’s SHA-256 with the stored file. The reverse path mattered too. An attachment still referenced by a draft or published content could not simply be archived. It became archivable only after valid references were removed. Restoring an attachment did not automatically associate or publish it again.
Save, associate, publish, archive and restore now had distinct meanings, rather than being similar-looking status buttons.
An upload error also needs to preserve the user’s input. We injected an object-storage failure in an isolated environment, restored storage and retried with the original form and file. That was acceptance of a controlled failure path. A later timeout in the browser operation tool itself left the upload result unknown. The two incidents cannot be combined into one resolved defect.
Moving the site means walking through login again
A runnable build on Cloudflare Pages does not, by itself, establish that the administrator can use the site.
We needed to check the Google callback, site session, administrator identity and management API permissions separately. Isolated tests show how the application behaves given a particular valid identity. A real login must establish that the browser creates the right session after returning from Google, while ordinary accounts remain denied management access.
A session expiring during an edit is another easy case to miss. Browser checks of an early migration candidate covered a rejected save, hiding the private form, restoring the same administrator session and revalidating it. The unsaved title remained available. This was isolated-environment evidence, not a replacement for a real OAuth callback or live-cookie acceptance, but it made the required behavior concrete.
The deployment target, identity and connected data store are conditions of the same user journey. A successful homepage response cannot stand in for all of them.
Public access connects crawling, permissions and measurement
After the site went public, new problems appeared where different rules met.
The Google verification file passed through Pages routing. Public images could still use attachment URLs with crawler restrictions. Deliberate noindex on recommendation details could be mistaken for a site defect during daily checks.
Each issue needed a check at its actual entry point. For the verification file, inspect redirects and exact response bytes. For an image, check whether its referring content is public, its MIME type and its response headers. For indexing, distinguish the site serving a page from Google having processed it.
Measurement requires the same care. Boloop’s first-party events, GA4 and Search Console have different dates and coverage. A visible number does not mean the sample supports a growth explanation. A visit made to accept a release is not evidence of a new organic-search reader.
Let real use decide what comes next
We did not list every possible system and build them all at once. More content made pagination and search across pages necessary. Actual upload problems made recovery requirements concrete. Operating the site made analytics emails, diagnosis and topic selection depend on handoffs and duplicate prevention.
If you are building a site with AI, I suggest choosing one real journey and completing it. Write an article, save a draft, preview it, publish it, read the correct version anonymously and then check what happens when it is withdrawn. The capabilities involved in that journey define what the first version needs.
Then add a realistic failure: an expired session, temporarily unavailable storage or further editing after publication. Check whether the application preserves work, explains the outcome and can recover.
Boloop’s experience will keep changing. Early development and acceptance took place in an isolated cloud environment. After October 19, 2026, development and isolated testing moved to my Mac, with verified builds then published to Pages. Those boundaries belong in the record: readers need to know which path was actually exercised and which remained a candidate.
A maintainable website grows out of these connected journeys. An AI-assisted interface is a useful starting point. Once content, permissions, recovery and operating results each have a clear place, that starting point begins to become your own product.