From idea to product in 7 days

We went from an idea to a full product in 7 days. Here’s how we did it.

First, the idea

Sometimes, it’s frustrating to copy a file from a computer to another one, for example two servers. You may have to download the file to your computer over slow ASDL, then upload to the other server with an even slower ASDL uplink, just because they can’t talk to each other directly. And there was no tool for this job.

I loved the simplicity of the problem, easy to tackle alone.

I came up with a domain name the same day: ezcp.io ! Short, catchy, and probably understandable by fellow developers and sysadmins. Finding that name made the whole idea more fluid. Somehow, I felt energized with that domain name: usually, I’m looking for a name for weeks.

In the case of ezcp.io, the domain name came before the first line of code was written. A first.

Next was monetization: let’s put some ads on the front page, and ask for a Bitcoin payment for a premium tier (we didn’t put ads on the page in the end, because that’s how we like it).

Then the other developer joined. He was looking for a side-project, I offered one. Working in a team helps with motivation.

So when you see a void, find a domain name, see how to monetize, and find someone to share the load, the joy, and create emulation. And choose a problem you can solve without $1M.

The new shiny stuff

You know what I mean: you must try something new on a new project. Having something new to learn is a major motivator in my case to start a side project.

For ezcp.io, I choose Golang on the server… not a first.
node.js and golang for the CLI… not a first.
Mongodb for the database… not a first.
Prometheus for the metrics. That’s a first, but it came last in the implementation.
Bitcoin for payment. That’s also a first! and a big one.

And that’s probably why it took us only 7 days.

I chose Golang for fun and by conviction. I’ve started using it exclusively, after years with node.js, less than 6 months ago. And I’m enjoying every line of code… almost. It’s very important to use enjoyable stuff for a side-project. Motivation is key. But using something you already know will help a lot.

Some may wonder why I chose Mongodb. The answer is simple: I’m already running a 3-servers cluster for other projects, and I know mongodb well. I could have tried to setup a Cassandra cluster… but mongodb does the job perfectly. And I didn’t want a SQL database that can’t do automatic failovers. I don’t want to babysit a database.

I’ve upgraded Mongodb from 2.6 to 3.4 with no downtime for my other app.

Don’t choose only stuff you don’t master in a side project. Build on what you already know, and add new stuff to it. Don’t let your project rely on something crucial you don’t know at all.

Let’s get coding

Being a server-guy, I started with the server. Very simple, very easy. Upload a file. Download a file. But it was a first for me in Go! I’ve been using Go only for websocket applications before, now was time for HTTP.

Automatically issued Let’s Encrypt certificates were probably most of the fun, but I got to enjoy the interface-based design that’s so specific to Go. Does your Let’s Encrypt lib require a KV store interface? That’s a job for your DB layer. Just implement the interface, and here you go: your certificates are now stored in mongodb (for sharing of certs among instances).

Bitcoin was the biggest unknown of the equation. I do own some, I know the basics, but I had no idea how to receive payments. I first thought Coinbase would offer convenient APIs… not so much. So I turned to Bitgo for a Bitcoin wallet with nice APIs. They have no Golang client, but my needs were few: create a new address to receive payment, and check a transaction hash to see if it made it to my wallet.

But with Bitcoin came a great idea: we’re not going to ask for an email/password registration! Instead, we’ll use the transaction hash as a proof of payment… and that proof of payment is also an authentication for the user. In a word, the transaction hash is the user’s login/password! and it’s certainly way more secure than a password like ‘password’.

Adding Prometheus was fun too. It’s a very well designed tool. I’ve used statsd-graphite (and statsd-influxdb too) in the past, and Prometheus is clearly ahead in terms of architecture with well-designed instrumentation and reversed responsibility (clients don’t push stats, servers pull instead). I loved it. It was set up in an afternoon (server and Grafana included) and everything worked at first try.

When trying new stuff, be open to new ideas that may emerge as you’re wandering in a new territory. We didn’t plan for Bitcoin-based authentication, it just happened. Prometheus came to mind when I realized we’d have no logs at all, no feedback, without a reverse proxy/SSL terminator like nginx.

More coding

While I was coding the backend, my partner was hard at work on the node.js CLI. It was mostly uneventful, until I ported his implementation to Go.

I thought a Go implementation of the CLI would be a force, for those who don’t use node.js and prefer a binary. It was easy, until we tried AES encryption between node.js and Go. Node is generating an AES key in its own way, and I was lucky to find other guys with the same problem on the net. One guy took the time to port a function from OpenSSL to Go that could be used to generate the same AES key from golang and node.js.

We’ve open-sourced the two CLIs, feel free to have a look.

There will be blood… when you expect it the least. Be prepared for the occasional point where you’ll be stuck. That’s when the internet will become your best friend. Google it.

Almost there

You don’t really exist on the Internet until you have a website, and we’re no designers. We did our best, trying to keep the home page very lightweight at <10Kb compressed, CSS and JS included (but excluding Google fonts).

No Google analytics. No server logs. No email/password registration. No ads. Only straight to the point contents. We’re trying hard to be 100% honest, and share the values of our audience: don’t ask for my email, don’t track me, don’t make me load 10Mb of jpeg and JS junk, just let me use your stuff.

Don’t be evil, share the values of your users.

Conclusion

Today was launch day. Exactly 7 days after I had the idea for ezcp.

How did it go? okay. We got visits. No users, and no registration. We won’t be rich overnight (well, technically, we’ll know only tomorrow morning! Go try it at ezcp.io), but it was worth it. It was energizing to work very fast, to iterate on ideas and code with a very short dead line.

The beauty of a side project is that it doesn’t need to be a commercial success. You just have to like it, to enjoy it, and to learn from it.

And I can tell you it was worth every late hour spent on it.

Like what you read? Give Chris Hartwig a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.