You build a product, a web or a mobile app and then you need to build a web site to promote it, a.k.a.: the web site. There are several ways of building and maintaining this web site and I have tried most of them and today I have strong opinions about how to do it.
One alternative is to build a custom website as a bunch of HTML and CSS produced by a graphics designer and a coder. Maybe with some server side functionality. If you are building a web app, you might be tempted to mix the web presence with the web app. A lot of tech startups go this route because they have the talent and because it’s the only way to achieve the pristine look that everybody wants and that the industry giants, such as Apple, have.
This is a mistake. The mistake is not considering the process of the evolution of this web site. We only think of the initial task of building it and that tends to be easily achievable, but after that is when the problems really start. Marketing and sales will want constant modifications to that web site both in terms of content and look and feel. They’ll want new landing pages, different kind of analytics. Sometimes they’ll want to scrap the whole thing and start over. This is part of their job and you should just let them do it.
The problem of having the developers of the startup also develop the website is that they need to maintain it and if your marketing/sales people are active enough, they can easily generate enough modifications for a full time person. But your developer needs to be working on the product, not the website. Most changes requested by marketing are going to be relatively small and not as important as improving the product, which means your web presence will be neglected and your marketing person will get annoyed.
The answer is to have CMS and give write access to market and sales. Whether the CMS is WordPress or SquareSpace or something else, it doesn’t matter. I would even recommend to not host it yourself so that the marketing/sales department have a support department that can help them with issues that is not your development team.
This approach will not look as clean, it might feel a bit clunky and people inside and outside the organization are going to constantly fight it. If this is your choice, you’ll have a tough time defending it. I found myself repeating the contents of this blog post to many people over and over again and this is why I’m writing it.
