I find the tech really interesting, but I'm concerned about the business side.
I've also rebuilt a foundational level tool before and I think there are some critical problems with doing this.
---
Low level development becomes a massive bottleneck. Product development becomes really hard because you often have to touch low level stuff to do anything, which is generally not the kind of thing you can quickly iterate on.
For example, you mentioned that you only support CRA right now with support for Vite maybe coming soon. This seems really bad for adoption and it's not something you can easily change because you have to rebuild this infrastructure just to get people in the door. You might do all this work to support a build system and then realize all those users have no interest in your product.
---
Even if low level development is isolated from product development, low level development is far more time consuming and harsh since correctness matters more. I found it very difficult to balance product development with low level development.
The questions I would be asking are:
- Who is actually going to pay for this and what does their build system look like?
- Are the people who I think are going to pay beating down my door when I tell them about my product?
If there is no clear build system(s) among people who might be paying customers I would be concerned, and if they are not very excited when I tell them about the product I would be doubly concerned because it seems like supporting a build system is high effort.
---
My point of view for rebuilding something foundational is now that it needs to enable something new that is extremely valuable. You are enabling deployments on file save, but is that extremely valuable to people? I honestly don't think so. There might be another use case of this tech which is though.
An example of this is https://bun.sh. He's rebuilding a JS runtime which is a herculean task, but the goal is extremely clear and the outcome (A way faster runtime) is extremely valuable if he succeeds.
I feel like you should pick a single build system and validate the value prop with that first before adding multiple build systems, because otherwise you might be doing a lot of work for nothing.
PS: I really don't like everything on the same domain. Subdomains seem preferable to me.
Vercel is cutting this particular Gordian knot by acquiring / hiring the people who make already popular tooling. And yet, it’s a struggle to shift a substantial production app from AWS to Vercel because the change of programming model from server to serverless is a massive lift for those kinds of apps. Your runtime and build architecture are even farther away from the stuff we ship to production today. I would love to use these features - just like I’d love to deploy on Vercel with NextJS instead of ECS with Express, but it’s a wide chasm. For you more so than that combo, because you can’t provide a local dev experience.
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.
I've also rebuilt a foundational level tool before and I think there are some critical problems with doing this.
---
Low level development becomes a massive bottleneck. Product development becomes really hard because you often have to touch low level stuff to do anything, which is generally not the kind of thing you can quickly iterate on.
For example, you mentioned that you only support CRA right now with support for Vite maybe coming soon. This seems really bad for adoption and it's not something you can easily change because you have to rebuild this infrastructure just to get people in the door. You might do all this work to support a build system and then realize all those users have no interest in your product.
---
Even if low level development is isolated from product development, low level development is far more time consuming and harsh since correctness matters more. I found it very difficult to balance product development with low level development.
The questions I would be asking are:
- Who is actually going to pay for this and what does their build system look like?
- Are the people who I think are going to pay beating down my door when I tell them about my product?
If there is no clear build system(s) among people who might be paying customers I would be concerned, and if they are not very excited when I tell them about the product I would be doubly concerned because it seems like supporting a build system is high effort.
---
My point of view for rebuilding something foundational is now that it needs to enable something new that is extremely valuable. You are enabling deployments on file save, but is that extremely valuable to people? I honestly don't think so. There might be another use case of this tech which is though.
An example of this is https://bun.sh. He's rebuilding a JS runtime which is a herculean task, but the goal is extremely clear and the outcome (A way faster runtime) is extremely valuable if he succeeds.
I feel like you should pick a single build system and validate the value prop with that first before adding multiple build systems, because otherwise you might be doing a lot of work for nothing.
PS: I really don't like everything on the same domain. Subdomains seem preferable to me.