Building Subscription Manager: An Iterative Development Story

Multizone Subscriptions Manager is a Joomla extension package that provides subscription key management for extension developers. Built and shipped to production in just a few months, it demonstrates what disciplined iterative development looks like in 2026 — where the combination of strong product management, clear technical constraints, and AI-assisted tooling can take a solo or small-team project from first commit to a production-grade, cryptographically secure commercial platform without cutting corners.

TL:DR – This isn't vibe coding. This is professional product management with help from AI.

The Problem

Joomla extension developers need a way to manage subscriptions for their products. They need to generate and validate subscription keys, enforce feature limits per tier, handle expiry and renewal, and provide a professional storefront — all without leaving the Joomla ecosystem.

Subscriptions Manager was built to solve this. It is open source software released under the GNU General Public License v3 (GPL-3.0-or-later).

Development Approach

The project followed an iterative methodology, prioritising working software in testable, deployable releases over upfront full-feature planning. Each release cycle focused on a specific capability, validated it in production, and used what was learned to shape the next iteration.

The early 1.x releases established the core architecture: subscription key management, the four-tier system (Trial, Standard, Premium, Enterprise), and the admin interface. Rather than designing everything upfront, the tier system evolved through real usage, starting simple and then adding product feature enforcement, and progressive UX as genuine needs emerged.

From 2.0 onwards, the focus shifted to integration and production readiness. Payment processing via Stripe was needed, which gave rise to a companion Joomla extension, Multizone Payments via Stripe for Joomla — that can be optionally integrated with Subscriptions Manager. A REST API for remote key validation using Joomla API conventions was built, and the extension directory was styled for end users. Each version addressed a specific gap identified from the previous release. Everything uses the Joomla framework and vanilla Bootstrap styling for maximum template compatibility.

DevOps

The project is hosted on a self-managed Gitea instance, providing Git repository hosting, CI/CD pipelines, and release management without reliance on third-party services. This keeps the entire toolchain under our control and on our infrastructure.

Builds are handled by a custom script that packages sub-extensions (component, plugins) into a single installable Joomla package ZIP. The script updates version numbers and creation dates across all manifest files, generates SHA-256 checksums, produces Joomla-compatible changelog XML, and creates update server manifests — all from a single command. Separate build targets for development and production control which update server URLs are embedded in the package, ensuring test builds never point at production infrastructure.

For day-to-day development, the build script symlinks the output directly to a local Joomla test server, so a build-and-refresh cycle takes seconds. For production, pushing a tagged commit to Gitea triggers a CI/CD workflow that runs the build script, creates a versioned release with the ZIP artifact and checksums, and deploys the update XML and extension manifest to the production download server. Tags follow a naming convention — prefixed with prod- for production releases — so the same workflow handles both environments cleanly.

Multiple test environments are maintained in parallel: a Joomla 5 development server and a Joomla 6 development server for testing, and a non-branded site that simulates a customer installation. This ensures that changes are validated across Joomla versions and deployment contexts before reaching production. Database schema changes are managed through Joomla's versioned SQL migration system, with each release generating a migration file automatically.

Eleven production releases were shipped across this period. The pace was deliberate: small, focused releases rather than large infrequent ones. This kept risk low and feedback loops short.

Architecture Decisions

Several architectural choices shaped the project and are worth noting for their practical impact.

Cryptographic Key Validation

Subscription keys are not simple database tokens. Each key is cryptographically signed using RSA-2048 and bound to a specific domain. This means keys can be validated offline and cannot be forged or transferred between sites without detection. The signing and verification is handled by a dedicated SignatureService.

Designed for Third-Party Use

Subscriptions Manager is primarily focused on delivering our own extensions to customers. That said, it is also available for third-party extension developers. The code operates with full key generation and management capabilities on our own sites and on customer sites. On customer sites, Subscriptions Manager validates its own subscription key via the API on our instance. Customer extensions can in turn validate keys via the customer's installation of Subscriptions Manager through the REST API installed as part of the package. Production releases are identical software for our use and for customer use.

Product Features as Data

Rather than hardcoding what each subscription tier unlocks, feature limits are stored in the database per product. Extension developers can define their own feature gates — maximum items, API call limits, access to premium functionality — and Subscriptions Manager enforces them at runtime. New products can define their own tier structure without modifying Subscriptions Manager itself.

Progressive UX for Limits

When users approach their subscription limits, they are not met with a hard wall. The interface uses usage meters that shift from green through yellow and orange to red as limits approach. Contextual upgrade guidance appears at each threshold, showing what the next tier offers and how to get there. The goal is to inform and guide rather than obstruct.

Zero-Friction Trials

All our extensions are freely downloadable as trials. A generic trial key with an expiry date is automatically created for each extension, so users can download and start using the software immediately without registration or manual key setup. The subscription key system only becomes relevant when a user wants to unlock higher tiers of capability.

By the Numbers

The component comprises 95 PHP classes, 22 templates, 31 SQL migrations, and nearly 1,900 lines of language strings. The business logic is concentrated in seven service classes totalling, with the SubscriptionServicehandling tier validation, feature gating, and domain binding.

The package ships as four installable extensions: the core component, a REST API plugin for remote key validation, a system plugin for automated tasks such as expiry notifications, and an internal overlay package for publisher-specific data.

Product Management Comes First

The most important factor in this project's success was not the tooling — it was the product management discipline applied before and throughout development. Requirements were written explicitly. Constraints were defined upfront: which frameworks were permitted, which shortcuts were forbidden, which conventions the codebase had to follow. The product manager made all final decisions and signed off on test results after both manual and automated verification.

This matters because it is the difference between professional software and a prototype that happens to run. Knowing that a Joomla API call must be used instead of a raw cURL request, that Bootstrap must not be overridden, that every database change must go through the migration system — these are not incidental preferences. They are the constraints that make the software maintainable, upgradeable, and trustworthy for customers running it on their own sites.

Documentation created during development was reviewed and corrected across multiple rounds, with the product manager supplying real product knowledge to catch stale references, incorrect tier descriptions, and misleading terminology. These corrections were captured in local patterns documents that became part of the shared knowledge base for building and maintaining Joomla extensions professionally.

AI-Assisted Development in 2026

This project was developed with the assistance of Claude Code, Anthropic's AI coding tool, which has expanded considerably since the project began. Claude Code is now available as a CLI, a VS Code and JetBrains plugin, a desktop application, and a web interface at claude.ai/code — giving developers the ability to work in whatever environment suits the task, from a terminal build script to a full visual diff review in the desktop app.

The iterative workflow suited AI-assisted development well. Each cycle involved reviewing existing code, planning changes, implementing them, and verifying the result. The AI contributed to architecture recommendations, code generation, documentation, and large-scale refactoring — including changes in terminology and philosophy that touched dozens of files simultaneously. It also identified functionality gaps, such as a missing contact route for paid extensions that was resolved in a subsequent release.

Functional testing benefited from Claude's browser-integrated capabilities, which allowed the AI to assist in identifying bugs and verifying behaviour directly in the running application — a practical addition to the manual testing workflow.

What made this work was not the AI's capability in isolation. It was the combination of clear requirements, defined constraints, and a product manager who understood the domain and held the final call on every decision. The AI accelerated execution; it did not replace judgement.

The distinction is worth stating plainly. Vibe coding produces output that resembles software. AI-assisted development, done properly, produces software that can be maintained, extended, and trusted in production — because a skilled product manager shaped every decision and took responsibility for the result.

What Has Changed since the initial production release

Since the initial release, the broader context for this kind of project has shifted in ways that reinforce rather than undermine the approach taken here.

AI coding tools have proliferated and matured. Claude Code now supports a wider range of development environments and workflows, including recurring task scheduling and parallel sessions in the desktop application, and long-running remote tasks via the web interface. The practical implication is that the human-AI collaboration model used here — tight requirements, defined constraints, human sign-off — is now more accessible to small teams and solo developers than it was when the project started.

At the same time, the volume of hastily assembled AI-generated software in the wild has made the qualities that Subscriptions Manager was built to demonstrate more valuable, not less: proper use of framework conventions, cryptographic rigour, upgrade-safe database migrations, and a CI/CD pipeline that treats test and production as distinct environments. These are not difficult things to do. They are things that require someone to insist on them.

Joomla 6 compatibility has been maintained throughout, and the forward-compatibility test environment means the codebase is positioned for the next Joomla release cycle without emergency rework. The self-hosted Gitea infrastructure continues to provide full control over the toolchain, an advantage that has become more relevant as third-party CI/CD pricing and policy has continued to shift.

What's Next

Subscriptions Manager is live and managing its own subscription — a satisfying piece of self-reference. The foundation is solid: cryptographic key validation, flexible product feature definitions, progressive UX, and a clean extension directory. Future work will focus on additional integrations, usage analytics, and making it easier for other Joomla extension developers to adopt the platform for their own products.

The broader ambition is straightforward: demonstrate that the Joomla ecosystem can support commercially serious, professionally built extensions — and provide the tooling to make that easier for the developers who want to do it properly.