Enterprise systems on Java and Spring Boot

Yes, and it’s a significant part of what we do. The first step is a short paid audit: we read the code, run the build, look at the database and at how deployment works. Then you get a list of risks and an order of intervention. We don’t propose a rewrite from scratch unless it is demonstrably cheaper than the repair.

For business systems with complex logic, transactions and a long life, Java has concrete advantages: strong typing, serious profiling tools, a stable ecosystem, developer availability. For a small API or something tightly coupled to the frontend, Node.js is often faster to ship — and we use it there. We make the choice per case, not by preference.

By default: a well-structured modular monolith with clear boundaries between modules. We move to microservices when there is a real reason — separate teams shipping independently, components with very different scaling profiles, or isolation requirements. Microservices move complexity from the code into the infrastructure; if you don’t need that move, you’re paying for nothing.

Architecture documentation, important decisions written down with the reasoning behind them (ADRs), a README that works on a clean machine, and recorded handover sessions. We write the code from the start assuming somebody else will take it over.

Yes. We can join an existing team on sprints, with code review and an agreed quality standard, or we can take one module end to end. Both work; the second gives more predictable results.