Mirtilo IO / Services
Software engineering, with proof behind the decisions
Evidence-led support for architecture, backend delivery, quality and release.
Three connected forms of work
Mirtilo IO focuses on three connected forms of software engineering. The public products in the portfolio show how I turn constraints into architecture, code, tests and release evidence. Client work is described separately and only at a level that respects confidentiality.
01. Architecture and modernisation
When a system is difficult to explain or change, I map the important paths, clarify boundaries, compare viable options and turn trade-offs into decisions the team can use.
This is useful for backend systems, service boundaries, enterprise Java, integrations, event-driven architecture and incremental replacement of legacy components. The goal is a route forward that can be understood, tested and changed one slice at a time.
02. Software delivery
When a technical decision needs to become working software, I design, build and test a defined backend or product slice through to a maintainable handover.
The public evidence includes a Rails application shell, TypeScript browser applications, APIs and integration boundaries. My broader experience includes Java 8–21, Jakarta EE, Quarkus, Payara, MicroProfile, REST APIs, Angular and messaging systems. The work stays close to the code, the tests and the decisions that make the implementation maintainable.
03. Quality and release
Quality is part of delivery, not a final inspection. I help make CI/CD, automated tests, accessibility, security boundaries, documentation, artifact checks and release decisions visible and repeatable.
The public projects show this at small-product scale: explicit contracts, privacy boundaries, browser checks, production builds and documented deployment paths. They are evidence of engineering practice, not a claim of high-scale incident history or advanced observability without project-specific proof.
What the public work proves
Formatloom and Max Bid are public product evidence. They show requirements, constraints, implementation choices, tests and release work. They do not pretend to be client testimonials, revenue results or a substitute for confidential production history.
How a defined piece of work moves
- Frame the problem, constraints and useful outcome.
- Make options, risks and boundaries explicit.
- Build and test the smallest useful slice.
- Leave release evidence, documentation and a maintainable next step.