Day 17

We're building a startup in 80 days in public. Day 17 was on Feb 1 '22. You can find today's entry at Day 67.

Today's posts:

Recap week #3

In the second week we started with some technical prototypes, because as we wrote about in We always build the hard part first, we need to get a good sense of what’s possible. Having experimented a bit with some components of the editor, we think the core vision we have for the app we’re building is going to work (at least technically speaking).

At the same time we’ve been working on more design mockups for the app, to get a better idea of what it could all look like and how the parts might fit together.

In the coming weeks we’re going to build the actual MVP, a first version of the app. It won’t have all the features we could think of yet, but it’s important that it sparks joy, so we can validate we’re on the right track and hopefully get some initial fans of the product.

Some of the work we did on the prototypes we can recycle, other parts might need some rework, but that’s part of the process. We wrote about this some more in We build one to throw away.

While building an MVP, we also want to make sure we have a landing page up. The goal of the landing page is to tell people what we are building and generate interest. That way we can already start collecting feedback and build a list of people who want to try the app, and we don’t launch to 0 people when it’s ready. While working on the first drafts we also wrote about some Landing page do’s and don’ts.

We’ve also written a few more articles on our blog, such as Where are all the software startups, Everything is Power Law and posts about parts of our stack: Our CALM server stack and Setting up a basic git server. As always you can find a list of all our posts here.

As we wrote in our weekly stats, we’re also happy we continue to sign up more people for the newsletter (thanks everyone!), got a lot more visitors to the blog (especially after the HN traffic spike thanks to the previous week’s You don’t need the cloud) and are (very) slowly working on building an audience on Twitter.

What’s next

All in all a productive week, but time does really fly so we have a lot more to do! Up next is doing a lot more coding work on the editor, launching the landing page and doing some initial marketing around that.

Thanks for following our story! You can see our daily updates on Twitter (@wcools and @jdvhouten). Or drop us a line at [email protected] for any reason. We’re always excited to hear from people πŸ™‚

Setting up a very basic git server

Just yesterday gitlab was down. Github has network issues on a pretty regular basis. Imagine not being able to push an update to your product because some 3rd party service is down. No thanks! We’ll set up our own git server. Shouldn’t be difficult.

Our general philosophy is to do as much as possible ourselves, for 3 mains reasons. One, we learn a bunch and this will help us troubleshoot when something goes wrong down the road. Two, we enjoy not being dependent on 3rd parties. Three, having your own stuff that never breaks with APIs that never change makes life way better. Yes, sometimes we reinvent the wheel, but that’s alright.

We’re two people and we build small scale apps (couple million users max). This means we don’t need much in terms of infrastructure. We don’t need even 5% of the functionality github has to offer. When we have specific needs we can often duck-tape a handful of Linux command line utilities together. In that spirit we’re setting up our own git server.

Goals: (a) create new repositories easily. (b) push/pull from VSCode. (c) push/pull to release server. (d) email hook on push.

I’m just going to follow the guide on I’ll create a user called ‘git’ on our server, and set up public key authentication, with blockers for port forwarding. We have a whitelist for ssh logins, so I’m also updating AllowUsers in /etc/ssh/sshd_config. With chsh I’m removing shell access for the git user as well.

If you lock everything down as aggressively as possible then you’re never one configuration file typo away from disaster. We have a firewall that whitelists IPs, a secondary firewall on a switch in the data center, we block users in sshd, disallow password authentication, we disable shells, we use fail2ban to ban/alert on suspicious activity, all sorts of monitoring and we probably have additional security measures I can’t think of right now. We’re big believers in this kind of layered security and I’m sure it will be the subject of future posts.

Now I’m going to deviate a little bit from the git-scm instructions. One, I want to rename the main branch to ‘main’. We can do that with git symbolic-ref HEAD refs/heads/main. Future versions of git will make renaming the main branch easier, but this works.

I’ll also add a simple ‘post-receive’ hook so when any commits are pushed to the git server it’s posted to our wiki and we’ll get a nice email about it.

Basic bash script gets the job done. This is not a robust script that is intended to stand the test of time. We think of it as a type of interactive documentation. When we want to create a new git repository a year or two from now and we forget the steps we can just read the script, ask ourselves if it still looks reasonable and then run it.

It’s a good habit to sanity check your inputs, even on throwaway scripts. It’s easy to shoot yourself in the foot with bash shell expansion, after all.


# usage: ./make-repo myrepo
# for git commands see

set -euo pipefail

if [[ "$1" =~ [^a-zA-Z0-9_-] ]]; then
        echo "use alphanum git repo name '$1' (exit)"

sudo -u git mkdir /home/git/$1.git
cd /home/git/$1.git
sudo -u git git config --global init.defaultBranch main
# only repo, not also a checkout
sudo -u git git init --bare
# debian git doesn't have rename head yet
sudo -u git git symbolic-ref HEAD refs/heads/main
# papyrs wiki hook
sudo -u git ln -s /home/utils/ hooks/post-receive

Now it’s just a matter of adding the remote to my local git repository and we’re off to the races:

git remote add origin ssh://80daysgit:testproj

And I’ll add an entry to my ~/.ssh/config:

Host 80daysgit
  HostName [redacted]
  User git
  ForwardAgent yes
  IdentityFile ~/.ssh/80daysgit_id_rsa

That’s it. The remote shows up in VSCode automatically and I can push/pull with a click of a button.

State of the Startup (20%)

Yesterday was day 16, which means that we’re at 20% of our our 80 day journey. Time flies. We’ve made some good progress, but building traffic takes a lot of effort and patience. Let’s get to the stats, and I’ll then add some observations.

The stats

Traffic for the blog is at about 150 visitors/day, up from 50/day at the last update. We had a big spike in traffic on the 24th when one of our blog posts hit hackernews. This was probably the blogpost I spent the least time on. I wrote it in a hurry and didn’t make my case very carefully. No predicting which post gets popular out of nowhere, sometimes this is just how it works out. Still, part of me wishes one of my better posts got all the traffic. Oh, well.

On twitter our following count is ticking up, slowly but steadily. Wim is at 85 (was 38),Β Diederik at 91 (was 19). I also discovered that on you can see some charts.

We’ve written 38 blogposts in total now (up from 20). Blogging still takes an immense amount of time, although I’m already getting a bit faster. It will take a long time for us to get actually good at writing, but we have we have some good insights to share. I think that there are many people interested in what we have to say, it’s just that practically nobody knows this blog and our 80daystartup project exist. Our goal is still to write the blog we wanted to read when we started doing software startups.

Our mailing list is now at 95 subscribers, up from 29. We email a weekly summary of our blog to the mailing list, and hopefully that will keep people engaged with our project even when they don’t use Twitter or RSS.

Stray observations

I don’t know if the kind of traction we’re getting on social media is good, ok, or bad. I don’t know if we should be writing fewer super high quality blog posts or stick to our daily blogging schedule that is more hit-or-miss.

Combining focused programming sessions with social media presence is difficult. Social media is a big and constant distraction, which is why I’ve stubbornly avoided social media for my entire life. Maybe I’ll get the hang of it and find a good balance, but I’m not sure.

Thank you!

Thanks for reading and for following us in our 80 day project. We’re always excited to hear from people, and we’ve gotten some super nice messages! Just shoot us an email at [email protected] or contact us on twitter for any reason. We reply to everybody, usually within hours.

Next update at 30%!

← Previous day (day 16)Next day (day 18) →

You can follow us on Twitter @jdvhouten and @wcools and look for #80daystartup

Read more

Work/new-life balance
Durable tech
Early user feedback
Spending time to save time
Products want to be platforms
Always be launching
Enjoying the journey
Work-life balance
Recap @ Day 59
Perils of caching
Making sense of contradictions
Trust signals
DIY javascript error logging
Taxes: an automation story
Magical thinking
Start small
High conviction, low conviction
Most deals fail

Post archive