We build software you can own
Readable architecture, trustworthy tests, an operable pipeline, and documentation that is generated rather than rotted. We pair with your people and make the handover explicit.
Custom Software Development
Your team is at capacity. A consequential roadmap item is slipping, a previous delivery left unclear ownership or operating gaps, or a legacy system needs incremental change. We build with your team in Java and Spring, with an explicit path to operation and handover.
Scoped per engagement – fixed-price discovery first, then delivery in increments.
The problem we are usually called about
You need additional delivery capacity without creating a long-term dependency or a second operating model.
-
The roadmap is slipping
Your internal team is at capacity and an important product or platform cannot move. You need experienced hands who can contribute without creating another management layer.
-
Ownership and operating gaps remain
The software works, but architecture decisions, tests, operational knowledge, or responsibilities are unclear. We make those gaps visible and address them with your team.
-
The legacy system is the constraint
The business needs change, but a big-bang rewrite would put years of knowledge and revenue at risk. We can use a strangler-fig approach and replace capability by capability.
-
The prototype became production
An idea needs to become a working product with a real architecture, not a prototype that becomes production by accident. We establish the foundations before scale makes them hard to change.
If the existing system is the main problem, an architecture review is often the sensible first step.
What we build
Custom applications in the JVM and Spring ecosystem. We choose boundaries, tools, and deployment models from the product and operating constraints, and stay within the areas where we have relevant expertise.
-
Backends and APIs
Spring Boot services, secure APIs, domain logic, and integrations that fit the way your organisation already builds and operates software.
-
Modular monoliths
Well-bounded applications with Spring Modulith and domain-driven design. A modular monolith is often the better starting point than a distributed system you cannot yet operate.
-
Event-driven systems
Events, messaging, and integration boundaries for workflows that need resilience and loose coupling without hiding the business model behind infrastructure.
-
Legacy modernisation
Incremental replacement around the existing system, including a strangler-fig approach where it is safer than a rewrite. The old system stays useful while the new one earns its place.
-
Agentic workflows in products
Applications with agentic AI workflows embedded in the product, with evaluation, guardrails, and operational controls. See our agentic AI engineering service.
-
Delivery foundations
CI/CD, Cloud Native Buildpacks, GraalVM native images where they make sense, and observability with Actuator, Micrometer, and OpenTelemetry. PostgreSQL, containers, and Kubernetes are deployment context, not architecture by themselves.
How the engagement runs
A low-commitment start and working software early. You can stop after discovery with something useful in hand, or continue while your people learn the system.
-
Fixed-price discovery
We understand the domain, constraints, existing estate, and what done means. The output is a plan and an estimate that can support an internal or external delivery decision.
-
Walking skeleton
We put a thin end-to-end slice into production-like infrastructure early. The build, deployment path, boundaries, and first operational signals become real before the scope grows.
-
Incremental delivery
We deliver and review working increments throughout. Your people are involved, decisions stay visible, and the architecture evolves from evidence rather than a distant design exercise.
-
Handover
Your team receives the application, pipeline, documentation, and operational context agreed for handover. We reduce our involvement as your people take over.
What you get
Software your organisation can read, change, operate, and continue without us.
- An architecture your team can understand, with domain boundaries that have a reason
- Working application code with tests you can trust and a test-driven development habit
- A CI/CD pipeline your team can operate, with reproducible builds and deployment
- Documentation that is generated where possible rather than left to rot
- Production-like infrastructure and observability from early in the build
- A clear modernisation path, including a strangler-fig option where appropriate
- Knowledge transferred through pairing, reviews, and deliberate handover
- Explicit ownership and licence terms, documented dependencies, and a planned handover
If you want to strengthen your own team instead of asking us to build the whole application, consider developer coaching or our Spring Modulith training.
Who this is for
-
CTOs and engineering managers with a JVM estate
You run Java and Spring in production, have a consequential roadmap item, and need a build partner who understands enterprise constraints and can work within your operating model.
-
Teams modernising a legacy system
You need to reduce risk and increase delivery speed without throwing away the domain knowledge inside the existing application.
-
Product teams with a real idea
You have a business problem worth solving and need a production-capable first version, not a prototype that someone quietly promotes into a critical system.
-
Teams that want to own the result
You are willing to be involved. You want the architecture, code, and operational knowledge to stay with your people after the engagement ends.
Why us
We are a small team of experienced practitioners. Patrick Baumgartner leads the work, backed by the core team and trusted specialists when a specific need calls for them.
We know Spring in production
Spring Boot, Spring Modulith, domain-driven design, test-driven development, and the operational details around them are our daily technical context.
We teach what we use
Patrick is a ZHAW lecturer and a member of the JUG Switzerland board. We also deliver workshops and training, so the reasoning behind the code is part of the handover.
Relevant credentials and experience
Java Champion, Oracle ACE, Microsoft MVP, VMware Certified Spring Instructor, and Spring Certified Professional. More than 20 years of experience, 70+ conference talks, and 200+ workshops delivered.
Meet the people behind the work on our company page, or compare this build option with our other services.
Frequently Asked Questions
Do you work with our in-house team or replace it?
We work with your in-house team. We pair with your people, involve them throughout delivery, and provide the code, documentation, and operational context agreed for handover.
What technologies do you use?
Java and Spring are our primary area: Spring Boot, Spring Modulith, PostgreSQL, containers, Kubernetes, and the surrounding delivery tooling. For work outside that expertise, we clarify the boundary early and involve a suitable specialist where appropriate.
Do you do fixed-price projects?
We use a fixed-price discovery to understand the domain and constraints. We then define scope, commercial terms, and acceptance criteria for delivery in increments.
Who owns the code and intellectual property?
Ownership and licence terms are agreed in the contract before delivery begins. We favour working in repositories and delivery systems you control, document third-party dependencies, and make handover an explicit part of the engagement.
What happens after launch?
We complete a deliberate handover and reduce our involvement as your team takes over. Optional support can be agreed where useful, while the delivery approach gives your team the code, documentation, and operational context it needs.
How do we start?
Start with a 30-minute call about the problem, your team, and your constraints. If there is a fit, we propose a fixed-price discovery with a plan and estimate that can support an internal or external delivery decision.
Turn the roadmap item into a delivery plan
Book 30 minutes with Patrick. Bring the problem, the constraints, and any lessons from previous attempts. We will assess whether we are the right build partner and explain what a discovery would cover.