James Sansbury
Can you imagine a home builder building a house, but being forced to use the would-be home owner’s tools? I can picture the builder up in the rafters with that cute little Ikea hammer, trying to pound in a sixteen-penny nail. 20 minutes later, they proudly grin and flip you a thumb’s up.
It’s a funny mental image, but for web development agencies, that’s what our work feels like. The designers and strategists work with our clients to come up with that dream home for their digital presence, and then the development team rolls in to find that they can’t use the tools they know.
The wails echo through Slack, “the client is hosting this at HostMost?!”
Note: I don’t know if there really is a hosting provider called HostMost. I just made it up, and frankly I’m terrified to search if it exists. If there really is a HostMost, I’m so sorry for dragging your good name through the mud in the paragraphs that follow.
Now, continuing with our fictional HostMost hosting provider, here’s the deal: it’s not that they are such a bad hosting provider. They do their best to make the development process easier. They’ve got some documentation, and some tooling, and some helper scripts. And their support folks even seem to know what SSH is! 😅
The real problem with the client being on HostMost is that your team isn’t familiar with it.
For web development agencies, every client seems to have a different hosting provider, and each provider comes with it’s own unique set of challenges and gotchas. For an agency that’s trying to streamline their processes, hone their craft, and ensure great quality while keeping their costs low, the huge risk this poses cannot be overstated.
How can you expect your team to accurately estimate when there are so many unknowns? How can you know you’ll be able to deliver work on time if you don’t even know if there’s a staging server yet? How can your team become more productive if every project feels like starting all over again?
For a lot of web development agencies, the answer seems simple: try to convince the client to host with HostBestinstead. It’s what your team knows. You’ve been honing your process there, you’ve got all the right scripts, the checklists, the known issues—everything you need. You’re even willing to go with [gasp] a fixed bid and guarantee the client, “if we can move the site over to HostBest, we can absolutely make your dream home and stay on time and on budget.”
I’m going to say something perhaps a bit scandalous.
This isn’t to say that you can’t help them make the best decision for their company on where they host. You probably know the various options better than them and if they’re in the market for a new host, you can absolutely make some recommendations. But here’s the distinction I’m trying to make: they need the best hosting provider for their business, which isn’t the same thing as the best hosting provider for your business.
You need a hosting provider that has great tooling and is rock solid. They need a hosting provider that is under a certain budget, has certain security certifications, is hosted in a certain data center, or (worst case scenario) is sold by a certain smiling, mustached, golfing pal. (Not that there’s anything wrong with smiles, mustaches, or golf. I personally happen to like two of those three. They just aren’t often great heuristics for deciding where to host.)
“James,” you protest, “if I can’t control where my clients host, you’re asking my team to pick up that Ikea hammer again…”
Not at all. What I’m suggesting is that you hone and standardize on a process that works with any host. You need an agile process backed by consistent CI/CD and tooling that works with your team no matter where your clients host.
So do the work of creating what you and your team need to do the job. You should be in control of the tools you use.
Docker, docker, docker. You may be tired of hearing it, but the beauty of containerization is that you can replicate super sophisticated topologies (I love saying this word because it makes me feel smart) all from text files in code, and then everyone on the team is using the same stack.
In fact, your development team is probably already using tools like Docker Compose, Vagrant, Lando, et. al. to be able to get started faster, hone their craft, and switch between different client projects with ease.
So why are we webdev agencies only making use of Docker on our local development environments, but not alsousing Docker to ship every commit that gets pushed? Docker can replicate infrastructure, so why not use it to replicate the infrastructure that your client is hosting on, and then use it to build every pull request? Use it to demo every step of the way. Ship every commit, test every branch, cross those T’s, dot those I’s.
Docker is complicated stuff, I get it. Wiring together the tools necessary to automatically create real working websites with fresh databases and the like is a huge undertaking. (We know because we’ve spent the last 8 years making Tugboat better and better at that very thing.) But trust me, the work you invest into this will empower you to ship better code, faster, making your agency more profitable, and most importantly, you’ll even sleep better at night, knowing everything has been tested every step of the way.
Don’t worry, you don’t need to do this alone, and you don’t need to hire a DevOps engineer to do it for you. We’ve got a great community over on Slack of folks working on solving this very problem using Tugboat. Tugboat itself is built by a webdev agency that knows firsthand the risks posed by the unknown hosting provider. We want Tugboat to get you back to kicking ass and having fun, not dealing with the all-nighters and nail-biters that come with using someone else’s tools.
Want to learn more about how your agency can mitigate the risk of the unknown hosting provider with Tugboat? Get in touch. ☺️
Tell us about your project, schedule a demo, or consult with a Tugboat Technical Account Executive.
