HypnoTech

Choosing to build

When I was furloughed in 2020, I treated the enforced pause from paid work as an opportunity to make something substantial. In roughly four weeks of focused development, I built the foundation of HypnoTech: a reusable ASP.NET Core platform for bespoke content-managed websites.

It was not my first attempt at this problem. From around 2015, my Esoteric website ran on a custom MEAN-stack application using MongoDB, Express, Angular, and Node.js. It worked, but every new public feature needed a corresponding hand-built administration interface. The site and its CMS evolved as parallel applications, making change slower and maintenance increasingly repetitive.

HypnoTech was the architectural answer. I wanted the control of a custom website, the productivity of a generated administration system, and compile-time contracts across a growing codebase. C# and ASP.NET Core gave me the type safety I strongly prefer; conventions, reflection, and fluent mappings supplied the dynamic behaviour.

A dynamic CMS built from strongly typed models

A consuming application describes its editable models through a fluent mapping API. HypnoTech then exposes the appropriate closed generic controllers, routes, lists, forms, validation, uploads, relationships, search, sorting, ordering, and role checks without requiring a bespoke admin controller and view for every content type.

That balance is central to the design. The administration path can be generated from strongly typed metadata, while the public website retains its own models, rendering, and focused read repositories. Editing concerns stay in the Admin host instead of leaking into the customer-facing application.

The engine grew into separate CMS, Common, Ecommerce, Media, Frontend, and persistence modules. It supports content and configuration management, accounts and security, logging and email, uploads and galleries, audio/video, catalogue and basket behaviour, postage and order workflows, partial-page navigation, and reusable browser assets.

SPA-like navigation without turning the website into a SPA

HypnoTech's public frontend remains server-rendered ASP.NET Core MVC. Every destination has a real URL and a normal full-document response, so a direct visit, refresh, shared link, search crawler, or browser without JavaScript still receives a complete page. Routing, authorisation, Razor rendering, page titles, descriptions, and canonical URLs remain authoritative on the server.

For opted-in internal links, a focused browser-side router requests only the changing Razor content. The same controller action returns that fragment with its title, description, and canonical URL; the browser replaces the content region, updates its history and metadata, and leaves persistent interface elements such as the audio player and basket in place.

I designed this pattern to keep the parts I value in frontend frameworks—fast navigation, transferring only what changed, and persistent interface state—without turning a content website into a large client-side application. It is deliberately simple: each page has one server-side route and rendering path, with a small response contract selecting either the complete document or its replaceable content.

The result has much of the speed and continuity people associate with a single-page application, without duplicating templates or shipping a heavyweight React, Angular, or Vue runtime simply to navigate a content website. The elegance is in retaining one authoritative implementation: most of the application remains in strongly typed C#, while JavaScript progressively enhances it rather than becoming a second rendering architecture.

Ambitious infrastructure, then deliberate simplification

I originally treated each library as an independently versioned project with its own repository and CI/CD path through self-hosted TeamCity and Octopus Deploy. At the time I was seriously considering turning the platform into a business, so I built the delivery infrastructure to match that ambition.

For a personal platform, that eventually became more infrastructure than the product needed. I retired the self-hosted services to reduce costs and later consolidated 21 projects into one engine solution. Some earlier Git history was lost during those moves, which is why the current public repository appears to begin with a large working platform.

The repository's first public commit says exactly what happened: “Consolidate 21 HypnoTech projects into a single solution.” It records a migration point, not a sudden greenfield build.

Modernising a real platform with Codex

The existing engine targeted .NET Core 3.1. On 18 September 2026, I used Codex to help move all 21 projects to .NET 10 in a focused session of roughly one to two hours. The isolated upgrade commit makes the framework, package, API, Razor, image-processing, security, and logging changes inspectable.

From the repository's consolidation onwards, essentially all subsequent development has used Codex as an implementation and review collaborator. I remain responsible for the architecture, specifications, trade-offs, verification, and release decisions. Git records the resulting changes and evidence; my first-hand account identifies how the work was produced.

The sharpest example is an extended session on 6–7 November 2026. Over approximately 18 hours, I directed a phased programme that took the existing production-derived engine to two documented public releases.

What one extended session delivered

Characterise before changing

The work began by preserving the production baseline and adding characterisation tests around the dynamic CMS and MongoDB behaviour. Those tests exposed real edge cases in search, child population, ordering boundaries, and repeated module registration, which were corrected and retained as compatibility rules.

The suite then expanded across unit, architecture, integration, provider-contract, and browser levels. It tests real MongoDB, PostgreSQL, and SQL Server instances through Testcontainers rather than treating an in-memory substitute as database evidence.

Build a complete public example

I created Lantern House, a fictional arts-venue CMS and responsive website that exercises the engine as a coherent product rather than a collection of isolated snippets. It includes generated content administration, uploads, galleries, articles and events, media, a persistent audio player, catalogue and basket behaviour, editable navigation/configuration, and progressive partial-page navigation.

The Admin write model and public Website read model remain deliberately separate. A single provider setting runs the example on MongoDB, PostgreSQL, or Microsoft SQL Server, while retaining that architectural boundary.

Test real user journeys

Five focused Playwright journeys run against the actual Admin and Website hosts. They cover authentication and authorisation, dynamic CMS validation and editing, search and ordering, a real image upload reaching the public site, media, server-calculated basket/postage totals, the fail-closed payment boundary, and mobile navigation.

The full journeys run independently in Chromium, Firefox, and WebKit. The central dynamic-CMS journey also runs against PostgreSQL and SQL Server in addition to the default MongoDB path. Failed CI journeys retain traces, screenshots, browser errors, and application logs.

Modernise the request path

I converted CMS, Ecommerce, Media, Frontend, and example request paths to native async APIs with cancellation propagation. Existing production consumers remain protected on a preserved support branch while the public main branch uses async-only repository and I/O service contracts.

The same programme introduced provider-neutral persistence contracts and implemented shared Entity Framework Core repositories with thin PostgreSQL and SQL Server adapters. Each provider must satisfy the same observable CRUD, search, paging, ordering, nested-value, seeding, and lifecycle behaviour already exercised against MongoDB.

Make the AI workflow reusable

The repository now contains AGENTS.md plus six focused Skills for compatibility review, characterisation tests, async request paths, external HTTP testing, change verification, and releases. These encode the rules an agent needs to change the framework safely: preserve public and stored-data contracts, test behaviour before refactoring, keep external tests local, choose checks by affected path, and record release evidence.

This is the part of AI-assisted development I find most valuable. The result is not only faster implementation; each successful decision becomes reusable context for the next piece of work.

Evidence rather than a speed claim alone

The HypnoTech 1.1 release records a 39-project Release build with zero warnings or errors and 124 aggregate tests across unit, architecture, MongoDB, relational-provider, example-integration, and browser layers.

GitHub Actions checks reproducible frontend assets, formatting, build quality, MongoDB 4/8/9 compatibility, PostgreSQL and SQL Server contracts, the example application, three browser engines, two relational browser paths, and informative Linux/Windows/macOS portability. A separate CodeQL workflow scans C#, authored JavaScript/TypeScript, and workflow code.

The repository is public and source-available for non-commercial use. Existing production consumers remain pinned to a compatibility branch, while the public main branch and its fictional example provide a safe, inspectable account of the modernisation.

Why I include this work

• Initiative: turning furlough into a focused period of product and platform development.
• Learning from a real MEAN-stack system and replacing repetitive page-specific administration with a strongly typed dynamic CMS.
• Long-term modular architecture across CMS, Ecommerce, Media, Frontend, and multiple persistence technologies.
• SPA-like navigation and persistent interface state while retaining server-rendered pages, real URLs, crawlable metadata, full-document fallback, and a focused JavaScript layer.
• Pragmatic simplification after learning that per-project CI/CD infrastructure was excessive for the platform's actual needs.
• Modernising .NET Core 3.1 to .NET 10 without pretending the underlying platform was newly generated.
• Directing Codex through architecture, implementation, review, testing, security, documentation, and release work.
• Characterisation-first refactoring and preservation of production compatibility.
• Verification across real databases, real application hosts, and multiple browser engines.
• Capturing successful AI-assisted practices in repository instructions and reusable Skills.