Spring GDS 25th Anniversary
A logistics company that ships to 190 countries built something to ship to itself.
Monolith
What is a monolith?
A monolith is an application built and deployed as a single unit. The user interface, the business logic, and the data access all live in one codebase, compile together, and ship together. When you deploy, you deploy the whole thing. For most of software history this was simply how applications were built, and for a great many projects it is still the right call.
The usual point of comparison is microservices, where an application is split into many small services that run and deploy independently. The monolith keeps everything in one place, which makes it easier to develop early on, simpler to test end to end, and faster to reason about because there is no network hopping between parts. The cost is that it grows heavier over time. A small change means redeploying the whole application, and one team's work can collide with another's in the same codebase. A startup shipping its first product almost always benefits from a monolith, then revisits the question once scale and team size make the single unit start to creak.
The honest framing is that "monolith" is not a slur and "microservices" is not a trophy. Microservices solve real scaling and organizational problems but add operational complexity that small teams pay for without getting the benefit. Many companies that rushed to split things up have since pulled work back into a well-organized monolith. The architecture should match the size of the problem, not the size of the ambition.
Monoliths at Dallonses
We start most products as a monolith, and we say so plainly even when a client arrives asking for microservices. A clean, modular monolith ships faster, costs less to run, and is far easier to change while the product is still finding its shape. We have taken over more than one project where premature splitting left a small team drowning in infrastructure, and the fix was to consolidate, not fragment further.
When scale or team structure genuinely calls for it, we split deliberately, pulling out the pieces that need to scale or deploy on their own rather than rewriting everything at once. The custom web applications we build are architected so that boundary can be drawn later without a teardown. We make the call on evidence, with the client, and we are comfortable recommending the boring answer when it is the correct one.
Unsure whether to start monolith or split it up? Let's size the problem first.
Related services
Related works
Vizitio
Turning a brand into a working business.
Access Ticket
Half a million people. One app. Zero chaos.
Ready to work together?
Book a meeting
