WaypointAds did not begin with a business plan, a polished specification or a grand ambition to build a commercial Joomla extension. It began with a much simpler problem: I needed a better way to manage advertising on my own Joomla websites.

At the time, I was using existing advertising software that had become increasingly unsuitable for what I wanted to accomplish. Rather than continue working around somebody else's abandoned or aging ideas, I began considering whether it would be possible to build something specifically for my own needs. The original project was consequently rather unimaginously called MTD Ads, because its first job was simply to manage advertisements for Mark The Day.

There was no expectation in those first days that MTD Ads would become what WaypointAds is today. The objective was considerably more modest: create advertising Zones, put advertisements into them, display those advertisements through Joomla modules and keep track of what happened.

The earliest surviving development build had separate component and module versions and was still well below version 1.0. Yet the basic machinery was already working. Administrators could create Zones and advertisements, assign advertisements to Zones and have a Joomla module display them. Multiple advertisements could share a Zone, with one selected on each page load. Image dimensions could be validated, destination URLs worked, and the system was already counting impressions and clicks and calculating click-through rates.

It wasn't sophisticated, but it worked.

That was important because the first principle of the project emerged almost immediately: build something useful before building something impressive.

The next major realization was that individual advertisements were the wrong center for the system. Real advertising is organized around campaigns. An advertiser may have several advertisements promoting the same campaign, and that campaign may need to appear in several places across a website. Treating every advertisement as an independent object would eventually make management unnecessarily complicated.

That realization fundamentally changed the architecture.

Ads became Creatives, and Campaigns became the organizing center of WaypointAds. An Advertiser could own Campaigns, a Campaign could contain multiple Creatives, and Campaigns could be assigned to one or more Zones. A Zone could then choose an eligible Campaign and an eligible Creative for display. That structure provided the foundation for almost everything that followed: rotation, scheduling, statistics, priorities, targeting and eventually commercial advertising.

The basic relationship became: Advertiser → Campaign → Creative → Zone, which sounds obvious now but it wasn't obvious when we started.

Another principle appeared during this period that has survived virtually unchanged: the Administrator should not have to bounce between WaypointAds and Joomla's Module Manager simply to manage advertising. Joomla modules are excellent display mechanisms, but the Administrator should be thinking about advertising Zones rather than the technical module required to render them.

WaypointAds therefore began creating and managing its Joomla modules automatically. The Administrator could create a Zone, choose its position and determine where it should appear without leaving WaypointAds. Menu assignments developed to support all pages, selected pages or every page except selected ones. Standard advertising dimensions were added, followed by custom sizes for websites with their own requirements.

That became another permanent development rule: work with Joomla, but don't make the Administrator do Joomla's plumbing by hand.

The project was also beginning to acquire a personality.

Instead of asking only whether a feature technically worked, we started asking whether it felt natural. Could an Administrator understand what to do without reading a manual first? Was an unnecessary choice being presented? Did a screen explain what would happen next? Was WaypointAds helping the Administrator or merely exposing database controls with attractive buttons?

By early July, the development notes recorded an important change in direction. The original goal had been to “build an advertising extension.” The new goal was to build the advertising extension administrators wish had always existed. That distinction affected almost everything that followed.

A First Run Experience was created around the actual workflow: create an Advertiser, create a Zone, create a Campaign and add a Creative. Progress indicators guided a new Administrator through the process, while experienced users could dismiss the guidance. Campaign creation was prevented when no Advertiser existed because a Campaign without an Advertiser made little sense. When only one sensible choice existed, WaypointAds increasingly made that choice automatically instead of presenting another unnecessary dropdown.

The Health system grew from the same philosophy. Rather than simply reporting whether the software itself was functioning, Health began examining the quality of the advertising setup. Missing alternative text, campaigns approaching their end dates and missing images could be brought to the Administrator's attention.

Importantly, Health was not designed to scold.

Alternative text, for example, was encouraged rather than made compulsory. WaypointAds would explain why adding it was worthwhile while leaving the final decision with the Administrator. The philosophy became inform, don't scold.

Several other development principles emerged naturally during this period: protect the Administrator, reduce uncertainty, keep things simple, behave like Joomla, guide rather than lecture, and make every part of the interface useful. These were never written by a committee or borrowed from a software-development textbook. They came from repeatedly using WaypointAds and noticing the moments when something simply didn't feel right.

Testing developed much the same way.

The formal name eventually became the Chrome Hammer, but its operating instructions were considerably simpler:

"Go and try to break it."

Instead of testing only the sequence we expected customers to follow, we deliberately did things in the wrong order. We created multiple Zones, Campaigns and Creatives. We changed assignments, saved things repeatedly, upgraded existing installations, removed things that probably shouldn't have been removed and generally behaved like users who had never attended the development meetings.

If something broke, we fixed it. Just as importantly, if something technically worked but felt awkward, we treated that as a problem too.

By July, WaypointAds no longer felt like a small replacement for the advertising software that had prompted the project. It was developing an identity of its own.

The customer journey became increasingly important. Advertising Packages were connected with permitted Zones, and a fundamental rule was established: an advertisement could narrow the page coverage allowed by its Zone, but it could never broaden it. Campaign approval replaced the idea of approving every Creative individually, allowing an advertiser to prepare the entire Campaign before asking the Administrator to approve it.

The Advertiser Dashboard followed the same philosophy. It was not intended merely to dump statistics onto the screen. We began describing it as a conversation. It should reassure the advertiser, tell them what was happening and help them understand what they should do next.

Sometimes the correct answer to “What should I do next?” is nothing.

If a Campaign is running properly, its balance is healthy and nothing requires attention, WaypointAds should say so rather than manufacture busywork.

We also learned what not to build.

At one point, development of the Creative system was drifting toward a reusable asset library with increasingly elaborate management functions. Then came the realization that we were accidentally building a Digital Asset Manager. That wasn't the purpose of WaypointAds. The additional complexity was discarded. If an advertiser wanted another advertisement, they could upload another advertisement. ~ Simple won.

By the end of July, extensive Chrome Hammer testing demonstrated that the basic advertising manager was becoming a genuinely usable product. Advertisers, Campaigns, Creatives, Zones, statistics, approval workflows and manual campaign management were all functioning together. The question was no longer whether WaypointAds could manage advertising. The question was how far beyond that foundation it should go.

For a short period, the answer appeared to be two separate editions: a free Community Edition for manual advertising management and a commercial edition for selling and automating advertising. That distinction was useful because it established an important boundary. Core advertising management should not be crippled simply to create reasons to purchase the commercial product. The commercial value would come from selling advertising, advertiser self-service and automation, not from deliberately weakening the basic manager.

That idea survived, although the two-edition model did not.

On August 6, another major decision was made. WaypointAds would become one installer, one codebase and one product. The terminology evolved from Community and Pro into Core Features and Commercial Features. License Dock was integrated so that entering and activating a valid license immediately unlocked the Commercial Features. Deactivating the license returned the installation to Core without requiring another package or replacing the software.

This was the point at which WaypointAds stopped feeling merely like an extension we were developing and began feeling like commercial software.

The architecture continued expanding around the deliberately simple advertising core. A public Rate Card allowed prospective advertisers to see available opportunities. Advertising Packages could provide quantities of Advertising Credits. Each advertiser received a Wallet, while a Ledger recorded every credit entering or leaving it. The Wallet was designed never to fall below zero, and an important distinction was established early: Advertising Credits represent advertising value; they are not stored cash.

Payment processing followed. Stripe and PayPal were integrated and tested in their sandbox environments. Successful payments had to credit the Wallet exactly once. Failed, canceled, abandoned, expired or duplicated transactions must never accidentally create Advertising Credits. Webhooks were incorporated so fulfillment would not depend solely upon an advertiser's browser successfully returning from a payment provider.

Advertiser onboarding became another substantial project. WaypointAds learned to create the Joomla User Group and Access Level required for advertisers, but an important boundary was deliberately maintained: Joomla remains responsible for authentication and passwords. WaypointAds would work with Joomla's security mechanisms rather than attempting to replace them. Testing the journey of our fictional advertiser, Valerie, exposed awkward points in registration, approval, mandatory password changes and the route back into WaypointAds, allowing the workflow to be refined around what an actual advertiser experienced rather than what the code claimed should happen.
That approach—following the user's journey—has probably influenced WaypointAds more than any individual feature.

Eventually the extension moved from the development site to Mark The Day, the website whose advertising needs had helped start the project in the first place. That changed the nature of testing again. WaypointAds was no longer operating only with carefully constructed test data. It was being used on a large working Joomla website, managing genuine advertising positions alongside existing modules, article content, caching and Google AdSense.

Real use immediately found things laboratory testing had missed.

Module positions needed to change reliably. Article-embedded Zones needed to work without conventional module positions. Module Classes needed to survive synchronization between WaypointAds and Joomla. Mobile and desktop advertisements needed independent visibility rules. Multiple Zones had to support a single Campaign correctly. Wallet balances had to agree with advertising activity. Dark Theme screens needed to remain readable. Tiny switches that looked optional actually had to remember when the Administrator switched them off.

None of these problems individually changed the world. Collectively, fixing them is what turns software into a product. And that brings the development journal to where WaypointAds is today.

The extension that began as MTD Ads, a relatively simple Joomla component capable of putting rotating advertisements into Zones, has become a complete advertising platform with Advertisers, Campaigns, Creatives, Zones, targeting, statistics, scheduling, Packages, a public Rate Card, Advertising Credits, Wallets, a transaction Ledger, advertiser onboarding, Commercial licensing, Stripe and PayPal integration and a front-end Advertiser Dashboard.

Yet the most important part of its development may not be any of those features. WaypointAds has gradually acquired a set of rules about what it wants to be.

• Keep it simple.
• Work with Joomla rather than fighting it.
• Never make the Administrator perform unnecessary work.
• Tell the user what happens next.
• Don't add complexity merely because complexity is possible.
• Protect people's work.

And when everything is working properly, have the good sense to leave it alone.

There is still development ahead. There are things in the bucket that must be addressed before release, and there is another bucket containing ideas that may—or may not—belong in WaypointAds someday.

But the situation is very different now from those first MTD Ads builds. Today, WaypointAds is running on Mark The Day and doing the job it was originally created to do.

Perhaps that is the most appropriate place to begin this journal.

We built the advertising manager we needed. Then we discovered we were building one that other Joomla administrators might need too. And somewhere along the way, Valerie acquired a Chrome Hammer.

Continue