A system can be small and still be difficult to change. The usual cause is not a lack of services, but a lack of clear responsibilities. When every module can reach into every other module, even a simple change becomes a coordination problem.
Begin by making boundaries explicit. Decide which part owns a business rule, which part owns its data, and what other parts are allowed to ask of it. A documented interface is often more valuable than a new deployment unit.
Scale the parts that need to scale. Keep the rest simple. Architecture should follow the pressures the system actually experiences, with decisions that another engineer can understand and revisit.