In the Notes example, the whole kitchen sink is rolled into a single project. Is there any wisdom to breaking it into 2 separate projects. One for the API and Data and another for the front end React app? I can see where I might ultimately have multiple front end apps all talking to the same API. Also, I have development teams that are very focused on backend and database and others that are all about the front end. Separation of concerns seems wise to me. Thoughts?

I documented my thoughts on this here: https://github.com/serverless-stack/serverless-stack/tree/master/examples/typescript-monorepo

Hmm. You've clearly put a lot of thought into this. Doesn't fit with my narrative/thought process above, and that's ok. You make very good points in here. Now I'm torn. For example, our initial very small project will fit this nicely. That is, until we move to step 2 where we build an iPhone app. Clearly, that's a different animal. But, it will need to talk to the API. Or, at the very least, it will need to talk to an API that points to the common database (Dynamo, MySQL, etc)

Cool! And yeah there's a lot of ways to go with this. I can see why monorepos are trickier with native apps. I'd probably still try to do it personally though and separate once clear painpoints show up

I think the more important thing is to split Stacks as opposed to projects. I would definitely set everything up across Stacks so they could be easily moved to another project however (like say, using SSM and

.fromArn

instead of handing in props). This means you can always change your mind, and decreases coupling for almost no cost. I would say the single vs multi project argument is the same as Monolith vs Microservices, its about scale.