Claiming the Name
Avoiding distractions 💬 – a simple setup to rapidly get up a basic pre-launch page for UnscrewMe ⏱ without management overhead 👨🏻💻 or complex configuration ⚙️.
Having chosen a name and secured a domain name, we wanted to fill the new space with a placeholder to announce the idea. We did not want to spend too much time on this, but we felt that every new service or product today needs a little pre-launch or teaser page, so we created one.
Streamlining deployment
If you ever built a website, you probably know that before you can get something online, you need to make up your mind about how to get it online and how you are going to update it. Our main goal was to get a simple page online quickly, without any hassle. To begin with, a static website would really be everything we need – so no server-side logic required, just plain old HTML and CSS, with a tiny bit of JavaScript.
The only thing we were concerned about was deployment. Being spoilt by the easy-to-use Platform as a Service (PaaS) solution AWS Elastic Beanstalk and having selected GitLab as our main documentation and code management tool, we wanted go be able to get the page online and update it with a simple git commit (okay, we would also accept a git push).
We briefly considered AWS S3, maybe even in combination with AWS Lambda and other tools as outlined in ‘Using GitlabCI to build and deploy your Jekyll Site to Amazon S3' or the rather more complex recipe ‘Git-backed static website powered entirely by AWS’, but there was a far more convenient and quick option available right within GitLab: GitLab Pages. It supports more complex static site generators than we needed and can easily serve a basic website with some CSS, JS and a few images.
What made this option so appealing to us was the seamless integration with Git and GitLab CI. Thanks to the generous free plan of GitLab.com, we could probably do more than 1,000 deploys per month – that should be about enough to get a basic website up. And unless we generate an unduly amount of web traffic, static page hosting should be included in the free plan.
Build in Git(Lab), track in Git(Lab), deploy in Git(Lab).
The combination of Git and GitLab CI allows automated deployments with a simple git push to the Git repository hosted on GitLab.com. No need to set up FTP or SFTP or any other ancient tooling that we wanted to avoid. Instead: Build in Git(Lab), track in Git(Lab), deploy in Git(Lab). All we needed to do to get started was activating the GitLab pages feature, creating a .gitlab-ci.yml and pointing our domain to the IP of a GitLab server. A basic configuration without using any advanced static page generators is very simple, we copied the example from the excellent documentation and adapted it slightly.
Gathering metrics
After having sorted out the foundations, we wanted to be able to see if anyone would visit this little placeholder page. While we would have liked to use the open source tool Piwik, we did not want to host it ourselves or pay for the hosting at this stage, so we just went with Google Analytics.
We already had an account anyway, and just needed to add another site to the account, copy the tracking code into the HTML, git commit && git push and our pre-launch page had usage statistics and reports.
Collecting contacts
Of course, if you read any startup guides and blog posts in recent years like for example ‘Running Lean’ by Ash Maurya, you know that building up a mailing list is essential to gauge interest and helpful to enable growth at the beginning. – To be honest, we were not too concerned about any of this. After all, we want to build the service for ourselves, it does not depend on having any users or not. But we still want to be able to collect email addresses of people who like the idea, just in case someone might be interested. And because it indeed does make sense to build up a list of potential users we can reach out to when the first release will go online.
Having established that we wanted a mailing list, the next step was to find a free mailing list tool. Again, we considered a few options, including automation via AWS Lambda and AWS DynamoDB – however, since we wanted to avoid more complex, server-side logic at this stage and focus our efforts on the main product and code, a ready-to-use solution seemed more appropriate. In the end, we went with MailChimp.
MailChimp is mature and offers simple signup forms to collect addresses, while mail shots to up to 2,000 people are free. If we would get more addresses than that, we could either download the addresses and find another mail system, or simply pay MailChimp for the service. This looked like a fair offering, so we went with it.
Improving step by step
Admittedly, our pre-launch page was and is not the most impressive piece of web design out there. When we started to tell more people about the project, we thought we should refine it slightly and gradually improve the pre-launch page bit by bit.
A rather obvious blunder was that we started with a background image of the beautiful city of Stockholm that we had taken during a city break one or two years ago. That was for the simple reason, that we like to use a photo that combined wine and a view of a city, and we had no such picture for London available – we wanted to use own photos as much as possible. When I showed the initial pre-launch page to one of my colleagues, he immediately spotted that this wasn’t London and, slightly embarrassingly, even offered me to pay for a stock photo of London.
A few weeks later when we finally came around to make some tweaks to the pre-launch page, we also wanted to change the background image. We then decided to do away with the idea of combining a wine glass and the city and just go for a nice, panoramic view of London as background – which, due to the wide landscape format, we could also use on social media profiles as header and cover.
Right from the beginning, we intended to have a sleek mailing list signup process, ideally without a page reload. We looked up several code fragments and thought about implementing the feature, yet we have not added this improved process by now. Maybe the reason is that we are not too concerned about collecting fewer email addresses with a less convenient signup procedure at the moment. Once the service goes live, we might well add a state-of-the-art, low-friction signup process.
After we had published my first article on Medium, we also wanted to utilise the pre-launch page to connect to the story behind the project. So we added a link to the Medium page at the bottom, together with other social media links.
While the pre-launch page surely is still far from being the prettiest and coolest page on the web, it should serve its purpose: tell people about what we are working on and when we are planning to replace the announcement with an actual service.
Instead of spending hours and hours on the basic setup and building the perfect pre-launch page, we rather want to get the Minimum Viable Product out quickly.
After this somewhat technical write-up, we will focus on a more general aspect in the next article. Juggling a somewhat ambitious side project with a full-time job and a life can be challenging. While we made far slower progress than we wanted to, we kept going – and we will give some insight into our strategies and tactics to maintain motivation and push ahead.
(Between seeing good friends over plenty of glasses of Fellbacher wine back home in Germany, I’ve been using the few days off for some more coffee-driven writing. So I brainstormed, drafted and edited this article at The Perfectionists’ Café at London Heathrow Queen’s Terminal, at the really nice Mókuska Caffè in Stuttgart and at the quiet and relaxed Misch Misch, also in Stuttgart. In my travel state of mind, I did some final research, then wrote the title and summary on the Eurostar from Paris back to London.)
