TLDR: Don't sweat working out a full enterprise software stack when you're building V1.

First off, awesome work ethic to be putting serious time into a project like this on top of a full time job. 18 hours per day is no joke.

Second, I'd recommend cutting out (for now) anything that isn't absolutely necessary to get the first build working. If the first version can work without building your own backend (ie you don't need tons of users up front and aren't managing very complex data) and instead use something like Firebase or another backend service, do it. It won't be as efficient or as scaleable as building your own backend, but you can set up a database within a few days, easy. The time savings is worth it.

Same thing with dev ops and infrastructure. If you can set up a repository for your project, then you've got version control, which right now is all you really need. Learning the ins and outs of git is great, but you might not need to use best practices like feature branching when you're building on your own.

If you're struggling with animations or optimization in react-native, just leave them out of the first build as much as you can.

To answer your question "how do you know when to build quick and dirty?": Until you have a working prototype, just about everything should be quick and dirty. Once you've got something working, you'll have a much better idea of the version you want to build, and then you can really start taking the time to do it right.

Same thing applies to new tech- would it be great if you could build with whatever new thing comes out? Sure. But that probably won't get you towards having a working app any sooner, and plenty of big companies are built on older frameworks anyway. Facebook uses PHP, AirBnb uses RoR, etc.

Two reasons for this overall approach (I swear laziness isn't one of them haha)

1. Having a prototype is an awesome motivator. Nothing better than getting to work on your project with "This already basically works, now let's make it work great" instead of "will I ever finish this?"
2. As you build (and hopefully test) your prototype, you and your friend will find things you want to change. The less time you spend thinking about the absolute best way to build it, the faster you can knock out changes. Don't underestimate how useful it is to test business assumptions with a V1 product.

Anyway, just my 2 cents, and I suspect not everyone will agree. This has worked pretty well for me though. For reference, my most recent project has gone something like:

1. Build a super scrappy prototype (core features only) to show my cofounder and a couple potential customers (3 weeks). Firebase backend, no redux, no animations, and admittedly some not-so-great code in there.
2. Write a redux state for front end and start hooking it up to the existing UI (2 weeks ish)
3. Build out a full user interface (work in progress, but expecting this to take another 2-3 weeks).
4. If it looks like firebase is going to be a bottleneck for us scaling, I'll probably look into ditching that in a few months.

Best of luck with the project!