Give up. Your current team is incompetent. They are padding their resume with node/angular experience at your expense. They should have a working demo after 2 months.
While I agree with your sentiment, this sentence sounds like an overgeneralization. I can't imagine it would be that easy to put together a working demo of a fantasy sport site in two months, even with the best talent.
What kills me is that this sort of mystery is not in any way necessary. The planning methods from, e.g., Extreme Programming, are 15 years old. So that nobody else has to suffer like this, here's my 30-second intro to a basic version:
Everybody sit down at a table with a large stack of index cards, all of one color that isn't white, and n+1 sharpies. Talk about the product. As you go, every time something buildable is mentioned, write it on an index card with a sharpie. 3-7 words is enough; the cards aren't documentation; they're just tokens representing conversations. Every card should create business value that is visible to all stakeholders. No "set up the IDE", no "learn node", just business value cards.
After 30-60 minutes, put the cards in strict linear order of business desire, ignoring technical dependencies. Now take a bunch of cards, write "RELEASE" on them, and insert them into the order every time something shippable is necessary, including investor demos, user tests, private betas, and the like.
Next, look at the top 10-20 cards. For each one, ask the developers if it will take a week or more. No wizardry needed, just gut-level estimates. If the answer is yes, tear up the card and replace it with cards that are all smaller than a week of effort. Congrats! Now you have a plan that is enough for developers to get started. Make a permanent home for the cards on a table or wall with three columns: backlog, working, done.
Each week on Monday morning, everybody should sit together, look at the backlog, and take an hour to discuss everything that will likely get worked on. During the week, when people start on a card, move it from "backlog" to "working". When everybody agrees that it is completely done and the business value is has been demonstrated, move it to "done". And the end of the week, sit down together again, review how it went, count the cards completed. Protip: keep the number of cards in "working" as small as possible.
After a few weeks, the business stakeholder can look at the number of cards completed each week, look at the backlog, and make reasonable guesses as to how long things will take. And after a few weeks seeing the team deliver business value each week, they'll have a good notion of how effective their team is.
There are nuances (about which I'm glad to answer questions), but that's enough to get going. I've built a number of products this way and helped others do the same. Please, founders: adopt some simple short-cycle iterative process. It's not hard, it doesn't take long, and it will save you immense trouble.
I know the basic principles of extreme programming. But I ignored it (like most hotheaded fresh young devs are wont to do) till I rediscovered it some time earlier this year. Do you have a go to book that discusses these practices? Already have a couple in my reference stack, just asking because you seem to have grasped the practice so well.
For programmers looking to learn about XP, the book that I most recommend is the first edition of Extreme Programming Explained by Kent Beck, the white one. (The second edition, the green one, was rewritten for a broader audience; also interesting, but I don't think it speaks as well to programmers.)
But the book is ancient at this point, so I'd treat it more as a point of historical interest. We've learned a lot and our technology has changed greatly, so it's not something I'd recommend implementing as written.
It's also out of date in some ways. For example, it talks about using a shared integration computer, but Git + AWS + Continuous Deployment have made that kinda ridiculous.
But what I think of it as the core of it is still quite solid. In particular, the notion of thinking of a project not as a waterfall but as a series of self-correcting feedback loops has been immensely helpful to me. What XP gets really right versus, say, Scrum, is focusing on the minute-to-minute developer experience as a driver of quality and economy. Test-driven development, pair programming, sustainable pace, collective code ownership: when pursued vigorously, these have made a huge difference for me both in terms of project outcome and personal experience.
My general tip for process change is for people to pick their biggest problem and then start solving it in a way that shortens feedback loops. So if somebody's getting lots of bugs in QA, then I'd encourage them to automate their tests so that developers get bug reports sooner. Or here, if the problem is long periods without knowing what's going on, it's breaking the work down into little chunks and delivering the next most valuable thing every few days. Humans are really good at optimizing short-feedback systems; we do a lot of it automatically.
Feel free to write me if you have particular questions; people were very generous in getting me started. I'm glad to pay it forward.
Working is an extremely relative term. When it comes to web apps, you can usually get a workable product out there though in a pretty short period of time. If you have two developers and they actually intend to make this into a business, you can most likely get something workable in a few months.
There should at the very least be something working. Making a full backend and making the frontend after that's finished is a development strategy that's certain to fail.
