Want to ship a product fast and get to revenue? Don’t start with microservices. You’ll get to them eventually, but almost never on day one.
That’s not microservices being wrong. It’s how most successful systems actually evolve. You start with a monolith. One codebase, one deploy, and it does the whole job. The product ships, the business earns, and the system stays stable. That stage can run for years, and for a lot of teams it should.
Then you grow. Traffic climbs, the team splits into squads, and you start hitting ceilings — usually on scaling and release speed. That’s when you begin pulling the heavy parts out of the monolith one at a time and moving them to services that scale on their own. Almost nobody rewrites the whole thing at once and lives to tell the tale.
So the decision isn’t philosophical. It depends on where your system sits in that arc and what it needs next. Below I’ll go through the trade-offs on both sides, then a payments platform we helped move across.
What we’re actually comparing
You know what a monolith and microservices are. The useful question is what each one does to your deployments, your data, and your teams. Here’s the short version, with a cross-border payments platform as the running example, since that’s where the trade-offs bite hardest.
The monolith
One codebase, deployed as a single unit. Take a payments platform: the API layer, the ledger, compliance and sanctions screening, FX quoting, and the payout connectors for each corridor all live in the same application and share a database. A “send money” request runs through all of them in one process.
The upside is coherence. One transaction wraps the whole flow, so your ledger and your payment state stay consistent by default. The catch: to add one new payout corridor, you touch the shared codebase and redeploy everything, including the ledger and screening code that didn’t change.
Microservices
The same platform, split into separate services: orchestration, ledger, screening, FX, and each corridor as its own service, each with its own datastore, all talking over APIs. Now a new corridor is a new service you build and deploy on its own, without redeploying the ledger.
The cost shows up in the data. A single payment now crosses several services, so you can’t lean on one database transaction to keep it consistent. You coordinate with sagas, accept eventual consistency, and design for the case where screening succeeds but the payout call times out. In exchange, one degraded service no longer takes the whole platform down: if FX quoting slows, payments that are already priced can still settle.
That’s the trade in one picture. The monolith gives you simplicity and strong consistency. Microservices give you independent scaling and deployment, and hand you a distributed-systems problem in return.
Pros and cons of a monolith
Where a monolith wins
- One deploy, one mental model. A small team moves fast when there’s a single build, a single artifact, and no service mesh to reason about.
- Strong consistency for free. State changes happen in one database transaction. For anything money-related, that’s a real advantage: no sagas, no reconciliation work to keep two services in agreement.
- Cheap to trace. A bug lives in one process. You can follow a request end to end in a debugger, not across five services and a message bus.
- Lower latency. Calls between modules are in-process, not over the network. No serialization, no extra hops.
- Cheaper to start and run. Fewer moving parts means lower infra spend and lower cognitive load. That math flips once you need to scale one hot path on its own, but early on the monolith wins on cost.
Where a monolith hurts
- Everything scales together. If one endpoint is the hot path, you still scale the whole app, idle modules included. You pay for capacity you don’t use.
- Release coupling. Every team ships through the same pipeline. One risky change can block or break everyone’s release, and deploy cadence drops as the team grows.
- Debt compounds. Without hard module boundaries, code reaches across concerns until a small change ripples in ways nobody predicts. The bigger the codebase, the slower it gets to change.
- Blast radius is the whole system. A memory leak or a bad deploy in one corner can take the entire app down, not just one feature.
- One stack, effectively forever. Everyone shares a language and framework. Adopting something new for one problem usually means fighting the whole codebase instead of adding a service.
Where microservices help, and where they bite
The upside
Independent deployment. Each service ships on its own cadence. A corridor team can release ten times a day without waiting on the ledger team.
Targeted scaling. Scale the service under load and leave the rest alone. You spend compute where the traffic actually is.
Fault isolation. A failure is contained to one service and its dependents. Done well, the platform degrades instead of falling over.
Tech per job. Teams can pick the right language, framework, or datastore for their service instead of the org-wide default.
Team autonomy. Small teams own their service end to end and ship without a company-wide release train. This is also how you keep delivery speed roughly flat as headcount grows.
The bite
You inherit a distributed system. The hard problems move from writing correct code to coordinating correct behavior across the network. Retries, timeouts, idempotency, and partial failure become your daily reality, not edge cases.
Data consistency gets expensive. No more single transaction across the whole flow. You reach for sagas and the outbox pattern, accept eventual consistency, and design every workflow assuming any step can fail halfway. In payments, that isn’t detail work. It’s the core of the system.
Observability is a prerequisite, not a nice-to-have. Debugging a request that touched five services needs distributed tracing, correlation IDs, and centralized logs from day one. Without them you’re flying blind.
Operational load multiplies. More services means more pipelines and dashboards to run, and more on-call surface to cover. You don’t get microservices without real DevOps and platform investment behind them.
Conway’s law is real. Service boundaries end up mirroring team boundaries. If the org isn’t set up to own services independently, the architecture won’t deliver the autonomy you paid for.
The usual path for a growing product
Back to that arc, because it’s where the expensive mistakes happen.
Most teams don’t need microservices at the start, and many reach for them far too early. On day one a monolith is faster to build, cheaper to run, and easier to change. It carries the product while the business finds its footing. Splitting into services before you have scaling or team-scaling pressure just buys you a distributed system you have to operate for no payoff yet.
There’s also a middle option people skip: a modular monolith. One deployable, but with strict internal module boundaries and clean interfaces between them. You keep the operational simplicity while making the eventual split much cheaper, because the seams are already cut.
When the switch does make sense, do it incrementally. Find the bottleneck, the module that can’t keep up with load or has become a release chokepoint, carve it out, and replace it with a service that scales on its own. Then the next one. Over time the monolith shrinks and the heavy paths move to purpose-built services. The pattern even has a name, the strangler fig, where new services gradually take over from the old system instead of a big-bang rewrite that stalls for a year.
One more thing worth naming: the monolith’s real ceiling is scaling, and it tends to stay cloud-agnostic, which is convenient. But past a certain size it gets genuinely hard to maintain, and that maintenance drag is usually what forces the decision.
One more factor: building with AI
There’s a variable in this decision that barely existed a few years ago. If you’re building with coding agents and working spec-driven, your architecture shapes how well an LLM can actually operate in your codebase.
A monolith helps here: everything sits in one place. The code, the specs, the requirements, and the architecture notes are co-located, so an agent can follow how one part talks to another without you assembling that context by hand. Change a module and the agent can see what it affects.
Microservices scatter that context. Each service has its own repo, its own contract, its own spec. For an agent to reason across them, you have to keep every service’s spec, its interface contract, and its architecture decisions current and discoverable in one place. Let that map drift and the model loses the seams between services, which is exactly where distributed systems break. Maintaining it is real, ongoing work.
There’s a catch on the other side, though, and it’s worth being straight about. A large monolith is itself a huge scope. Past a certain size it won’t fit in an agent’s context window any better than a pile of services will. Microservices are naturally bounded: one service is small enough to hold in full, with a clean contract at its edge. So the monolith isn’t automatically the easy choice for AI work. You’re trading co-located context against bounded context, and each one buys you something.
The real lever here is spec discipline, more than the architecture itself. Whichever way you go, what makes an agent effective is keeping your specs, contracts, and architecture decisions written down and current, in a place that’s easy to find. Get that right and a modular monolith is close to ideal for AI-assisted work: everything in one place, with clean module boundaries the agent can respect. Get it wrong and no architecture will save you.
When to use which
Reach for a monolith (or a modular monolith) when:
You’re early. Small team, no scaling pressure yet, speed to market matters more than independent deployability. You can restructure later when you have the resources and the reasons.
You’re validating. For an MVP or proof of concept, a monolith gets you to a testable product with far less overhead.
The domain is contained. If the system doesn’t have many independent scaling profiles or teams, microservices mostly add cost.
Reach for microservices when:
Scaling profiles diverge. Different parts of the system need very different amounts of compute, and scaling them together is wasteful.
Multiple teams need to ship in parallel. Independent deployment is the real prize here. A new team can own one service, learn its surface in a day, and release without coordinating a platform-wide train.
The monolith has become the bottleneck. Release cadence is dropping, debugging is slow, and small changes ripple. That’s the signal to start carving. Our WorldRemit work is a clear example of that move.
FreySoft case: WorldRemit
WorldRemit is a large fintech company. They were rebuilding a monolithic project into microservices and adding new payment methods at the same time. Years of fast growth had left them with two problems:
- the existing architecture was hitting its limits,
- they didn’t have enough operational capacity to support new integrations.
What we did
WorldRemit needed engineering hands to move fast: replace existing payment methods with Optile-based equivalents, and add new payment methods to keep expanding worldwide. Bringing in skilled FreySoft teams to build, test, support, and customize each new method independently turned out to be an effective way to get there.
Our service integration work covered:
- gathering all the required documentation
- closing the technical gaps for integration (TLS/MTLS connections, authentication, mandatory fields, and so on)
- building the service
- testing it in the test environment
- setting it up in the microservices architecture
- supporting the go-live step
To reach WorldRemit’s goals, the QA team:
- built high-load, scalable services (more than five of them)
- kept the code structure flexible to make maintenance easier
- added several layers of manual and automated tests, reaching test coverage above 85% and keeping major and critical bugs out of production
- set up two levels of monitoring so QA could react fast to any issue in any environment
- gave the business responsive support while it opened new markets
The result
The product now runs with high performance and stays reliable and stable for customers around the world. The project also cleared out the architectural tech debt. Without that, onboarding new payment methods and providers would have stayed nearly impossible.
Our DevOps team improved security, shut down several Azure services, and updated the automation. We reached new standards for building the features the client needed, and adding new payment methods and providers got much easier and far less error-prone.
For the business, it means lower costs and room to expand into new markets. Today the platform serves thousands of users, and customer satisfaction is up.
So, monolith or microservices?
There’s no universal answer. It comes down to your scaling profile, your team topology, and how many external systems you have to integrate. But a working rule: if you’re not facing heavy load or a constant stream of new integrations (payment rails, banks, external storage, and the like), stay on a monolith and keep it modular. Once the system has to absorb serious load and coordinate many services, you’re into microservices territory, with the operational cost that comes with it.
If you’re already on a monolith, the signals to start splitting are concrete:
- a new feature costs more than the value it returns, because the codebase fights you;
- you want to work on one component in isolation instead of redeploying the whole platform;
- teams have grown to the point where shared ownership of one codebase slows everyone down. On large systems, org boundaries force architectural ones sooner or later, and services make that split livable.
And the part that outweighs the diagram: architecture doesn’t rescue a project on its own. Team quality, how well people coordinate, and how closely they work with the domain experts decide the outcome long before monolith-versus-microservices does. We’ve watched clean architectures fail on weak teams, and messy ones ship on strong ones.
We’ve spent years in exactly this space, mostly in regulated fintech and payments. We look hard at the scaling profile, the release constraints, the team setup, and the number of external systems in play, then pick the architecture that fits the project in front of us rather than the one that’s fashionable. Want to pressure-test your own decision? Contact us and we’ll dig into it with you.
