Item — HN Reader

It hits home with me, and the TL;DR is: Don't bother setting up "proper" DevOps (but you still need it, just to get going), Don't bother building for scale, Don't bother proper code lifecycle... Until you have some traction. Focus on your MVP. Your truly scrappy MVP.

Applicable most (only?) when there's only 1-2 tech guy. More than that, you need some structure (communication issues).

Technical debt? Yes. Server will crash with angry customers? Definitely. Will never experience those problems because you product will fail anyway? Most likely.

Also, refrain yourself from using that latest JS framework. Use what you know like the back of your hand.

1 comments

Just to expand on this:

> Don't bother setting up "proper" DevOps (but you still need it, just to get going)

Correct, you can use a Makefile or make.sh for years, more to remind you of the build process rather than something that needs to be continuously run, in a startup. Time waiting for a build process is time not adding user features.

> Don't bother building for scale

Correct, since finding the true requirements for scale requires having many users, and the unicorns that you admire had multiple rounds of scale-out rewrites.

(You can add Google Analytics to your pages to see their usage. I've seen some companies do this as a lightweight interim APM before. Pages that nobody uses aren't a bottleneck.)

My current SaaS app has a built-in APM using pre-auth, post-auth and post-load hooks that I added after version 2.0. I learned the auth was slow, but the page generation was fine, so I fixed the auth routine.

> Don't bother proper code lifecycle

Correct, since you don't know what the final version will even look like. The exception is if you've done similar projects with a similar expected load, then you can skip a lot of the steps that didn't work before.

My goal is to write code to Open Source standards, but I realize that rework will be needed later for scale, etc.