By Merlin Carter
It’s the first quarter of the new year. That means time for renovations, new hairdos, and maybe a company website facelift…or possibly a total rebrand? If you’re a tech startup, this might seem like a trivial task compared to building your actual product. But some tech startups end up spending way too much time and money on their company websites. Why is that? We have a theory, and we’d like to share it with you — so that you can avoid making the same mistake yourself. We’ll get into that in a moment, but first…
What exactly does “company website” mean?
When people talk about “our website”, the term “website” often becomes synonymous with the online store or the web app that their company makes. In some cases, the website and the product are thrown together under the same address, but usually, they’re completely separate entities.
For example, here are some screenshots of company websites from a couple of our portfolio companies.
In both of these examples, the main company website serves to introduce a company’s brand, people, and products. But it is not the product. The products are web and mobile apps, which are accessed through separate user interfaces and require users to sign in first. The company websites, on the other hand, have very little interactive functionality — perhaps just a couple of forms for newsletter subscriptions and contact requests. Visitors don’t need to sign in or update a shopping cart — it’s mostly basic content.
This “basic” content doesn’t change dramatically from company to company. There’s some “About us” content, an overview of the products and services that they provide, a careers section, some contact details, a standard legal blurb, and so on. So why does (re)launching a company website often seem so complicated?
Websites aren’t like software products
Cloud-based products are usually developed in endless iterations. It’s baked into the Agile Scrum methodology, where developers make continuous improvements in two-week intervals. This is fine if you’re building a web or mobile app. But for a company website, it’s not ideal. Still, many startups prefer to use in-house teams to build their websites, which can be a problem because they’ll often manage the website development in the same manner as they would for a SaaS product.
The instinct to build your website in-house is understandable. If you’re a tech startup, you already have the right people to launch a website (unlike a traditional business such as a dental practice or law firm). You have your own designers, frontend developers, product managers, QA, and so on. Plus, the communication overhead is much lower when you can just ping a colleague on Slack or stop by their desk. But the risk is higher that you’ll be working without a clear end in sight.
In fact, the company website is one of those rare cases where a “waterfall” approach is the better option. You should know when the project starts and when it should be completed. Ideally, you have most of your requirements detailed before you start work.
The more you specify upfront, the better you can estimate time and cost. Then you can start thinking about how much you’re really willing to spend.
How much ARE you willing to spend?
It’s hard to figure this out when you don’t know how much things are supposed to cost. For example, you can’t assume that your website is going to cost the same as it would cost to build a basic web app. You might end up with a budget that’s unnecessarily lavish.
If you’re outsourcing the work, it’s easier to get an idea of the price range that you’re comfortable with. Agencies will look at your requirements, match them with projects they’ve done in the past and offer you different bundles. You might discover that an idea for a fancy front-page animation will make up 50% of your budget and adjust your expectations accordingly.
However, if you’re building your website in-house, this process will be more complicated (unless you’re in the business of building websites). This is because it’s harder to determine the “real” cost of development.
The problems with treating your website like a product
If you approach your company website like it’s one of your products, you’ll most likely borrow your product developers. These are typically skilled workers who can build sophisticated front ends that need to integrate with multiple distributed systems. However, these skills come at a premium. Unless you really need those kinds of features, you risk using expensive people to do work that would be cheaper to outsource.
Product developers have different priorities
Your developers will be the ones who recommend a technical strategy for your website infrastructure. But it’s highly likely that they’ll go with a similar tech stack to the one they use for your product. This makes sense — learning an unfamiliar technology takes time: Why learn PHP when you already know Ruby on Rails? However, your standard tech stack might not always be the best fit for a basic website.
For example, most front-end developers (especially those in e-commerce) are highly sensitive to page load speed. They know that a few extra milliseconds have a significant impact on conversions. And with huge volumes of traffic, these differences can mean a lot of lost revenue. So many developers tend to prefer more modern, sophisticated technologies that result in a highly performant website. But your company website probably doesn’t generate any direct revenue, and it might not get a lot of traffic (at least compared to your product). Load time is, therefore, not such a crucial metric, and you have more room to make compromises. Compromises that can save you a lot of money.
You might discover that a low-code or no-code solution is the best option, assuming that you’re willing to compromise on load time and your requirements are simple enough. However, a product developer would be less inclined to consider one of these tools because they rarely use them (they love code..why use something that doesn’t require code?!).
Suppose that one of your product managers eventually suggests WordPress. How many developers do you have that love working with WordPress? Probably zero.
But even for a WordPress-based site, you’ll probably need a developer to set it up and customize it to match your designs. It’s not a major technical obstacle if your developers don’t know WordPress. Any decent developer can figure out WordPress’s templating system in a day or two. This bigger issue is…will they want to?
There are plenty of developers out there who live and breathe WordPress, but you probably won’t find them in a product development team — they usually work as freelancers or for web design agencies. So, if you’re keeping it in-house, you’ll probably end up with something that would be easier for your developers to customize. Which is fine, except…
You’ll probably depend on your developers to make cosmetic changes
Let’s assume that you do choose a similar tech stack to the one that you use for your product — for example, a custom React-based front end coupled with a headless CMS on the back end. That type of solution is going to have a higher maintenance overhead than something like WordPress.
If you want to change the layout of a page, you’ll need a developer to add and deploy the changes. You might also need developers to configure a build job that will automatically deploy your content changes. Of course, if you have complex requirements, maybe you really do need a more custom solution.
One example will be if you want to pull in data from a third-party source from an API, such as a job posting database or a social media feed. Or you have an extremely tight integration between your plain company website and your web app.
But it’s worth considering what this level of customization will cost you long term. Once you weigh the pros and cons, you might realize that boring old WordPress will do the trick after all (or a hybrid headless/low code solution).
Your developers are supposed to be working on your product
Don’t forget, if you use your own developers, you’re also taking resources away from your core business. So to estimate cost, you can’t just divide the engineer’s salary by the number of estimated days. You also have to factor in the opportunity cost. For example, will building your website delay the release of a revenue-driving feature? And will this delay affect your financial forecasts and planning?
Even after you’ve factored in the cost and committed people to the task, they could be pulled away at any moment if there’s a fire to put out with your core product. So your planned completion date is going to be vulnerable to delays.
Your mindset is more important than the “agency or in-house” decision
Sure, going in-house can be risky — but you can still get great results with the right mindset and methodology. Using an agency is not a magic bullet. There’s no guarantee that an agency will be cheaper or recommend a better technical solution. It comes down to being clear about what you want from your website. This is true no matter what industry you’re in — tech startup, dentist, law firm, it doesn’t matter. As any web designer can tell you, customers who don’t know what they want can end up wasting your time and money.
Conversely, it might still be cheaper to use our own developers as long as you approach the task with the right mindset. And what is the right mindset?
Think of your website as a one-off project with a fixed due date
Even if you don’t actually use an agency, approach your website with the mindset of an agency. When a web design agency starts a new project, it will first clarify the scope and the expected delivery date.
They’ll run the project with the mutual assumption that once the website is delivered, the developers who built it will move on to the next customer project and will no longer be at your disposal. The agency will hand the website over, and you’ll usually be expected to run it yourself (unless it’s a very complex website). This means that the whole tech stack will be set up with this fact in mind.
If you use your own teams, you can still build your website with the same project-oriented mindset.
Ask your tech team to consider the maintenance and operational tasks that come with their chosen tech stack and make a plan for who will take these over when they finish the project. In other words, approach it like any other infrastructural project, such as rolling out a new payroll system or upgrading your development tools. At some point, you can consider it “done” and hand it over to the target users of the system. For the website, this will be your content creators.
If you approach your website in this way, you can avoid pitfalls such as unpredictable costs, delays, and conflicts of interest — and you’ll have more time and resources to focus on your actual products.