Launch A Project In One Day


I created #MustReadBooks in one day. I had the idea 30 years ago, during the 90s, already had a domain for some time but didn’t execute on it.

MustReadBooks.me is a website where people can share their 5 must-read books for one audience, for example, my 5 must-read books for engineering managers. It wants to set personal curated lists of the 5 most important books (not 10 or 20, I did need to drop many to come up with five) against AI generated content.

Sitting on the idea for thirty years (and having seen many websites on the topic), now in one day I have something to show. I wrote the code, set up a deployment pipeline, instantiated the cloud servers, load balancer, SSL, connected the domain, added global load balancing, added a CDN, made CI/CD work and soft-launched the MVP.

How was that possible? Because of two things.

  1. Radically limiting the scope
  2. Using things I already know

There currently is no signup and I onboard users (friends) manually. There is no start page to list all users. There is no cross linking. There is no way for Google to find all pages. But users can link to their 5 must read books. But I have something to share and show and get feedback for.

Second, using the things I already know. They are different from the things you already know, you stick with those, I don’t want to convince you of the way I do things.

  1. Go - simple and fast language, creates fast websites with one server (40ms in Europe with a db roundtrip). I needed to stop myself from something new I wanted to try, in this case Zig. Go (pun intended!) with the things you know.

  2. Echo/Gorm ORM/a-h templ - There are new Go web frameworks I wanted to use, but I know Echo, and it has batteries included, the same goes for Gorm, it has plenty of users and documentation.

  3. Postgres - just use Postgres for everything. Playing with SQLite and LiteFS is tempting, but I know Postgres and the ins and outs, no surprises there.

  4. Hetzner - Cheap and just works for most things. Wanted to play with other cloud providers (perhaps Lidl), also wanted to try performance with a managed SaaS Postgres. But didn’t.

  5. CI/CD - GitHub, ’nuff said.

  6. Deployment - using my single binary Systemd deployment method I know from several projects. Simple, works, doesn’t drop connections during replacement of the binary. Restarts on crash, restarts every 24h.

  7. bunny.net DNS/CDN - I didn’t want to use something new, Bunny is practically perfect.

  8. Better Stack for Uptime monitoring, Simple Analytics for analytics, Google Search console for SEO.

I did use something new (nothing blue though!) - Pico.css instead of my usual Tailwind or instead of Mvp.css that I had used before. I thought the risk is limited and wanted to have new minimal CSS options.

Pico.css looks decent for a no-work application. I reused Reflex Grid instead of Pico.css grid because of my familiarity with break points.

I had a rough idea in my head and started writing some code, based on a skeleton of application I had lying around, with modules and some helper classes. This enabled me to write the code fast. Reusing a Makefile with all targets from a former project and deployment artifacts for Systemd, the code was easy to deploy to production.

Now on to some more features (adding lists to sitemap.xml) and opening up signups.

Most important of all, I scratched an itch I had for a long time. Now I can point people to my must-read-books as reference.

What can you take away?

When starting something new, don’t drop the ball by using all those new shiny things. What do you really want, playing with new toys or get the project out of the door and be successful? I know, every engineer thinks they can eat the cake and have it, but this is an illusion, my friend.

Join CTO Newsletter

Join more than 3500 CTOs and Engineering Managers

More Stuff from Stephan

Other interesting articles for CTOs

Best books for CTOThe CTO BookExperienced CTO CoachEngineering Manager CoachingConsulting and Workshops to Save you TimeCTO MentorCTO MentoringCTO NewsletterHow many developers do you need?Postgres for Everything Technology and RoadmapsHow to become a CTO in a company - a career path

Other Articles

Comparing CPUs for Development

Our Fetish with Failover and Redundancy

Just Use Postgres for Everything

😊 One Thing A Day For Happiness

Dear Paul Graham, there is no cookie banner law