One thing you deploy
A monolith is one thing you deploy.
All of your code, checkout and search and billing and admin, builds into a single artifact that ships as a unit and usually talks to one database. When checkout needs inventory data it makes a function call, not a network call, and that single fact drives everything good and bad about the shape.
Count the good, because it is enormous and routinely undersold. A function call takes nanoseconds and cannot time out. One transaction wraps your order insert and your inventory decrement in a single atomic commit, with no choreography required.
Debug from one stack trace. Develop in one process. Refactor across module boundaries with an editor rename rather than a cross-team API negotiation. For five to thirty engineers this is close to the fastest way to ship software.
The pain arrives with head count
Expect the pain to arrive with head count rather than with traffic. When forty engineers push to one repository, your deploy queue becomes the bottleneck, one team's flaky test blocks everybody's release, and a bad migration from the analytics team takes down checkout.
Scaling goes all or nothing too. If image processing needs ten times the processor of everything else, you still scale the whole artifact, paying for forty copies of code that mostly idles.
Do not read any of that as an expiry date. A well-factored monolith with clear boundaries inside it keeps most of the benefits far longer than the conference talks suggest, and some of the largest codebases on earth run Black Friday this way.
Treat it as the thing you keep until a specific measurable problem forces the split, not the thing you graduate from.
Worked example
In 2016, Priyanka joins a 12-person startup running a Django monolith: one repo, one relational database, deploys in 8 minutes. A consultant pitches microservices, and the team spends a quarter splitting out a users service and an orders service. Now creating an order means two network calls, auth tokens between services, and a bug where an order commits but the user's order count doesn't. Feature velocity drops by roughly half; the two services still deploy together anyway because their APIs change in lockstep. After six months they fold both back into the monolith, add clear module boundaries and a CODEOWNERS file, and deploys go back to boring. The distributed version solved a team-scaling problem the 12-person team simply did not have.