Where this begins
I have been writing code for more than forty years. That is not a boast. It is context. The first language I learned was Pascal: structured, formal, designed to teach you to think before you typed. Then C, which rewarded a different kind of thinking entirely, closer to the machine, less forgiving, but more honest about what was actually happening. Then the web arrived, and with it HTML, and then the server-side languages that made HTML dynamic. By the time PHP was the language most of the dynamic web ran on, I had already been through enough technology generations to have developed a healthy suspicion of the next new thing. I had watched languages and platforms rise, gather communities, and fade. I had seen promising tools become legacy burdens. I had learned to notice the difference between a technology that was genuinely solving a problem and one that was solving a problem that the previous technology had already solved, with more ceremony.
PHP did not feel like that. I started using it in the mid-nineties, not long after it was released. It was one of those languages that arrived at exactly the right moment, when the web needed a way to put data onto a page without writing a full backend from scratch. It was pragmatic in a way that C was not, dynamic in a way that static HTML could not be, and immediately useful to anyone who needed to build something real. In 1997 I built one of the earlier e-commerce implementations using it. Not a proof of concept. A working store, taking orders, handling transactions. This was before there were frameworks for any of that, before there were tutorials, before there were Stack Overflow answers to copy from. You read the manual, you read the source code, and you worked it out. PHP had rough edges, as all honest languages do. But it worked, and the ecosystem around it grew fast enough that the rough edges got smoothed by accumulated community knowledge as much as by the language's own evolution.
By 2005 I was contributing to the PHP documentation team. Not the language itself. I did not write a single line of the C code that made the engine run. What I wrote was the manual. The reference material. The explanations of functions, the code examples, the clarifying notes that told a developer what a function actually did when the formal specification did not quite say it plainly enough. It was a particular kind of contribution: not building the thing, but making the thing intelligible to the people who needed to use it.
The work was collaborative in the way open source was collaborative before GitHub made collaboration visible to everyone. Version control ran on CVS. Contributions were tracked in commit logs that most people never read. The community was a mailing list, a shared style guide, and a sense, which nobody had to articulate explicitly, that making PHP easier to understand was itself a meaningful form of contribution to the wider project. The language was growing fast. The web was growing with it, and the manual was the thing that made it accessible to the developers building on it.
That work gave me a particular kind of knowledge. It is not the knowledge of the engineer who designed the system. It is the knowledge of the person who read every corner of the system's behaviour, tested the examples, found the edge cases, and had to translate what the code actually did into language that someone starting from scratch could follow. Combined with forty years of watching technology change, and watching the things that do not change, it produced a perspective that I have found genuinely useful: an ability to distinguish infrastructure from fashion. To see which technologies are solving real problems and which are producing the same outcome with more dependencies attached.
The community that formed around these tools
The documentation work was one thread. The other was the physical gathering of people who used these tools. In Brisbane, a user group called Humbug had been meeting since the early days of Linux and Unix finding their way onto personal machines and into small organisations. Humbug was not a corporate meetup. It was not a networking event with a sponsor and catered food. It was a room of people who were genuinely interested in open-source software and what it could do, sharing knowledge in the way that communities share knowledge when there is no financial transaction involved and no stage to perform on.
The group evolved as the web evolved. Linux gave rise to the LAMP stack. The LAMP stack brought PHP into the mainstream. PHP gave a generation of developers and consultants the tools to build things for small businesses, local organisations, universities, and anyone else who needed a website or a system before there was a commercial product category for every conceivable need. Humbug tracked this evolution. The meetups moved through subjects as the landscape moved through them. PHP evenings. Development practices. The strange early days of JavaScript frameworks. The tools that were emerging and the ones that were fading.
What I observed over those years was that the open-source web had a generative quality that was difficult to appreciate from the outside. It was not merely that the software was free to use. It was that the knowledge was freely shared, freely argued over, and freely improved. When something was wrong in the PHP manual, someone wrote to say so and the correction was made. When a better way to explain a concept was found, the documentation was updated. There was no product team deciding whether a correction warranted a sprint. There was only the question of whether the correction was right.
That is not how software works today. Today, the product team decides. The roadmap decides. The pricing tier decides. The acquisition decides. The investor returns decide. The infrastructure that powered the early web: PHP, MySQL, Apache, Linux. It was governed by none of those things. It was governed by technical merit and community consensus. The result was infrastructure that has run in production, without interruption, for over two decades.
The web we built in 2005 ran on infrastructure that nobody owned. The web small businesses are paying for today runs on infrastructure that someone else owns entirely.
What we watched happen to the tools
In 2003, WordPress was released. At the time it was a blogging platform, a fork of b2/cafelog, built on the PHP and MySQL stack that the web already ran on. It was not, on its face, a remarkable thing. There were other blogging tools. There were other content management systems. WordPress was cleaner than many of them, and it grew quickly, but it was one entry in a competitive field of tools for publishing content on the web.
What happened over the following twenty years is one of the more extraordinary stories in software. WordPress did not simply survive the successive waves of disruption that took out most of its early competitors. It absorbed them. Every time a category of web software emerged, whether e-commerce, membership sites, multilingual publishing, media delivery, form handling, SEO tools, or event management, WordPress grew to accommodate it through a plugin architecture that had been designed to extend the platform without requiring changes to the core. The platform that 42% of all websites now run on is not the same platform that launched in 2003. But it runs on the same foundation, maintains backward compatibility with a discipline that most modern frameworks would not tolerate, and continues to be governed by the same community structure it started with.
Meanwhile, the market for business tools moved in a different direction entirely. The SaaS model, Software as a Service, emerged as the dominant commercial form for business software. Instead of buying software that ran on your own server, you subscribed to software that ran on someone else's server. The argument for this model was that you did not have to manage the infrastructure, the updates, the backups, the security patches. You paid a monthly fee and someone else handled all of that.
The argument was not wrong in every case. For genuinely complex software that required significant engineering capacity to run, offloading that infrastructure to a specialist provider made sense. The problem was that the model was applied universally, to tools of every complexity level, including tools that had no meaningful infrastructure requirements at all. A contact list. An invoice tracker. A staff roster. A job log. These are not complex systems. They do not require enterprise infrastructure. They require a server, a database, and a login page, all three of which were already sitting inside the WordPress installation that most of those businesses already had.
The SaaS model also carried a dependency that most businesses did not fully examine at the point of adoption. When you subscribe to a tool, you do not own the tool. You own access to the tool, under terms that the vendor controls. The vendor can change the pricing. The vendor can change the features. The vendor can be acquired. The vendor can shut down. In every one of those scenarios, the business that built its operations on the tool bears the cost of adaptation. The vendor does not bear that cost. The vendor has already been paid.
The economics of the subscription stack
There is a particular financial reality that has crept up on small businesses over the past decade without ever arriving as a single visible event. It arrived as a succession of small, individually justifiable decisions. A project management tool here. A CRM there. An invoicing platform. A staff scheduling system. A customer feedback form. An inventory tracker. Each tool solved a real problem at a cost that seemed reasonable. Each tool was faster to adopt than building something custom. Each monthly charge was, in isolation, unremarkable.
Aggregated, the picture changes. The average small business is now paying between A$150 and A$500 per month across tools that each do one job. None of those subscriptions end. The price never goes down. The data stored in each tool is not fully portable. It can usually be exported, but the export is often in a format that requires work to move anywhere useful. The tools do not talk to each other without an additional integration layer, which itself usually requires another subscription. The monthly cost is permanent. The ownership is perpetual in the wrong direction: the vendor owns the data relationship, not the business.
This is not a criticism of any individual tool or company. Most of these products are good. Most of the companies behind them have built genuinely useful software. The problem is structural. The subscription model, applied across an entire stack of business tools, creates a permanent cost that compounds over time and accumulates dependencies that are expensive and disruptive to change. A business that has been using a CRM for three years has three years of customer history in that CRM. Moving it is not trivial. The switching cost grows with use. The tool becomes more embedded the more you rely on it. That is not a bug in the product. It is a feature of the business model.
A$499 once versus A$150 per month is break-even at month four. At month twelve, the subscription has cost A$1,800 for the same functional outcome. At three years, A$5,400 for a tool doing one job that could have been built on infrastructure the business already paid for, under terms the business controls, with data that belongs entirely to them.
This is the conversation that was not available to small businesses before. Not because it was not true, but because nobody had built the apps that made it possible.
The infrastructure that was already there
Every WordPress installation comes with infrastructure that most businesses have never thought to use for anything except their website. There is a PHP server running server-side code. There is a MySQL database with direct SQL access and a schema that can be extended. There is a working authentication system with user roles, permissions, and session management. There is file storage. There is a REST API. There is a plugin system that can load custom code without modifying core files. There is a hook system, actions and filters, that allows custom behaviour to be attached to any point in the platform's execution without touching the code it hooks into.
This is not a limited set of primitives assembled for websites. This is a complete application platform. The authentication system alone, which most custom apps need to build from scratch, is mature, well-documented, battle-tested across hundreds of millions of installs, and already running inside every WordPress site. The database layer includes a query abstraction that sanitises inputs correctly and handles the most common database operations without requiring raw SQL. The file handling system manages uploads, storage paths, and media metadata in a way that has been hardened against the full range of web attacks over two decades of production use.
Applications built on this foundation inherit all of that stability. They do not start from zero. They start from a platform that has already solved the hard problems: the security problems, the performance problems, the compatibility problems, the deployment problems. It has been solving them, continuously and in public, since 2003.
Most of those installs are running on a fraction of their capacity. The servers are running. The databases are provisioned. The authentication systems are active. The infrastructure is there. The applications that should have been built on it just have not been built.
You do not need a new platform. You need someone to build the application on the platform you already have.
Why this gap persisted as long as it did
The gap between what WordPress can do and what it is routinely used for did not persist by accident. There are structural reasons that the platform became identified with websites and not with applications, and understanding them matters if you want to understand why the opportunity still exists.
The first reason is perception. WordPress's origin as a blogging platform shaped how it was understood by the broader market, and that understanding calcified as the platform grew. Developers who entered the industry after 2010 often encountered WordPress primarily as a content management system, something used by marketing teams to publish pages, managed by agencies billing hourly for template customisation. The perception that it was a CMS and not an application platform became self-reinforcing. Developers who wanted to build applications chose frameworks built for applications. They did not consider that the platform their customer's website was already running on was equally capable of running the application the customer also needed.
The second reason is the shape of the development market. Agencies that do WordPress work are, in the main, organised around content sites. The engagement model is a project to build a website, followed by a retainer to maintain it. Building a bespoke business application on the same infrastructure is a different kind of engagement: different in scope, different in the questions asked during discovery, different in how the work is structured and priced. Most agencies have not built that capability because their clients have not, historically, asked for it in terms that made it clearly an extension of existing WordPress work.
The third reason is that the tools and practices for building applications on WordPress, as distinct from building websites, are less well documented and less well understood than the equivalent for purpose-built application frameworks. The knowledge exists. The capability is there. But the patterns, the conventions, the examples, and the guidance that would make it obvious to a developer starting from scratch are thinner than they ought to be. Technical capability that is not well explained remains inaccessible to the people who need it.
None of these reasons is sufficient to justify the gap. A platform running on 42% of the internet, with over two decades of production hardening, is not inaccessible because of documentation gaps. It is underused in a specific way, for a specific kind of work, by a market that was pointed toward alternatives before it had reason to look at what it already had.
What a small business actually needs
There is a mismatch at the centre of the business software market. On one side, you have enterprise software designed to accommodate thousands of users, complex permission hierarchies, multi-region data requirements, and audit trails that satisfy regulatory compliance frameworks. On the other side, you have consumer apps designed for individuals, with pricing and feature sets that reflect individual use rather than business process. In between, you have SaaS tools that attempt to serve the small business segment by offering simplified versions of enterprise software at subscription prices that are positioned as affordable relative to the enterprise alternative.
What a small business actually needs is rarely any of these things. Think about the tools a business of five or ten people genuinely requires to run its operations. A contact list with notes and a history of interactions. An invoice tracker showing what has been sent, what is outstanding, and what has been paid. A job log with status fields that the team updates as work moves through stages. A staff roster with availability and scheduling. A stock count linked to a re-order trigger. A custom dashboard that surfaces the numbers the owner looks at every morning. An intake form that captures client information, stores it somewhere the team can access, and notifies the right person when a new entry arrives.
These are not complex systems. They do not need to scale to a million concurrent users. They do not need a global CDN. They do not need a compliance framework designed for a publicly listed company. They need a server, a database, a login page, and someone who understands the specific business well enough to build a tool that fits it exactly. WordPress is the server. WordPress is the database. WordPress is the login page. The only thing that was missing was the someone who would build the tool.
The consequence of that gap is that small businesses have been paying subscription fees for tools that approximate what they need, rather than owning tools that do exactly what they need. The approximation is costly in two ways. It costs money, the permanent compounding subscription, and it costs fit. A tool built for ten thousand businesses in a category is not built for your business specifically. The fields are labelled with someone else's terminology. The workflow is someone else's workflow. The features you need are behind a higher tier. The features you do not need are in the way.
The vibe coding problem
In the past two years, a new category of tools has emerged that promises to make custom app development accessible without a developer. Platforms that generate applications from natural language descriptions. Tools that scaffold interfaces from prompts. Services that claim to compress the distance between an idea and a working product to a conversation and a few minutes of processing time.
These tools are genuinely interesting. Some of them produce functional results for straightforward use cases. They have made it possible for people without programming backgrounds to prototype ideas in a way that was not accessible before. That is a real contribution to the practice of building software.
The problem is structural, and it is the same structural problem that afflicts every other SaaS product: the resulting application runs on someone else's infrastructure, under terms the vendor controls, with data stored in a system the business does not own. The application may look like yours. It may behave like yours. But it lives on a platform that can change its pricing, change its terms, or stop operating. The moment any of those things happen, the investment in building and operating that application is at risk.
There is also a less-discussed problem, which is that applications generated by vibe coding platforms are largely invisible to search engines. The rendering architecture of most of these platforms produces single-page applications that serve the same empty shell to crawlers as they serve to users before JavaScript executes. Google indexes what it can crawl. It cannot effectively crawl a page that has no content until a script runs. For any application that should be findable, such as a directory, a public tool, or a resource that benefits from organic traffic, building it on a platform with poor crawlability is building it with a permanent handicap that no amount of content quality will overcome.
WordPress has been indexable from its first version. It is server-rendered by default. The content that should be visible to search engines is in the HTML that the server returns. That is not a new development. It is a twenty-year-old property of the platform that has never needed to change.
Going forward without going back to zero
The argument for building on WordPress is sometimes mistaken for nostalgia. It is not. The platform being recommended here is not the platform of 2003 or 2010. It is the platform that hundreds of millions of installs are running in 2026, updated continuously, with a security team, a core team, and a contributor community larger than almost any other open-source project in existence. The argument is not that older is better. The argument is that proven infrastructure that continues to be actively maintained and extended is a better foundation for business-critical software than unproven infrastructure that may or may not still exist in three years.
Every new platform is a tax. You learn it from scratch. You find people who know it, and the pool of experienced practitioners is smaller and shallower the newer the platform is. You trust a company you have never met to keep the service running, to price it fairly, and to make product decisions that remain aligned with your needs over the useful life of the application you have built on it. That trust is rarely fully repaid. Pricing tiers change. Free plans disappear. Features move behind higher tiers. The company pivots, gets acquired, or shuts down. Each time, the business absorbs the cost: the migration effort, the relearning, the data extraction, the lost process continuity, the interrupted operations.
That is not progress. That is repeatedly starting over with different dependencies. The infrastructure that removes all of that has been running reliably since before most of the platforms now selling subscriptions for it were founded. The foundation was already there. It was sitting under a reputation it did not deserve: the reputation of a blogging platform rather than a production application platform. It was waiting for someone to build the applications that belong on it.
The next decade of small business software does not run on new platforms. It runs on infrastructure that is already installed, already paid for, already proven in production, and already owned by the people who need it.
WordPress is not a website builder that also happens to run applications. It is an application platform that also happens to power most of the internet's websites. That distinction matters. The capability has been there for twenty years. The perception has not caught up. The market has been pointed away from the answer while paying someone else for an approximation of it.
Having spent the better part of three decades building on this infrastructure, watching it harden, watching the community around it grow, watching the market repeatedly look past it in favour of something newer, I am not persuaded by the argument that the answer was somewhere new. The answer was here the whole time.
What Merebase is building, and why it is the right thing to build
Merebase builds the applications that should have been running on existing WordPress infrastructure for years. One application, one defined job, built to the exact specification of the business that commissions it. No subscription attached to the application itself. No kill switch. No dependency on Merebase remaining in business. No data stored on our servers. The code is the customer's. The data is the customer's. It runs on infrastructure the customer controls.
The model is intentionally narrow. We are not building a platform. We are not building a marketplace of templates. We are not building a product that needs to work for ten thousand different business configurations. We are building specific applications for specific businesses, on infrastructure those businesses already have, and we are not retaining any ongoing claim on the result. The application runs when we are no longer involved. It runs if we shut down. It runs if the customer changes hosting providers. It runs because it is built on infrastructure that has been running continuously for over twenty years and has no realistic path to switching off.
That specificity is the product. A tool built to fit one business's exact process, labelled with that business's terminology, structured around that business's workflow, is more valuable than a tool built to approximate it. It is also, in most cases, significantly cheaper over any period longer than a few months, because the A$499 one-time cost of the application is the total cost of ownership, not the opening payment in a permanent subscription.
The infrastructure is already there. We are building the applications that belong on it. That is what this company does. That is all it does. And the reason it had not been done before is not that it was too hard. It is that the market spent twenty years looking at the shiny new thing instead of looking down at what was sitting at its feet.
Founder of Merebase. More than 40 years writing code, over 25 in the internet industry. AI has changed what it costs to build custom software. Businesses are done paying for SaaS they do not own. The infrastructure was already there. For the first time, all three are true at once.
LinkedIn