Building Subscriptions 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 a matter of months, it stands in 2026 as a concrete example of what disciplined iterative development looks like when strong product management, clearly defined technical constraints, and AI-assisted tooling work together — enabling a solo developer or small team to deliver a production-grade, cryptographically secure commercial platform without cutting corners or accumulating the kind of technical debt that haunts hastily assembled AI-generated software.

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 exhaustive upfront 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, 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 integrates optionally 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 direct control and on our own infrastructure — an advantage that has grown more meaningful as third-party CI/CD platforms have continued to adjust pricing and access policies.

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, 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 the initial development 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 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, with the SubscriptionService handling 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 agentic AI coding tool. By 2026, Claude Code has matured considerably: it is available as a CLI, a VS Code and JetBrains plugin, a desktop application, and a web interface at claude.ai/code. The desktop application supports parallel sessions and recurring task scheduling. The web interface handles long-running remote tasks. Developers can work in whatever environment suits the task — from a terminal build script to a full visual diff review.

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 terminology and structural changes that touched dozens of files simultaneously. It also surfaced 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 complement to the manual testing workflow.

In 2026, the landscape of AI coding tools is crowded. GitHub Copilot, Cursor, Gemini Code Assist, and a range of newer entrants all compete for developer attention. What distinguishes productive use of any of them is not the model — it is the human process wrapped around it. Clear requirements, defined constraints, and a product manager who understands the domain and holds the final call on every decision. The AI accelerates execution; it does not replace judgement.

The distinction is worth stating plainly. Vibe coding — prompting an AI until something runs, then shipping it — 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. In a market now saturated with hastily assembled AI-generated extensions, that difference is visible and consequential.

What's Changed in 2026

The context for this kind of project has shifted in several meaningful ways since the initial production release — most of which reinforce rather than undermine the approach taken here.

The volume of AI-generated software in the wild has increased sharply, and so has the quality gap between software built with discipline and software built without it. Proper use of framework conventions, cryptographic rigour, upgrade-safe database migrations, and a CI/CD pipeline that treats test and production as distinct environments are not difficult things to achieve. They are things that require someone to insist on them — and that insistence is now a genuine market differentiator.

Joomla itself has continued to evolve. Joomla 5 is the current stable long-term support release, and Joomla 6 development is active. Subscriptions Manager maintains compatibility across both, with a dedicated Joomla 6 test environment already in the pipeline. The forward-compatibility posture built into the project's DevOps means the codebase is positioned for the next release cycle without emergency rework.

AI coding tools have matured and diversified. Claude Code in particular has expanded its agentic capabilities — longer context windows, improved code reasoning, and more robust handling of multi-file refactors — making the human-AI collaboration model used here more accessible to small teams and solo developers than it was when the project started. The practical lesson from this project is that the model matters less than the process: tight requirements, defined constraints, and human sign-off at every stage.

Self-hosted infrastructure has also become a more deliberate choice. Third-party CI/CD platforms have continued to revise their free tiers and pricing structures, and several have made policy changes affecting open source projects. The Gitea-based pipeline used here has required no adjustment in response to any of these shifts — a quiet but real advantage of owning your own toolchain.

Finally, the Stripe integration reflects a payments landscape that has continued to consolidate. Stripe remains the dominant choice for developer-facing subscription billing, and the companion Multizone Payments extension continues to handle this cleanly within the Joomla framework. No architectural changes were needed to accommodate Stripe's own API evolution during this period.

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 payment integrations, usage analytics, and lowering the barrier 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 developers who want to do it properly. In 2026, with AI tools making it trivially easy to produce low-quality software at scale, that ambition is more relevant than it was when the first commit landed.