On the CNAME feature in particular, we’ve discussed this as a team many times because we’re very aware that it’s a game changing feature for our customers building apps that require white-labeling. Each time we break it down and try to put together a plan for it, though, we realize that it’s likely months of work from our most senior engineers. The big challenge is that Bubble was built on the assumption that each app is hosted on a single domain. That assumption is everywhere in our code, from our login handling, to our page routing, to our front-end datasources. Changing it would require an overhaul of a bunch of our key systems. That’s why we keep pushing it back. We would love to build it, and we hate saying no to features that you urgently want, but it’s on a massive scale, and our biggest constraint right now as a company is engineering time from people who know Bubble’s systems really well. We can’t put a timeline on it without actually having the resources and plan to carry it out. When we rolled out our CloudFlare integration, which touched a small subset of the code we would have to touch to build this feature, it ended up being a much longer project than anticipated. Same with the editor redesign (which isn’t really in competition with this project for engineering time, since it’s much more front-end oriented and requires a different skillset). So we’re really careful about taking things like this on, no matter how much we want to do them.
As far as crowdfunding features in general, I think @allenyang did a very good job explaining why we stopped doing this (we haven’t done it in years, and even when we did, we were selective about which features we’d accept and only take on ones that we thought we could reasonably deliver on with the time we had). I think the crowdfunding model might work better with plugins, because plugin building is more scalable, so I’m excited to see what comes out of the discussion on this thread about it.
My biggest personal frustration with Bubble is how long it takes to change things technically. Back when Emmanuel and I first started, it was all green field development; we didn’t have to worry about breaking things or supporting existing use cases, the codebase was smaller, and it was just the two of us. As we’ve gotten more customers, added more features, and grown the team, it’s gotten harder to move as fast as we used to do, and I think both the team and the community were used to and addicted to that speed. My biggest personal priority right now is getting our team trained: I’m currently building out an internal training course that teaches new engineers the ins and outs of our technology, so that we can bring on more engineers and get them up to speed faster. We’ve had a bunch of great people ramp up lately and start making real contributions, but there’s still a very finite amount of things we can do. We still have issues in terms of reliability and performance with features we’ve already shipped, let alone shipping new features, and we desperately want to make sure we upgrade the quality of them so that the people using them today have less pain. So when we ignore urgent pleas to add a new feature, it’s not because we don’t care, it’s because we’re constantly stretched to our limits of how much we can work on at once, and have to make tough triage decisions.