Don Drury

1. SEO before speed.
2. Speed.
3. Sooner is better than perfect.
4. Our computers do the hard work.
5. Empower developers to submit straight HTML, CSS, and Javascript.
6. Don't let producers, designers, or developers break things by handling all front-end tasks on the server.

I'm Don Drury, and I created Viking CMS. I built a whole enterprise-scale CMS based on a need I saw working as a front-end developer within the largest media conglomerate in Oklahoma. They had spent 20 years trying to work around Frankly CMS, which as far as I can tell is no longer actively adding customers. They had hired a back-end developer, a front-end developer, 4 designers and still weren't able to do the basic things they wanted to do. They had set up a variety of services around their CMS provider to accomplish basic things like banners, featured routes, and outgoing data feeds to serve various third-parties that their CMS wouldn't support. It was mind-bogglingly inefficient. It broke down constantly. The back-end developer would frequently get calls a 2AM because on-air content ("tickers") were being affected by system failures.

It was completely bananas. My demoralized co-workers all told me "nothing will ever change around here", "this is just how it is". The leadership was paying over $500,000 per year to Frankly, while also paying payroll exceeding that to accomplish their business goals. They still weren't getting the outcomes they needed.

One day at the whiteboard an idea occurred to me: What if every page render on the website was from arbitrary data feeds? What if it just talked to itself, the same way it would talk to a third-party vendor?

I'd heard of many content outlets rendering pages themselves from feeds originating in the CMS the paid for. They didn't like the front-end of their CMS provider, so they set up a React or NextJS app that renders the content coming from that CMS. That's silly though, because then you are just doing somebody else's work for them. Why pay for a CMS that you don't even want to render your pages?

The idea fully condensed when I realized that the rendering engine could be part of the same software that managed the content, but still relying only on the data feeds it offered, and any others as needed. We had so many incoming data feeds from other sources, they could be intermingled freely. This meant that a single page like "weather", could have stories coming from internal data feeds, and forecasts coming from external sources, all on the same page template. We had "elections", we had "school closings", many other concepts that combined internal and external data sources.

Within a couple months I had a proof of concept.

Within a year, we migrated thirty years of content, deployed, and changed the DNS to point at my IPs, and I was in business.

That was 7 years ago. We've proved that we can handle the traffic, the sudden spikes of traffic (a BIG deal in Oklahoma during "storm season"), and serve over 2 Million page views per hour.

The best part? It runs faster the more traffic it gets. Read that again please. It runs FASTER, the more traffic you throw at it. It's self-talking. More traffic just primes the pump, and it builds on itself. It is content in motion, it has a momentum all it's own.

I've built generous amounts of features during the last few years and honed and optimized it's capabilities. We've sorted out every security flaw. We've tailored the stack to be shockingly efficient, and experienced a cumulative 12 minutes of downtime in that entire 7 years, and that was human error on my part, not the software! I'm honest when I make mistakes. Integrity is my highest goal. Clarity and transparency are the most important qualities in creating trust. You need a CMS provider you can trust, not just sales pitches and empty promises.

I wanted to include story that because nobody would believe me if I said 100% uptime. Instead I'll say 99.9997% up-time, because that's what it is.