Re React v Angular:
Before Angular I was coming from knockoutjs, and most of Angular made sense to me pretty immediately out of the box. It felt very quick to get going.
The community/tooling around it was also pretty great. For example, angular-material is miles ahead of material-ui (the most popular react material UI framework). I've definitely missed having access to so many great off the shelf libraries.
The downsides were mainly around architecture; we ended up littering state all over the place as a result of two-way bindings, and it always felt a little like we were missing an important abstraction. Even on an MVP, it started to feel like we were nervous about touching components because we weren't sure what would break elsewhere in the system.
Flux stores/dispatcher is that abstraction we were missing. We've made an effort to follow the model closely with all of our DB data and it pays off wonderfully. The code is easier to reason about and I have more confidence about which changes could produce downstream effects.
The downside is following the pattern tightly requires a whole lot of boiler plate. For simple things like flipping a bit in a component in response to a user action, angular was incredibly easy. Doing it following the Flux pattern is much less so (dom element calls a callback in the component which calls an action creator which calls the dispatcher which is listened to buy a store which is observed by the component..). In Angular you touch two files with one line of code, with React the same change might involve changes across five or six files with a lot more boilerplate.
I do think that extra work pays for itself in future maintenance costs, but for a scrappy start up trying to move fast, it can at times feel painful.
Which brings me to testing; The short answer is: we don't. I think testing is important for a product with an established user base. I think it's less important when you're trying to get an MVP out there to see what people think. We know that what we showed today will need to change, we're just not sure how yet. Assuming that pretty much everything in the product will churn in the next six months, setting up a robust test suite felt too expensive for the value it returns. As the product consolidates we'll fill in tests, but not while the feature churn is as high as it is.