Reflame

Since completing the initial prototype, I've dogfooded it to build a bunch of personal toy projects, and improved on it a fair bit. But I've become more and more discouraged by the lack of progress on the actual SaaS MVP as time went on.

I kept making excuses for my lack of progress by attributing it to things happening at work that kept draining my energy, and the little time I did manage to muster up, I ended up spending distracting myself with cool little open source side projects that I kept trying to justify by telling myself they will build up my open source street cred which might help me build an audience for when I need to market Reflame.

Eventually I realized that I've become so much more passionate about Reflame and the value it could bring to the world of frontend development than my admittedly very comfy and awesome day job as an OG frontend engineer Brex. I was very lucky and grateful to have been a part of that journey since the very beginning and working with so many inspiring and talented people day to day, but I had to come to terms with the fact that I was no longer happy with dedicating so many of the most productive hours of my life to something that wasn't Reflame.

So I quit, and since then I've been focusing the majority of my waking hours on making the SaaS MVP of Reflame a reality, while holding a few part-time contracting hustles to keep my TN Visa so I can stay in the US.

New goal is to get the Reflame MVP ready for a "friends and family" alpha within the next 3 months.

Working only on nights and weekends, it took me quite a while to finish the prototype.

The prototype was built as a CLI that ran locally to watch for file changes and integrated with S3 and CDNs through chaining together a bunch of SDKs for deployment.

I was able to prove out the following:

1. It was possible to build a reasonably low-latency react fast-refresh workflow that worked against real production assets hosted on S3 behind CDNs as opposed to assets served from local dev servers.

2. It was possible to build a content addressed dependency graph for distributed caching of JS module assets, to minimize the amount of work that needs to be done on each new file deployed and take advantage of immutable cache headers for long-lived granular client-side caching and minimize invalidation on updates.

3. It was possible to do all this while keeping costs to a reasonable level for a relatively productive engineer shipping changes per day in the hundreds to low-thousands, to ensure I won't have to charge my users an unreasonable amount of money to just break even.

This means it was time to start turning this prototype into a real MVP, which of course had to be a SaaS. And I would build out the frontend portion of the MVP with the prototype to dogfood the experience and start feeling any potential pains early on and adjust for them.

Idea was initially inspired by what https://darklang.com/ was doing for backend development. Their relentless focus on minimizing production deployment latency with novel safety rails that don't compromise on production deployment latency (feature flagging, testing against production, etc) really resonated with me.

I eventually realized it might be possible to build out a similar workflow for frontend development, while limiting the scope to "just" reworking the deployment workflow, without trying to also replace the language, editor, and infrastructure like dark was, so I can realistically have a chance of releasing something and reaching product market fit in a reasonable timeframe.

There were a lot of technical unknowns for me at the time, so I started building out a prototype to prove out the feasibility of the idea and try to rule out the biggest potential show-stoppers up front.