Working on old projects

With side projects like Revisit, if you are like me then you tend to update them once or twice a year.

Every attempt leads to the painful realisation that the version of every dependency has moved on. First thought is to try to upgrade the project. 4 hours later when the project is very broken and no end is in sight you realise that this process isn’t working. Most likely, it’s time to give up, but it’s actually quite easy to Rsync the whole server into a Vagrant machine and have a working version with all dependencies.

First create vagrant machine with a linux distro that matches the server:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config| = "ubuntu/trusty64" "private_network", ip: ""

Then run vagrant ssh to login to the vagrant machine.

Run the following. NOTE: change /home/user/.ssh to your user ssh directory and change root@ to your server.

sudo rsync -aAXvP --exclude={/boot/,/dev/,/etc/fstab,/etc/modprobe*,/etc/modules/,/lost+found/,/etc/mtab,/etc/network*,/etc/sysconfig/ip*,/etc/sysconfig/kernel,/etc/sysconfig/network*,/lib/modules/,/media/,/mnt/,/proc/,/run/,/sys/,/tmp/,/var/lib/lxcfs/,/var/lock/,/home/user/.ssh} root@ /

This command comes from the Digital Ocean Downgrade guide.

Reboot the machine and then you should be able to access the machine in the same way as the server. E.g. You may need to remove any SSL config but everything will match what is on the server (including the database). Be careful because this server will have production data.

If you’ve ever tried to share a directory with vagrant to do work with a server that watches the disk e.g. rails, nodejs, elixir, then you have probably run into issues with changes not being picked up and forcing the server to reload. A fix for this is to use sshfs and mount the directory from inside vagrant. To do this on a mac first install Fuse.

Run vagrant ssh-config to get the port that vagrant ssh is running on. Also


From here you can ssh onto the vagrant instance and run your app in development, make changes in the mounted directory, and deploy changes easily once finished.

For bonus points take a backup on the vagrant instance so you don’t have to go through is again:

vagrant halt
vagrant package

Run Markdown

I ended up writing run-markdown yesterday. A utility that lets you run code in a markdown file.

Check it out here:

Pretty Good Slice > Minimum Viable Product

When showing a product to a potential customer, the best outcome is those fantastic words, “How do I pay for this”. Those words were said at my first pitch and it’s all because of ditching MVP.

Instead of MVP, my approach is to make a “pretty good slice”. Build out a single feature (vertical slice) and polish it to about 75%, then try and sell that feature. The feature you pick has to be the most important feature that you think users will pay for. And it needs to stand on its own, everything else is manual.

So what does a “pretty good slice” have in it?

  • It is designed, not to the highest level of polish but it feels close to finished and is pleasing to the eye.
  • An onboarding so that users can quickly understand what the feature is about.
  • A blank slate that gives the user a sense of what will be there once content is added.
  • Any graphs, info, etc that make the feature complete.
  • Copywriting that has been reviewed but might not be perfect.

What shouldn’t it have?

  • Animation (unless they are at the core of what you are trying to make)
  • Links to other features

The default mindset for MVP is “the worst version of all features”. I know this is incorrect but it’s what happens. Even with the correct version an MVP includes a larger set of features, e.g.

  • Users
  • Passwords
  • Emails
  • Accounts
  • Lots of domain specific features

But there isn’t any proof that anyone would buy the core single feature. And because all of the features are implemented without any love, potential customers take a lot more work to get over the line.

When showing my first customer and they were able to use the feature, see the value and from there I had a sale. A lot of “things that don’t scale” were happening in the background but I have proof that a customer will buy this key feature and they didn’t get scared off by a sad experience.


Going to do Hackagong again this year. Here is a reminder of what I worked on last year.


Recently I started taking notes on copy paper. I Noticed that my notes were completely different to how I would take them on the computer. On copy paper they were freeform - using space as a way to organise thoughts. This lead me to experimenting with the idea of Evernote meets Google Maps.

Atlas lets you zoom between summary and the details. It is quick and easy to create maps and notes. Markdown is used to format notes, making it easy to copy and paste into other apps.

I made Atlas as a Railscamp project that helped me learn React.

Try the demo at and checkout the source

subscribe via RSS