Every website is built out of choices that outlive the people who made them. Some of those choices still work fifteen years later. Others stopped working the day a company somewhere decided to stop shipping a product.
I have run an independent practice in Santa Fe since 2001, and the portfolio on this site covers 2009 through 2026, 159 projects. That portfolio is not a complete record. It is the work that seemed worth showing, drawn from a great many more projects than that, and not every early one was a winner. Take what follows as a pattern I have watched repeat rather than as a dataset, since a sample chosen for quality flatters the choices inside it.
The run is long enough to watch the same decisions play out twice, sometimes three times. What follows is not a history of WordPress. It is what my own record says about which technical choices held up, which ones locked people in, and how you can tell the difference while a proposal is still sitting on your desk unsigned.
The choices below were all correct when they were made
A homepage slider in 2011 was not a mistake. It was what clients asked for, what the industry recommended, and what every competitor’s site already had. Bootstrap in 2013 solved a real problem, responsive layout across a dozen screen sizes, at a moment when CSS offered no native answer. A preprocessor in 2015 gave you variables and nesting that plain CSS would not deliver for another five years.
None of this is a list of things I wish I had done differently. Reasonable decisions have different half-lives, and the length of the half-life is usually predictable at the moment you make the choice. That is the part worth knowing before you sign anything.
What lasted
Three technology markers recur through the portfolio and are still correct in 2026:
- Custom fields, on 22 projects. Structured data attached to a page or post, stored in WordPress’s own tables.
- Custom post types, on 10. A content type of your own that WordPress treats exactly the way it treats a post.
- Custom taxonomies, on 5. Your own way of grouping and filtering that content.
These are WordPress’s own content-modeling tools. Nothing about them is fashionable, which is close to the point. A staff directory built in 2013 with a custom post type and a handful of custom fields still runs today. More usefully, it still exports. The content sits in the database in a shape WordPress understands natively, so when the site gets redesigned, the entries move to the new theme and the client keeps thirteen years of work.
Where that line falls between building a content type yourself and buying a plugin that does it got its own post: custom post types vs. plugins. The plugin is often the right answer, and the question worth asking is what happens to your content if it goes away.
What did not last
The other column is longer, and more instructive.
- Bootstrap framework, 31 projects. A third-party CSS framework the whole layout leaned on. When it moved to version 4, class names changed, and updating meant rewriting markup across every template.
- Javascript slider, 27 projects. The homepage carousel, in its various forms.
- Image gallery, 21. Usually a plugin, and usually one that eventually stopped being maintained.
- SCSS on 10 projects and SASS on 9. Preprocessors that supplied variables and nesting before CSS had either. Native CSS custom properties now do most of that work without a build step.
- Video background 5, parallax 3, fixed navigation 3, lightbox 3. Trend features. Each was a reasonable flourish at the time and each now reads as a date stamp.
- Pre-press, 15 projects. Not a website choice at all, but it belongs here: an entire production discipline that shrank as budgets moved online.
- Flash slider, 2. Adobe ended Flash support at the end of 2020, and the browsers dropped the player with it.
- Expression Engine, 1. A commercial CMS that was a credible WordPress competitor in 2011. It still exists, but hiring someone in New Mexico to work on it now is its own small project.
Sliders already have a post of their own, written from load-time and click-through evidence rather than taste: why homepage sliders rarely work.
The pattern underneath both columns
Line the two lists up and the split has nothing to do with how old a choice is. It has to do with what the choice depends on.
Everything in the first column is native to WordPress’s own data model. Custom fields, post types and taxonomies are part of the platform itself. For them to stop working, WordPress would have to stop working.
Everything in the second column needed somebody else to stay interested. Bootstrap needed a team at Twitter, and later an independent core team, to keep shipping compatible versions. A slider plugin needed its author to keep testing against new PHP releases. Flash needed Adobe. Expression Engine needed a market of developers who eventually went elsewhere.
A choice tied to the platform’s own capabilities ages at the speed of the platform. A choice tied to a product ages at the speed of the company behind it, and companies lose interest much faster than platforms do. That distinction accounts for nearly every entry in both columns.
I am the WordPress developer making this argument, so it is fair to say where I started. I built in Drupal and in Joomla for years before I settled. Both are serious systems with real users and I am not running either one down. I worked in three platforms, and WordPress is where I hung my hat. That was a bet on platform durability too, made slowly.
How can I tell whether a website proposal is building something that will last?
Read the proposal for dependencies and ask one question about each: does this depend on WordPress’s own capabilities, or on a company staying interested in a product? Proper nouns are the tell. When a proposal says “custom post types and custom fields for your staff directory,” the dependency is WordPress. When it names a specific plugin instead, the dependency is whoever owns that plugin, and you have a fair question about what becomes of those entries if it stops being updated.
Four questions to put to any developer, none of which require you to understand the technology:
- If this plugin stops being maintained, where does my content actually live, and can I get it out?
- Which parts of this build are WordPress core features and which are third party?
- When we redesign in six years, what carries over and what gets rebuilt from scratch?
- How many separate companies have to stay in business for this site to keep working?
Listen for fluency more than for the answer itself. A developer who has moved a site off a dead plugin will describe it in specifics, an export, a field map, a script, a day of cleanup afterward. A developer who has not will tell you the plugin is very popular. Popularity is a real signal, and it is not the same as an exit.
A developer worth hiring will answer plainly, and will say when a third-party dependency is worth taking on anyway.
When depending on somebody else is still the right call
Nobody builds a payment system from scratch to avoid depending on a vendor. The rule I apply on my own projects is a split between content and service. Anything that holds your content goes into WordPress’s native structures, because that content is yours and has to outlive every tool that touches it. Anything that performs a service, taking payment, sending mail, mapping an address, can be a third party, because a service is replaceable in an afternoon and the years of case studies in your archive are not.
A dependency you take on deliberately, with a rough idea of what the exit looks like, is ordinary engineering. The expensive kind is the one nobody wrote down. You find it in year six, holding the product catalog together, built by an author who stopped answering email years ago.
What this means for a site you commission this year
The durable column has an obvious problem as a sales pitch: none of it is exciting. Custom fields do not demo well. A properly modeled content type looks, from the outside, like a page. The features that photograph beautifully in a proposal deck are disproportionately the ones with short half-lives.
Sites built on the platform’s own structures get redesigned. Sites built on somebody else’s product get rebuilt.
Patrick Iverson is a brand strategist and custom WordPress developer in Santa Fe, New Mexico, working with businesses in Albuquerque, Santa Fe and across the state since 2001. If you have a proposal in front of you and want a second read on which parts of it will still be true in ten years, get in touch.
