Tight vs loose coupling is not a new concept. You can write a monolith with bounded-context components which are loosely coupled to each other with an eye towards possibly putting those bounded contexts in different containers in the future.
Unfortunately, this requires an actual architect to think about the design of the monolith ahead of time, and most startups either have trouble recruiting anyone above the junior level, confuse the responsibilities of the project manager (who, in the early days, is typically the CEO/CTO) with the responsibilities of the architect, or simply cannot afford to put an architect on payroll.
I think there is a middle ground. Especially if you can start writing common libraries for the other components to use.