Building for weekends (and vacations)

I've never been paid to code by someone. Just like no one ever paid me to make food, I just love doing it and think I've become decent at it.

The hardest part of a development gig is 24*7 support. The business doesn’t shut its doors to customers anytime and a basic expectation from me is that everything will always work. If it’s not, I’ll get on top of it and fix things. I wouldn’t have it any other way either.

Being a solo operation means doing sales, legal, funding, etc. on top of this. It can’t be done unless the firm is fundamentally designed to manage this constraint.

My approach to this is a framework:

1. Pick a boring tech stack. One thing which great engineers doing boring stuff do is to make things backwards compatible. Since I cannot always be available to handle breaking changes, boring tech stacks allow me to enjoy a little sun.

2. Pick a familiar tech stack. All of Wafrow is built in PHP (Laravel) and hand-rolled html and javascript. Could I do better? I’d say yes! But somehow the flashy javascript frameworks today make very odd choices that make them bulky and hard to like. I deal better with things I can go deep into and understand. Making things ‘easier’ shouldn’t make them obscure and unpredictable.

3. Obsess on the design of failure points. The highest number of traffic Wafrow gets is at the point of experiment bucket allocation i.e., determining which user/session is in which experiment variant? Of the 5 weeks that Wafrow has been developed so far (including everything else), I’ve spent 2 weeks designing just this aspect. I made a few prototypes and tested multiple approaches to pick a decision I can live with. I know we’ll need to upgrade this at some point but obsessing on this failure point forced me to make product decisions which will ensure the smallest chances of people having a bad experience.

4. Read best practices extensively. LLMs have made doing research easier than I remember it to be. Sometimes condensing documentation into directly actionable code. Reading how experts solve a problem and digging into their github code has been really helpful.

5. Expect dependencies to fail. Wafrow stands on the shoulders of giants who’ve done most of the heavy lifting. I made product choices assuming that one of these giants may stumble for a few minutes and I need a shoulder in their place. Very tangibly, if my own hosted server on digitalocean fails for any reason (likely my own stupidity), I’ve built a pass-through layer directly to call posthog and return all experiment data. It will be inefficient in that phase but a few milliseconds of experience downgrade is better than not serving users at all.

It's served me well so far. Let's see how this scales :-)