OnlineOrNot Diaries 25: you can just build things

I know, it sounds cliché at this point, but you can just build things.

What do I mean by just build things? I mean, don't obsess over the right language, framework, tools, or approach to use.

Just build something, and ship it.

In the absolute worst case, you get it wrong. Guess what? you can just fix it.

I'm writing this article after realizing it has been four and a half years that I've been working on a product folks told me "won't work at scale", and "can't be viable". They were mostly wrong, and the things they were right about? I fixed.

The right programming language to use

A painfully common question I see is "what programming language should I use in $INSERT_YEAR_HERE to build my side project?"

The correct answer is: the one you already know. If you already know PHP, just use PHP. Same goes for jQuery, Java, Node, etc.

(Of course there are caveats. If all you know is VB6, and you want to build modern web apps, you might want an egghead.io subscription first.)

I'm a strong believer that getting things done quickly and well is the only thing that matters. If you're spending half of your project's time learning the language, or figuring out if how you use it is the "language-way" of doing things, when you could be building, you're wasting your time. If your goal is to learn the new programming language, do it intentionally. Trying to build a business at the same time will only distract you.

I'm speaking from experience here.

I've known since about 2016 that I wanted to build a business on the Internet (for context, I started my professional career building with AngularJS 1.5 and Django, and shortly afterwards pivoted to React and Node.js). My first month or so of trying to build an Internet business was just to figure out which language/framework to use. I ended up using what I used at work (React + Node.js), but that was a frustrating month of indecision.

Building it "correctly"

I'm writing this for folks with little-to-no users. Obviously, at web scale, getting it wrong hurts. Like, "a multiple-year project to handle the rewrite, migration, and user messaging" levels of pain.

The great thing about wanting to carve out a small portion of the Internet to run a bootstrapped business on, is that our projects aren't that hard to fix if we screw things up.

I'd argue at small scale, there's rarely a "right" way to build things. Just get things out there, and see if people will use them.

I started off OnlineOrNot on AWS Lambda because I knew it would cost me nothing if I got no users. I got users, enough to keep my AWS Lambda functions active 100% of the time. It started to cost me a shit ton of money more than if I just used a VPS. If I used a VPS from the start, I doubt I'd have shipped.

So I rewrote to use a VPS. It took about 10 hours. It didn't work for my use case. I undid the change, and eventually moved to Cloudflare Workers.

More recently, I noticed OnlineOrNot's main dashboard was taking longer several seconds to load (almost at one billion uptime checks complete at time of writing). After spending a bit of time optimizing the query and indexes, I got the query down to 500ms.

Was using postgres for clearly analytical (OLAP) workloads right? Clearly not, but it did the job until things started to get slow, and since moving to Clickhouse, that query now runs in 50ms.

In short

Your technical approach doesn't have to be perfect the first go.

Just make sure it works, and iterate.