Really appreciate you taking the time to write this super thoughtful comment! There's definitely a lot of valuable feedback/advice for me to take away here.
Re: supporting new build systems. You're totally right that it's a lot of work, with tons of potential edge cases to cover. In my ideal world people would just use the dev workflow provided by Reflame out of the box, and not bother with Vite/CRA/anything else, and everything would be easy. But in the real world I do need to meet potential customers half way and make the product as easy and low risk as possible for them to adopt, and supporting existing local dev toolchains is a crucial part of that effort.
Luckily though, I think supporting just CRA and Vite-based React apps is enough for me to capture a good 50% of the kinds of apps I'm looking to target, and I don't have plans in the short term to add support for anything else without strong demand from customers.
Re: monetization, this is definitely still the big question mark hanging over my head and keeping me awake at night. Pretty much everybody I show Reflame to seem super excited about the idea of previewing and shipping instantly, but only a very tiny fraction of those people have actually ended up giving me their credit card.
I did end up getting quite a few more new users to talk to with this launch though, so I'm looking forward to chatting with them to figure out whether they are willing to pay for instant deployments, and if so, how much, and if not, what's missing.
It's going to take a while, but I'm personally convinced that engineers having to wait minutes to deploy is a valuable problem worth solving (companies are already spending tons of money, both on SaaS and entire teams of engineers just to _keep_ it in single/low-double digit minutes in the first place, after all), and can be turned into a great business. And even if I turn out to be wrong, at the end of the day, I've been building the deployment platform of my dreams that I always wanted to use, that I can continue to use to build new products going forward even if nobody else does. I don't think I'd ever regret a single moment spent doing that (in fact I've been deeply regretting not having started on it sooner).
Re: Bun. I'm a huge fan of Jarred and Bun too! Have been following his progress for quite a while, and it's been an amazing source of learning and inspiration, even though we're solving very orthogonal problems.
Re: same domain vs subdomain previews. Appreciate the feedback! I'm not dogmatic at all on _only_ having same-domain previews. But it was important for me to have it available as an option at the start, because I think it is valuable to have in many circumstances, even if not as a default. And I at least wanted to experiment with having it as a default, because at least in theory, more production parity should offer us more confidence, still TBD on how that works out in practice. Adding subdomain based previews will certainly be on the table if I get enough similar feedback. Should actually be a lot more straightforward to implement since I already have most of the pieces in place.
Re: supporting new build systems. You're totally right that it's a lot of work, with tons of potential edge cases to cover. In my ideal world people would just use the dev workflow provided by Reflame out of the box, and not bother with Vite/CRA/anything else, and everything would be easy. But in the real world I do need to meet potential customers half way and make the product as easy and low risk as possible for them to adopt, and supporting existing local dev toolchains is a crucial part of that effort.
Luckily though, I think supporting just CRA and Vite-based React apps is enough for me to capture a good 50% of the kinds of apps I'm looking to target, and I don't have plans in the short term to add support for anything else without strong demand from customers.
Re: monetization, this is definitely still the big question mark hanging over my head and keeping me awake at night. Pretty much everybody I show Reflame to seem super excited about the idea of previewing and shipping instantly, but only a very tiny fraction of those people have actually ended up giving me their credit card.
I did end up getting quite a few more new users to talk to with this launch though, so I'm looking forward to chatting with them to figure out whether they are willing to pay for instant deployments, and if so, how much, and if not, what's missing.
It's going to take a while, but I'm personally convinced that engineers having to wait minutes to deploy is a valuable problem worth solving (companies are already spending tons of money, both on SaaS and entire teams of engineers just to _keep_ it in single/low-double digit minutes in the first place, after all), and can be turned into a great business. And even if I turn out to be wrong, at the end of the day, I've been building the deployment platform of my dreams that I always wanted to use, that I can continue to use to build new products going forward even if nobody else does. I don't think I'd ever regret a single moment spent doing that (in fact I've been deeply regretting not having started on it sooner).
Re: Bun. I'm a huge fan of Jarred and Bun too! Have been following his progress for quite a while, and it's been an amazing source of learning and inspiration, even though we're solving very orthogonal problems.
Re: same domain vs subdomain previews. Appreciate the feedback! I'm not dogmatic at all on _only_ having same-domain previews. But it was important for me to have it available as an option at the start, because I think it is valuable to have in many circumstances, even if not as a default. And I at least wanted to experiment with having it as a default, because at least in theory, more production parity should offer us more confidence, still TBD on how that works out in practice. Adding subdomain based previews will certainly be on the table if I get enough similar feedback. Should actually be a lot more straightforward to implement since I already have most of the pieces in place.