The Long Way to Gixo

On 19 June 2025, I made a commit with the message:

Gave name Gixo, fully transitioned to Blazor Hybrid.

Naming it was not the beginning.

By then, the project had already passed through a language change, a complete framework rewrite, several authentication systems, failed deployments, discarded approaches and hundreds of decisions that only become visible when software stops being an experiment and starts becoming a system.

Today, Gixo comprises seven workflow-specific products: Quill, Lumen, Arc, Business, Lex, Folio and Prism. Beneath them is a shared platform for AI orchestration, source acquisition, evidence handling, editing, collaboration, background processing, metering, billing and export.

I remain its only human software developer.

AI has been used extensively throughout its development. That is part of the story, not a qualification hidden in the footnotes. AI helped me write code, investigate failures, generate tests, understand unfamiliar technologies and move across a much larger technical surface than one developer traditionally could.

But AI did not decide what Gixo should become. It did not determine which abstractions should survive, where deterministic code had to replace probabilistic output, or whether a change was safe enough to put into production. It could propose implementations. It could not assume responsibility for the system.

That responsibility remained mine.

My first serious application

Before this project, my programming experience was limited to BASIC and C at school. Gixo is the first software application I have taken from an idea to production.

When I describe it as the work of one developer, I am not claiming that I manually typed every character without assistance. That would be inaccurate, particularly in the AI era, and it would miss the important part of the achievement.

One developer meant that one person had to understand the product, choose the architecture, evaluate generated code, integrate every subsystem, diagnose production failures, reverse bad decisions and remain accountable for what happened after deployment.

The current repository does not contain the beginning of that story. It starts with a large September 2025 import called “Complete Gixo project.” The earlier repositories preserve what came before it.

The first retained prototype dates to August 2024. Yes, it used Flask.

It was a relatively narrow content-optimisation application. It could acquire material from a URL, improve it using an AI model, calculate SEO and readability scores, compare versions and export the result.

A second version shifted from optimising existing pages to generating and managing new content. OpenAI produced the first draft; Anthropic refined it. The application already understood content types, style rules, keywords, metadata, readability and persistent user work.

The implementation was small, but the underlying workflow was recognisable: acquire context, generate something useful, evaluate the result and give the user an artifact they could continue working with.

In October 2024, I rewrote the application in .NET and Blazor.

This was not a cosmetic port. The new system introduced MongoDB, an API layer, shared domain models, infrastructure services and automated tests. The implementation changed completely, but the product concepts survived.

The repository history is untidy because the project passed through several snapshots and migrations. The continuity is nevertheless visible in the domain model and in hundreds of files that survived into Gixo. Roughly thirteen months separate the earliest retained prototype from the September 2025 platform snapshot.

The large application did not appear in one commit. That commit merely recorded how far it had already travelled.

From generating text to compiling artifacts

The difficult part of applied AI turned out not to be prompting a model well.

A model can produce convincing text that is structurally incomplete, weakly sourced or impossible to export cleanly. A business user does not merely need a plausible answer. They need a proposal containing the required sections, a presentation whose layout survives PowerPoint, a legal draft that does not silently omit an important clause, or a chart whose displayed number is exactly the number they supplied.

That led to one of Gixo’s central architectural principles: generation should behave more like compilation.

Models handle language, judgment and transformation. Typed recipes and style guides define the expected structure. Validators check invariants. Evidence systems connect claims to sources where the workflow requires it. Bounded repair handles recoverable failures. Deterministic renderers take over when an output must be exact.

The distinction is simple:

Judgment belongs to the model. Guarantees belong to code.

The same principle governs the product architecture. The seven products share identity, storage, model routing, source ingestion, metering and export infrastructure. But Gixo does not pretend that an article, a contract, a book, a proposal and a presentation are the same domain object with different labels.

Shared infrastructure reduces duplication. Explicit product rules preserve meaning.

Provider abstraction and fallback routing add complexity, but they protect the application from a market in which model capability, cost and availability change quickly. Long-running work moves into background processing where appropriate. Real-time progress returns to the interface. Uploaded documents require extraction and sometimes OCR. Finished work requires editors, persistence, versioning, sharing and real export engines.

These systems were not added to make the architecture appear sophisticated. They accumulated because the workflows eventually demanded them.

Production was a second education

A system is not competent merely because it works in a local demonstration.

Azure App Service taught me what happens when container restarts invalidate ephemeral data-protection keys: authentication cookies fail, login loops appear and SignalR connections begin disconnecting. The durable solution was to persist those keys outside the container.

Middleware that appeared sensible for ordinary HTTP traffic broke Blazor and SignalR when applied globally. Rate limiting and central authorisation had to be scoped to the routes they could govern safely, while real-time hubs retained their own policies.

Presentation generation introduced a different class of problem. Producing slide text was relatively easy. Producing editable layouts, relevant visuals, stable exports and PowerPoint files that remained useful after generation was not.

Authentication, entitlements, metering and billing also had to become separate concerns. A user may be correctly authenticated without being entitled to a particular product. A generation may succeed technically but still require correct usage accounting. These distinctions are easy to ignore in a prototype and expensive to discover in production.

The history contains wrong turns. A separate WebAssembly client was introduced and later folded back into the server application. UI frameworks changed. Authentication providers changed. Deployment approaches were repeatedly revised.

The old commit messages are unusually honest about this period: “Trying,” “Frustrating,” “on a wing and a prayer,” and eventually “phew.”

Competence is not the absence of wrong decisions. It is the ability to recognise them, understand their consequences and remove them without losing the system.

Gixo now runs on .NET 10 and server-side Blazor. It has explicit product boundaries, protected high-risk areas, focused tests, a curated release gate, production health checks and one canonical deployment path. Those controls exist because the platform earned them through experience.

What AI changed

AI dramatically increased the amount of implementation one person could attempt.

It also increased the amount of implementation one person had to govern.

An agent can produce an excellent local change while misunderstanding the surrounding architecture. Two agents can each follow their instructions correctly and still collide if their work is not isolated. Fast code generation makes specifications, source control, tests, architectural boundaries and adversarial review more important—not less.

As development accelerated, I had to build an engineering system around the engineering: isolated branches and worktrees, defined agent responsibilities, build and test gates, risk rules, production canaries and documentation that records why dangerous areas work as they do.

My role increasingly became one of specification, decomposition, integration and verification. I had to decide when to accept an implementation, when to ask another system to challenge it, when to inspect the code directly and when a passing build was insufficient evidence.

That is the part of AI-assisted development that commit counts cannot show.

The scarce resource is no longer typing. It is judgment.

What I consider the achievement

The achievement is not the number of lines in the repository. Generated files, historical artifacts and AI assistance make that a poor measure of anything important.

It is not the number of products by itself either. Breadth without coherence can become a liability.

The achievement is continuity: learning an unfamiliar stack, rewriting the application, deploying it, recovering from failures, integrating increasingly difficult domains and continuing to maintain a working mental model of the whole platform.

Gixo is not equally elegant everywhere. Building broadly before identifying the clearest market entry introduced accidental complexity alongside genuine capability. Some systems should remain because they create product value. Others should be simplified because they exist mainly as evidence of history.

Being able to distinguish between those two categories is now part of maintaining Gixo.

I did not begin this project knowing how to architect a platform. The repository contains successful decisions, abandoned directions, production mistakes and systems that became stronger because they failed once.

It is not the record of a perfect plan.

It is the record of learning how to take responsibility for one.