Back to Blog

Profile: Dave Sparks of Sparks Interactive, on AWS costs, Drupal, and open source

/ Case study
Dave Sparks started Sparks Interactive with his wife in 2005. We spoke with him about taking their web agency in and out of AWS, building an open-source development platform for the public sector, and why he’s a big fan of Drupal.

SiteHost: Thanks for talking with us today, Dave. What's the elevator pitch for Sparks Interactive?

Dave Sparks: We're a full service website design, build and support agency. We've been around a long time and we have a pretty solid practice. When my wife and I set up the business, we wanted to make sure that we had everything in-house - design, build and support. It's really important to us that design and build talk to each other a lot. 

We fly a little bit under the radar. People generally come to us by word of mouth or through traditional ERP procurement, which we’ve done well since our earliest days. It’s still a major source of project work now. 

We just like making websites. That's what we do, and it’s who Sparks Interactive people are.

What makes a good fit between you and your clients?

DS: We focus on large-scale content websites with a broad public audience. Usually we like to work with clients who have a clear business need or some social good in there. We like to deal with people for whom their website is important, but that doesn't necessarily mean that it’s expensive. We never wanted to say, ”You must be this big to work with us.”

Dave on stage at DrupalSouth last month

Instead it’s about how important your website is to you. One line we’ve used is “mission critical websites for the New Zealand public”. If you don't want to spend money on your website and you don't take it seriously, or if you’re not prepared to think deeply about the intersection of your website and your business, then you're probably better off somewhere else.

We can pick and choose our clients but we're not precious about who we work with. Right now we’re looking after around a hundred sites. They break down into about five really big ones, 20 medium size ones, and another 20 or 30 or so in active support. Then a long tail after that, where businesses don’t necessarily have a lot to spend and have to justify a return. There are limitations, but good ideas and good advice aren’t always expensive.

How did Sparks Interactive begin?

DS: In 2005 I did a management buyout of the web department where I worked. It was a mess when I started working there. It was a bit like, “We've got this horrible mess that no one wants to touch. Who should we give this to? Oh look, there's Dave!”

So I inherited a portfolio of about 30 clients who had hosting with five or six different providers. We didn’t start from scratch but from 2005 to 2010 was like a start-up era for us. We grew quite quickly - we doubled in size every year for the first five years. You make a lot of mistakes but you realise that sometimes there’s money that you spend just to learn a lesson. 

Then in 2010 we bought another business in Wellington so we could have boots on the ground there, as they say. And again, we inherited a variety of hosting setups. From 2010 to 2015, we really wanted to lock in a more sustainable growth model. 

We had the opportunity to grow again in 2015 with a substantial new client, and a different strategic direction for us as a business. 

Was that around the time you took your hosting in a new direction as well?

DS: Yes, these were our pre-SiteHost days and we were experiencing a little bit of grief with our preferred hosting supplier. We wanted a more modern, flexible, dynamic workflow and we thought that the cloud's the way to support that scaling in a more manageable way.

Another motivator was seeing friends go through the earthquake in Christchurch, and we’d had an earthquake in Wellington too. Here in Auckland, I think in 2013 or 2014, we had a flood event in our Auckland office. That was very ahead of the curve! A plastic bag got stuck in the gutter of a building on Victoria Street and everyone's office got flooded that weekend. 

We used to have a server rack for our dev instances that sat in the corner of the room, keeping everyone warm, and we got rid of that. I didn't want to have any physical hardware onsite.

Related article: How our data centre performed through Auckland’s extreme weather (2023)

How did you choose your cloud provider?

DS: AWS was the obvious choice at that time. A good colleague of mine who I've known since the mid-90s had one of New Zealand’s first big AWS shops, in Auckland. I think they were the first platinum partners here. So we got ourselves set up on AWS. 

How did AWS work out during that period of growth?

DS: We started out with our dev instances there, because our production was spread around various places and we still had an existing relationship with our New Zealand-based supplier of production hosting. 

AWS did support growth, it did allow us to develop what we did, and it let us change how we did things. AWS is not a completely bad option. But I think within the first six months, the monthly cost tripled without our workload necessarily tripling. That was from a small base, but it showed that there was a cost to that growth. We were working so much harder, doing so much more. So why was the bottom line not joining us on that journey of joy?

What did you do to control your AWS costs?

DS: It gets out of control very quickly, like having a puppy in the house. If you don't watch it 24/7 it’s running around chewing the couch and making a mess in the corner. We had a massive amount of focus and chat within the development team about managing costs. 

I might sound a little bitter but AWS cost reporting is almost deliberately opaque. We set up our own dashboard to look at costs and to give producers and project managers the ability to turn instances on and off. We had around 75-80 dev instances for our various sites. If they're all left running all the time you'd be like, what's that sound? Oh, it’s money burning.

So there's a lot of faff and fuss, just mucking around with it. The more we did, the more that management overhead grew, along with the statement at the end of every month. 

How did your local AWS partner help manage your costs? 

DS: That relationship worked well for us until their business got bought out and moved away. While we were getting frustrated with AWS and cost control, what had been a personal support relationship moved to some people in Australia. They didn't necessarily have any awareness of who we are, or what we did, or why they should care. That was an issue.

After four or five years, I was sick of paying a penalty for growth. We did a lot of looking around for what we could do differently. We didn't want to go back to owning hardware again. 

Related article: Clever companies are leaving the public cloud

What were your priorities when you went looking for a new cloud provider?

DS: For us, service and support are number one. Technology changes, things develop, problems and opportunities will come up. But you can't do anything about that if you can't have a decent conversation with someone who actually understands what you're doing.

Another thread that runs through our business is continuity and stability. When we started Sparks Interactive my wife and I looked at each other and said, what do we want to do differently, based on our experiences? I'd worked in about ten jobs in the 90s. It was chaotic. You’d put a team together for a project and then everyone would go their separate ways. Or you’d get a job with someone cool for six months until they get made redundant or the company closes. We really wanted to build a business that had stability and continuity of support, and that was one of the things we were looking for in a partner.

How has SiteHost measured up to those expectations?

DS: The thing about SiteHost for us is that I like making websites. I do not like hosting. I've never wanted to run a hosting business. It’s not my thing, but I know that it is SiteHost’s thing. 

The proactive support—they think about it so I don't have to think about it. They take the pain away and everyone on the team is happy, and that's never happened before with any external hosting supplier.

When your clients have input into hosting choices, what do they ask about? 

DS: Carbon footprints have been part of the conversation for a long time and now this is becoming an everyday concern. But people's awareness of how much choice and control they have is generally at a low level. Like, we're supposed to be measuring this but what can we do? How do we make these decisions?

Greener hosting: SiteHost's roof sports 384 solar panels

How do these carbon discussions typically go?

DS: For a lot of customers, we’re at a phase now where they say, “Are you doing a good job?” 

And we say, “Yes, I am doing a good job,” and that's it. 

But it’s getting pointier and pointier. We’ve started to see some clients ask for carbon reporting to be included in their contracts. So we have to be able to back up our “yes, I'm doing a good job” with facts and figures. I think that will become a common part of accreditation in the same way that security, for example, has become a baked-in requirement.

Related article: Talking solar power with Canterbury Tech

Do you still have clients who make their own hosting choices?

DS: Whenever we have the choice we go with SiteHost, but we have a lot of clients who BYO hosting. Some of our biggest clients have internal hosting teams or their own hosting preferences. So we're quite flexible in how we work. 

When I started out I thought, I'm going to manage this down to one hosting provider as soon as possible. Almost 20 years later. I still haven't quite managed that! 

How do you use the Private Cloud that you’re running in our data centre? 

DS: We have some instances where we do our development work, and then we have Cloud Containers for each of the production sites we have on SiteHost.

The CMS technology that we work with, Drupal, has some preferences in terms of how everything is managed from dev through to production. A lot of the solution architecture and development happens in the database and configuration rather than code. And so moving the database around had always been a problem with Drupal.

Does all your development happen in Drupal?

DS: I'd like to say yes. But clients will come to us with sites that they want us to look after. So we have a smattering of WordPress, and we might babysit a Kentico or Umbraco site until it gets redeveloped.

But all of our new development, moving forward, is a single code base in Drupal.

How long have you been all in on Drupal?

DS: We did our first Drupal site in 2007. It’s been a long time.

What attracted you to Drupal back then?

DS: In 1997 I worked on what I think was one of the first content managed sites in New Zealand, It wasn't called content management in those days, we called it a database-driven website. Then I worked at Web Media for a while and they built their own CMS. I watched very good people, people who I think are some of the best in the industry in New Zealand, and I saw the huge effort involved in building and maintaining a CMS. I decided that when we run our own business, we're never going to build our own CMS. We'll use something else.

But by 2006, we were perilously close to having to build our own CMS! I had a look around at what was out there at the time, and it was more development frameworks than CMS. 

I’d been introduced to someone to do some troubleshooting on a large website that we were looking after, and he was into Drupal. He recommended Drupal for a redevelopment project, and it was great. We delivered that project very quickly, in six months, under budget, which was really good. We realised that, okay, this works. At that stage, looking back, the benefit of being part of an open source community was just starting to become apparent. You don't have to do everything yourself because there’s a process for sharing and collaboration, and people are very welcoming. 

What’s your favourite thing about Drupal today?

DS: I love Drupal. The architecture is extremely powerful. It’s based around content that’s defined by its metadata and can be surfaced by metadata criteria. No other CMS that I have seen does that so elegantly or in such a mature way, and also in a way that's accessible to non-developers through the Admin console. 

Websites are content. Their job is to bring content to audiences. So Drupal’s dynamic of taxonomy and views that deliver content to people based on criteria is just a golden equation for us.

I’ve just come back from our Australia New Zealand Drupal conference, DrupalSouth, which was in Sydney this year. We were fortunate to have Dries Buytaert, the founder and tech lead for the Drupal Project, and Tim Doyle, the Drupal Association CEO, come over from the US to attend. They were very positive about the scale, success and direction of Drupal and emphasised that the longevity and maturity of the product is a huge asset for something that drives so many really important websites globally. 

DrupalSouth 2024 (Photo: Feb Dao)

How popular is Drupal in New Zealand?

DS: There are a handful of agencies that do some Drupal in New Zealand. We do a lot of business in Wellington and for a long period of time from 2012 to perhaps 2022, Silverstripe was the preferred platform for government.

Drupal lost market share to Silverstripe. There was no getting around that fact. We looked at working with Silverstripe but decided not to maintain a huge dev team with two different flavours of PHP-based CMS. There were other business reasons not to jump to Silverstripe, too. It looked like a lot of people all trying to squeeze through the same gate

So we doubled down on Drupal.

What did doubling down on Drupal look like in practice?

DS: We participated in the all-of-government bid for the Common Web Platform in 2012. We went fairly far down that process, but ultimately we lost out to Silverstripe. 

But we stayed the course and we kept developing the product that we had pitched against Silverstripe. It went through a few iterations and we used it for a big project from 2015 to 2018, for a number of sites that we developed for Treasury. It was a very stop-start project and just before Christmas one year, they needed to stop for three months. That was okay, but what was I going to do with my team?

That was when we took our code base, tidied it up, and published it as an open source distribution for other people to use. It’s called Sector, because it's designed for the public sector in New Zealand, and it’s still going strong. Our competitors use it. We're onto our fourth major release. 

Sector was a winner at the NZ Open Source Awards in 2018

This has allowed us to reinvest in open source. You publish, put yourself out there in public, and see what people think. You listen to the criticism, the inputs and contributions, and then do better. I'm a big believer in the marketplace and that's why I like open source, and the free exchange of ideas. The best ideas survive and the weak perish. 

Sparks Interactive is doing much more than surviving! Thanks for your time today.