DeathClock.io launched!

Preface

To be completely honest and transparent with myself and the world, I’m an 80%er. What I mean by that is, I love creating things, but usually I hack away for weeks or months, getting most of the stuff in order, just until I reach the 80% threshold, and then I lose all motivation. I’ve known this about myself for a long time. There has been some notable exceptions, but generally that’s how it’s played out historically when hacking on my own projects.

With that as the backdrop, it glads me to say that I’ve released the first version of my first hacked together project, Death Clock.

Idea

Basically, the idea was to create a simple visualisation tool of how much time you have left to live to act as a gentle nudge towards making great use of whatever time you have left. I had thought about this idea for long (not to be creepy; but I think about death a lot, in a very practical and non-pathological way).

Initially, the thought was get the user to a page where they can get a visualisation of the passed and remaining weeks of their approximated life expectancy, together with some facts intended to create emotion within the user.

Pitching this idea to people around me, some pointed me to the great Wait But Why article doing a very similar thing. In any case, I wasn’t deterred by this fact, since I have a slightly different approach and plan behind the whole thing.

Scope / Features

One of the main reasons I chose this idea and not one of my many other stupid ideas was that it was pretty well-constrained in terms of functionality necessary to create the first MVP, and that a business model was included right from the start. While there were some cool gizmos, gadgets and technical aspects that I wanted to implement, the MVP really just consisted of:

  • An algorithm to calculate a persons expected life expectancy
  • A basic app to visualise this
  • Simple payment processing
  • A printing service to handle any orders

I’m a great coder, so I’ll just bash that out in a day or two, no? Well, we’ll see.

Platform

For the technical platform, I decided to use a mix of technologies that I knew well and try out some new things that I knew less well. Below is a list of what I used and why.

  • React. For frontend stuff. Been working non-stop with React for the last few years, so it felt like a natural choice.
  • Node/Express.  For backend stuff. Since I’m super-comfortable with Javascript because of all the frontend programming, this also was an easy choice. Also, in terms of backend, I only needed something minimal.
  • AWS. I had used AWS very sparingly before, and for this project it was probably completely overkill, but there were really two justifications for using AWS.
    1. Learning. I know that AWS has wide-spread adoption, especially in bigger projects, and learning how to set up something with AWS will probably prove to be very useful for the future.
    2. Scaling. Again, probably overkill for this project (both since it’s super simple and because it will probably be a long time before you have to think about scaling). However, I felt that if I set it up properly, if I ever needed to scale up, it would just be a click of a button rather than setting up everything from scratch again. Together with the learning aspect, I felt that this was a good future proofing in case I ever got boosted in some social media.
  • Nginx. The site uses nginx as a reverse proxy for the node/express server. Again, this is overkill for this project most probably, but the motivation is the same as for using AWS; learning and scalability.
  • CrispChat. I chose to go with CrispChat as a primary support channel, mostly because they were free and they covered my basic needs. I don’t really have any feedback to give on this service so far.
  • Printful. Printful handles the printing of the posters, when and if the orders come. So far I haven’t written an integration for Printful since I thought I could do it manually until I’ve validated the idea (this part is super specific for this idea, whereas the other tech stuff is usable in all future projects).
  • Stripe. I’m using Stripe Checkout to process any payments that I get. I’ve gone completely database-less for this app (at least as of yet), so whenever an order is made, the required data is just attached as metadata to the Stripe charge for later manual processing. Integration with Stripe was pretty much a breeze, which was nice.

(Technical) Challenges

The absolute biggest challenge was that I had never used AWS, and getting it to work well proved to be quite a cumbersome task. This probably took me 7-8 times as much time as I expected it to do. However, now it’s set up in a fashion where if the server running the application is killed, it can almost instantly spin up a new server of any capacity to replace the previous one. Some stuff that took longer than expected

  • Figuring out how to setup all the required tooling automatically on instance creation.
  • Auto deploy whenever code had been pushed to GitHub.
  • Auto scaling (if the server ever crashed or was terminated)
  • Automatically fetching whatever secrets were needed from AWS SSM Parameter Store.
  • Automatically setting up SSL-certificates on new instances

Possibly I’ll collect all of my findings for setting up AWS into another post sometime. There are a lot more moving parts than for instance setting up a VPS at DigitalOcean (an approach I’ve chosen before), but the hypothesis is that this will pay off in the long term.

User Testing

So far I’ve done little to no user testing. I’ve only really showed one other person how to use and got some good feedback regarding additional interactivity and to showing a real world photo of how the poster might look.

Investments & Costs

  • Money. Most of the infrastructure falls under AWS Free Tier so it should be close to free. I bought the domain name deathclock.io for something like $10.
  • Time. The biggest cost has been the time investment. I’ve probably spent something like 60-80 hours working on it effectively, where probably half of that has been setting up AWS (no kidding).

Resources

Some resources found along the way;

  • NameMesh. Pretty good domain name generator that also shows the availability of the domain name. Doesn’t seem to be working entirely correctly for all TLDs, but works well enough.
  • AWS Cheat Sheet. Basically, it translates all of the weird AWS names into plain English, like writing VPS instead of Amazon AWS EC2 which, to be honest, is utter gibberish.

Future

I’m not expecting this service to blow up on day one. When I’ve launched stuff in the past, usually and extra ordinary amount of work is required in the beginning, and then after an arbitrary amount of lag time it starts getting traction, so I have that long-term mentality in mind.

However, in the short term, I’ve thought about

  • Using Google Adwords to drive traffic to it, to see if it converts at all, and start optimising the conversion.
  • Do more user testing with people physically around me.
  • Add more interactivity and fun facts.
  • Ask more designer oriented people around me to give some feedback
  • Order some posters to do actual product testing ( I should have, but I haven’t yet. Lean.  😃 🐴 )

Feedback?

If you have any feedback on the this post, I’d love to hear it. I’m pretty new to sharing in this transparent fashion, so I’m curious to hear what you think. Please write a comment below or send me an email! Also, if you have any feedback or ideas my death clock project, that’s appreciated as well!

Leave a Reply

Your email address will not be published. Required fields are marked *