"Just code up 6 these screens, we already have everything working in sketch - how long could it take" Then you realize the "6 screens" actually turn in to a 50

"Just code up 6 these screens, we already have everything working in sketch - how long could it take" Then you realize the "6 screens" actually turn in to a 50 step state machine that shares state between screens and changes screen logic conditionally on other screens, and the designer created sketches for the happy path. And your "really simple straightforward state management" now has you going through 10 steps and 3 screens before you can arrive your state 11 which you are working on, you can't unit test the logic because your state is tightly coupled to UI and the HTTP stack, you can't reason about state updates because it's happening all over the place and is written by 3 other people concurrently, and coming to the project 6 months later makes you quit on the spot. I've written plenty of WinForms to JQuery UI to know that "simple state management" is anything but. Redux has initial overhead but down the line it pays for it self in these scenarios many times over. Going over requirements/flow with product owner and then writing tests for a reducer specifying the expected states is incredibly powerful in ironing out miscommunication in requirements and much faster than sending iterations of UI app to testing. Like the parent said - the hairy part of the app ends up being dealing with the state machine - shuffling data over the HTTP is trivial, CSS/layout/animation are not that hard if you know what you're doing and don't need to support ancient browsers.