Using a Familiar Stack for a Critical Backend Workflow

On a mission-critical platform at Softcraft, we needed to add a new backend capability around an existing business workflow. The problem could have justified several interesting technologies. We had data to persist, work to process, and a need to support future growth. We chose tools the team already knew well: Java, Spring Boot, and PostgreSQL, integrated with the platform’s existing operational model. The stack wasn’t new or exciting. But we knew how to explain it, deploy it, monitor it and support it. For this workflow, that was more important.

The Cost After Development

The initial implementation is only one part of the cost. Every new database, message system, framework, or runtime needs a deployment path. It needs monitoring, access control, backups or recovery, security updates, and people who know what to do when it behaves unexpectedly. That operational work is easy to underestimate during design because it doesn’t appear in the feature requirements. The new capability was important, but it didn’t have a requirement that our existing stack couldn’t meet. Introducing another major component would have increased the number of things the team needed to operate without removing equivalent complexity from the business problem. For this case, the extra operational cost wasn’t worth it.

Using a Familiar Stack

Choosing established technology shouldn’t mean copying the same architecture without thinking. We still needed to design clear boundaries, understand how the application accessed data, plan for failure, and measure behavior under expected load. PostgreSQL being familiar didn’t automatically make every query efficient. Spring Boot being mature didn’t decide where business logic belonged. The advantage was that the team could spend more attention on those questions. We weren’t learning the basic operating characteristics of a new platform while also trying to deliver a critical workflow. Familiar tools reduced some uncertainty, but we still had to do the engineering work.

Adding a New Tool

I enjoy learning new technology, and there are good reasons to introduce it into production. An existing tool may not meet a real performance, reliability, or product requirement. A new platform may remove significant manual work or provide a capability that would be costly to build ourselves. Teams also need to evolve rather than freeze their stack forever. But “this looks cleaner in an example project” isn’t enough for a production system. I want the benefit to be specific. Which constraint does the technology solve? What existing complexity does it replace? How will we operate it? What happens if the people who introduced it aren’t available a year later? If those questions have strong answers, the new technology may be the responsible choice. If they don’t, we may be adding one more thing for the team to support without a clear benefit. For the team, a predictable stack made code reviews easier and production support faster. Engineers knew where to look when something failed. Existing CI/CD, observability, and security practices continued to apply.

For the business, the familiar stack meant less delivery risk. For us, it meant the same deployment, monitoring and security practices continued to work, and engineers already knew where to look when something failed. I still enjoy trying new technology and there are projects where a new tool is worth its cost. This particular capability didn’t need one. Java, Spring Boot and PostgreSQL did the job without giving the team another platform to explain during an incident or update a year later.