Java Development
Java development at OMAV means Spring Boot services and REST APIs delivered with tests, version control, CI configuration and API documentation as part of the deliverable rather than as options that can be declined to make a quote look smaller.
Services someone else could maintain
Java is the language most of the enterprise back ends we are asked to build or rescue are written in. The work is rarely technically novel; what separates a good outcome from an expensive one is whether the result can be handed to somebody else without a three-week archaeology exercise.
That is why tests, CI configuration and API documentation are part of the deliverable rather than line items. A service without tests is not finished, so it is not something you should be invited to decline. The same applies to the pipeline that builds it and the documentation that describes its interface.
The acceptance test we hold ourselves to at handover is whether another team could pick the work up without calling us. We build toward that test from the first commit, in your repository.
What a Java engagement covers
Six workstreams. None of them is optional.
Service and API development
Spring Boot services and REST APIs designed contract-first, so that consumers can build against the interface before the implementation is complete.
Data persistence
Schema designed and reviewed rather than generated by default, with Spring Data JPA used deliberately and native queries where the ORM is the wrong tool.
Tests as deliverable
Unit tests for logic and integration tests for the paths that carry money, stock or identity, run in the pipeline rather than on somebody’s machine.
CI and release
A pipeline that builds, tests and packages, with environment configuration externalised and release notes produced as part of the process.
API documentation
Generated from the code and kept current by the build, because hand-maintained API documentation is accurate only on the day it is written.
Handover
A walkthrough with whoever will maintain the service, plus the operational notes covering what fails and what to do about it.
How a Java engagement runs
Define contracts
API contracts and data model agreed before implementation, so consumers are not blocked and the interface is not discovered late.
Build a thin slice
One end-to-end path built first — request through to persistence and back — including its tests and pipeline, to prove the architecture.
Deliver in pieces
Remaining functionality delivered in increments, each ending with something runnable in an environment you can reach.
Harden
Failure handling, logging, timeouts and retries addressed deliberately rather than added after the first production incident.
Hand over
Documentation, operational notes and a walkthrough, judged against whether another team could take it on unaided.
Engagement shapes for development work
How to buy Java development, and when each shape fits.
| Dimension | Fixed-scope build | Embedded developers | Managed support |
|---|---|---|---|
| Delivery direction | OMAV | You | OMAV |
| Suits | A definable system | Ongoing capacity | A live application |
| Priced as | Fixed fee per stage | Day rate, monthly | Monthly retainer |
| Acceptance | Criteria per deliverable | Monthly review | Service levels |
| Code ownership | Yours throughout | Yours throughout | Yours throughout |
| Wrong when | Requirements shift weekly | You need an outcome by a date | Project work is hidden in it |
What we will not do
We will not quote a build without tests to reach a lower number. It is possible to deliver working software faster by omitting them, and the cost arrives later as a codebase nobody will change confidently. Where budget is genuinely the constraint, the honest response is a smaller scope, not a less rigorous one.
We also will not recommend a stack your team cannot maintain. That constraint eliminates more options than any technical comparison, and it is the right constraint. A well-argued choice your developers cannot support after we leave is a worse outcome than a conventional one they can.
- Tests, CI and API documentation are deliverables, not upsells.
- You own the code in your repository from the first commit.
- Build one end-to-end slice before scaling out the rest.
- The handover test is whether another team could continue without us.
Questions buyers ask about this
Are tests really included in the price?
Yes. A service without tests is not finished, so it is not something we present as optional. Excluding them would produce a lower quote and a worse asset, and it moves the cost to whoever maintains the code next — usually you.
Who owns the code?
You do, in your repository, from the first commit. There is no transfer at the end because there was never a period when it lived somewhere else. Handover is a walkthrough and documentation rather than a delivery of files.
Can you work inside our existing codebase and standards?
Yes. We adopt your review process, branching model and definition of done. Where we would diverge from your standards we say so and explain why rather than quietly working differently, and you decide.
What Java version and frameworks do you use?
Java 17 or later with Spring Boot for most work, Spring Data JPA for persistence, and Maven or Gradle depending on what you already run. Where you are on an older version we will tell you what upgrading buys and what it costs, and treat that as a separate decision.
Do you provide support after launch?
Yes, either as managed support with severity levels and a written support-versus-change boundary, or as embedded capacity if you would rather hold delivery direction yourself. We will recommend whichever fits how the work actually behaves after go-live.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.