Microservices means splitting a system into small pieces that can be shipped on their own. Billing is one service. Inventory is another. Identity is a third. They talk to each other over APIs. A team can change billing without redeploying the whole product. At a large company, with many teams and real traffic, that independence is worth the cost. At the start of a business system, it usually is not.
You pay the coordination before you have the traffic
Each small service needs a way to be deployed, logged, secured, and called when the one next to it is down. A single well-structured application needs those things once. A dozen services need them a dozen times, plus a story about what happens when inventory says yes and billing says no. That story is harder than the original screen. Firms buy the hardness on day one because a diagram of boxes looks modern, then spend the year keeping the boxes alive instead of finishing the job the user opened the laptop for.
The calls between those boxes are still just APIs. You can have a clear API inside one application. You do not earn a clearer API by cutting the application into pieces before anyone is using it.
A modular application is not a failure of ambition
Put the boundaries in the code. Billing does not reach into inventory's tables. Identity is a module with a door. You deploy it as one system until a real pressure shows up: a team that must release on a different day, or a part that must scale because it is genuinely hotter than the rest. Then you split that part. You will know which part, because you will have felt the pain. Guessing it in a proposal is how you staff a platform team for a product that does not have users yet.
When it matters on a project
It matters when you already run a live system and the release train is the bottleneck, or when one capability has load the rest does not. It does not matter as the opening architecture of a portal, an ERP slice, or a first integration with Tally. If a proposal leads with microservices and you do not yet have a live product, ask what problem the split solves this year. If the answer is "best practice", you are paying for someone else's scale.
We would rather build one .NET application with sharp internal doors, and split later if the doors are no longer enough. The first release should be something a person can log into on Monday. A cluster of empty services is not that.