May Hubspot Rest in Peace
I was so grateful when Ed Worthington's team implemented my current website for me. It used content I had already been working on in this press repository, which is currently the "source code" for this website.
This website will also serve as the foundation for my documentation, so I encourage my customers to fork it from time to time. It's all part of how responsibly well-run companies should operate: it's about distribution and resilience.
This website doesn't require a PhD in institutional corporate dysfunction just to figure out how to update a page.
The current system is implemented using PHP, and the source code is available in press-publisher on my GitHub account.
Feel free to fork it and use the code if you’d like to have a website like this.
I'll update the documentation if you have questions or need help getting it set up.
Moving forward, I try to make my systems open for inspection by others and available to my customers, who I know will increasingly face disaster scenarios in which their own infrastructure has been disabled by cyberattacks.
I am making sure you have options to quickly re-establish your own infrastructure, just as I needed to.
Collaboration
Let's say I get to a point where I need someone to edit the site. The beauty is that I can have them fork the repository behind it. They edit it independently, and then I can make sure they've only corrected grammar and haven’t gone and changed my meaning. This is so much better than what used to happen—I would write great documentation that had humor and personality, and my employees would go and turn it into bland, boring corporate nonsense.
Never again!
It Wasn't Just Hubspot
In earlier times, we had simple technology behind the website. Hubspot was an abomination introduced by an employee, and had I known how awful it was, I would have fought more vigorously to say NO—you need to nurture your ability to think and do things from first principles.
My Canadian company had at least five content management systems: various versions of WordPress, legacy code for Chameleon (which was built by an employee as a degraded version of KISSBOOK, a tool I wrote), and we used Confluence from Atlassian, which became more and more awful over time.
I don't apologize for pulling the plug on it all. I am really fast at writing documentation—as long as I am not crippled by poor tools, and this new system is fantastic.
In Memory of Hubspot
I was honestly amazed at how difficult Hubspot was. It felt like a room full of monkeys had gotten together and asked, "How can we make something incredibly simple as complicated as possible?" Then they invited everyone to a hackathon, and somehow this unmaintainable monster emerged.
I really tried to understand it. I spent hours digging through templates, modules, layouts, and files with identical names. But at some point, I had to admit defeat. It was simply too complicated for someone who prefers straightforward systems.
One of my biggest regrets was probably that I paid the marketing team too much severance. Looking at what they left behind, it almost felt like they should have been paying me. But that's life—you learn, you move on, and you build something better.
I managed to improve some of the messaging here and there, but for the life of me, I still couldn't figure out how to change something as simple as the download button. It was astonishing how something so basic could be so difficult to locate and modify.
At that point, it was honestly easier to replace the entire website, point the domain at the new one, and leave all of that complexity behind. Sometimes the fastest way to fix technical debt is not to fight it—it's to walk away and build something simpler.