Ecommerce development has come full circle.

I built my first ecommerce site before the word "ecommerce" existed.

It was 1995, and it was a side project. I had a day job at Insight, a fast-growing computer reseller in Tempe, my first job out of college, and I was writing the site at night in HTML, one page at a time. It launched in 1996. When we needed something bigger, I hired developers and we built our second site in ASP with a SQL Server database. Later we replaced that with a custom Java stack that powered allegromedical.com for years.

Everything was written from scratch because there was nothing to buy. If you wanted an online store and you weren't ready to write IBM a very large check for Net.Commerce, which later became WebSphere Commerce, you learned to code or hired someone who could. WordPress didn't exist. Shopify didn't exist. WooCommerce, Magento, BigCommerce, Squarespace, Webflow: none of them existed yet.

Thirty years later, we're back to hand-coded work, and it's a much better place to be than it was in 1996.

WordPress launched in 2003 as a blogging tool. Over the next several years it grew into a general-purpose content management system, and by the late 2000s it was powering a meaningful share of the web.

Then came the page builders. WPBakery, originally sold as Visual Composer, shipped in 2011. Avada arrived in 2012 and went on to become the best-selling WordPress theme in ThemeForest's history, putting its Fusion Builder on more than a million sites. Divi and Themify Builder both shipped in 2013, Beaver Builder in 2014. Elementor launched in 2016 and reset the ceiling on what a visual builder could do, giving designers close to full control of layout without touching code.

For the first time, a business owner could build a professional website without hiring a developer. That was a real breakthrough. The tradeoff, which nobody talked about at the time, was that every site was now sitting on top of a stack of dependencies that no single person fully controlled.

Developers wanted more than pages. They wanted applications: directories, marketplaces, booking systems, membership sites, custom catalogs. Advanced Custom Fields arrived in 2011 and made it possible to attach real data to a page. Toolset, from the team that built WPML, shipped the same year and let developers create custom post types, relationships between them, and templates that displayed them. JetEngine, from Crocoblock, later brought the same capability into the Elementor world.

WordPress could now do almost anything. But doing almost anything meant stacking Elementor plus a page-builder addon plus JetEngine plus custom post-type tools plus WooCommerce plus twenty more plugins to fill the gaps. Every plugin was a potential incompatibility, a security surface, and a moving target on update day.

Every commerce site I audited during those years had at least one ticking time bomb inside it. Usually there were more.

Then, in about the last twelve months, something changed the math again.

Dedicated AI coding tools like Claude Code, and platforms like Cursor that put those tools directly inside a developer's editor, have collapsed the effort required to write custom code. A developer working with these tools can produce in a day what used to take a week. In some cases, it takes an afternoon.

That efficiency turns a decision that used to be obvious the other way. For fifteen years, most businesses chose WordPress plus a page builder plus plugins because it was cheaper and faster than custom code. That is no longer true for many projects. Custom code, built from a well-organized template a good developer has used before, is now competitive on cost and faster on delivery than the plugin-stacking approach.

I have personally shipped more than a half-dozen headless sites in the last year using this approach. Some have no CMS behind them at all. Others use a very lightweight one. All of them load faster, cost less to maintain, and give the business owner something they never had with a WordPress stack: a codebase they actually own and understand.

The reason the Java-based allegromedical.com always outperformed the Shopify, Magento, and BigCommerce stores in its category was simple. Every part of the site did exactly what we needed it to do. Nothing was carrying weight it didn't need to carry. Nothing broke on Tuesday because a plugin author pushed an update on Monday.

That advantage is now available to any business willing to work with a developer who codes rather than assembles. And with AI-assisted tools shortening the timeline, it's available at a price point that would have been unthinkable five years ago.

What you get from a custom-coded site that you cannot get from a plugin-stacked platform:

• Performance. No bloated theme, no page-builder markup, no plugin JavaScript you never asked for. Custom Next.js sites routinely load in under a second.
• Security. No plugin surface to defend. No admin login page for every bot on the internet to attack.
• Stability. No forced updates that break a page-builder addon that breaks a theme framework that breaks a payment gateway.
• Ownership. Your codebase is yours. A future developer can read it. Nothing depends on the ongoing support of a plugin vendor who might disappear next year.
• Flexibility. Anything you can describe, a developer with AI-assisted tools can build. No more "there's no plugin for that" conversations.

Custom isn't always the answer. If your entire business is a small local storefront and you need a five-page site with a contact form, WordPress or Squarespace is fine. If you want the whole point of your setup to be that a non-technical team member can log in and change copy every day, a good CMS is worth its overhead.

But once your site starts driving real revenue, or your business model needs the site to do something the off-the-shelf tools don't do well, the balance tips, and the point at which it tips has moved a lot in the last twelve months.