How we shipped production Kotlin without a Kotlin team: ADLC in practice
Learn how JetRuby supported the evolution of a SaaS product using a structured development approach (ADLC) while maintaining system stability and delivery continuity.
Background
Our client, Sortly — a picture-driven inventory management SaaS platform — partnered with JetRuby to move into the next stage of product evolution. The platform helps teams track and organize physical assets through a simple, visual interface across a wide range of operational scenarios.
By the time we joined, Sortly already ran a mature iOS application with a Ruby on Rails backend in production. The system served a large user base and remained stable, so we had to introduce any architectural changes without breaking existing functionality.
As the product evolved, the team needed to:
- expand to a web application
- reach feature parity across platforms
- continue evolving backend logic for multiple clients
To support this direction, the team introduced Kotlin into parts of the system — mainly in mobile-related components and shared business logic aligned with Kotlin Multiplatform.
At this point, a key constraint became clear: the engineering team consisted primarily of experienced Ruby engineers. The company didn’t have a dedicated Kotlin team, and hiring specialists for a single layer didn’t fit delivery timelines.
At the same time, product development couldn’t slow down. The team had to preserve API stability and continue shipping features.
This led to a concrete challenge:
How do you ship production Kotlin in a system maintained by a Ruby team without introducing instability or delays?
The challenge
From an engineering leadership perspective, adding a new language to a production system introduces real risks.
Ruby and Kotlin rely on fundamentally different paradigms. Moving from a dynamically typed language to a statically typed one changes how engineers design, validate, and maintain systems.
In practice, three risks surfaced immediately:
- Ramp-up complexity: engineers need time to become productive outside their primary stack
- Code quality uncertainty: lack of Kotlin experience increases the risk of non-idiomatic or incorrect code
- Review limitations: reviewers lose confidence when they evaluate unfamiliar languages
The production environment amplified these risks. Sortly’s mobile apps depended on stable APIs, so even small inconsistencies could impact real users.
The team considered hiring Kotlin specialists, but that option introduced new trade-offs: longer onboarding, more coordination overhead, and no guarantee of solving the delivery constraint.
At that point, the question shifted from language choice to execution:
Can a strong engineering team reliably deliver production code in a stack they don’t specialize in?
Our approach — agentic SDLC (ADLC)
Instead of expanding the team or creating a separate Kotlin function, JetRuby treated this as a system design problem.
We redesigned the development lifecycle around an AI-assisted workflow — Agentic SDLC (ADLC). This approach reduced uncertainty and standardized execution across unfamiliar technologies.
Every task followed a consistent flow:
We didn’t replace engineering judgment. Instead, we ensured that missing stack-specific expertise wouldn’t block delivery.
Design & specification
We started each feature with a structured, language-agnostic specification.
These specs described behavior, constraints, and edge cases without tying them to implementation details. This approach prevented discrepancies between Ruby and Kotlin implementations.
The team used this specification layer as a single source of truth for implementation, review, and testing.
AI-assisted implementation
Engineers used AI tools to support Kotlin implementation, especially where paradigm differences created friction.
They worked incrementally — building models, logic, and validation step by step instead of generating large code blocks.
The team used AI to:
- translate existing business logic into Kotlin structures
- reduce boilerplate in a statically typed environment
- maintain consistent implementation patterns
Engineers kept full ownership of architecture, domain logic, and integration boundaries.
Code review
We adapted the review process to work without Kotlin specialists.
Instead of focusing on syntax fluency, reviewers relied on specifications and expected system behavior.
This allowed the team to validate:
- business logic correctness
- alignment with requirements
- consistency with system architecture
The focus shifted from how the code looks to what the system does.
Testing
The team derived test cases directly from specifications.
This ensured that implementations matched expected behavior and consistently covered edge cases.
By grounding tests in specifications, the team reduced ambiguity and aligned validation with system requirements.
Documentation
We maintained documentation alongside development.
This kept system behavior transparent across a multi-language environment and reduced reliance on implicit knowledge.
Results
By applying ADLC, JetRuby enabled a Ruby engineering team to deliver production Kotlin without hiring Kotlin specialists.
The team continued to evolve the Sortly platform while maintaining:
- production stability
- compatibility with existing iOS applications
- uninterrupted feature delivery
Instead of creating a new dependency, the team integrated Kotlin into the existing delivery flow through a structured process.
Why this matters beyond this project
This case reflects a broader trend: systems evolve faster than teams can specialize.
If companies rely only on stack-specific expertise, they create bottlenecks in hiring, scaling, and delivery.
A structured, AI-assisted lifecycle changes this dynamic. It enables teams to work across unfamiliar technologies while maintaining quality and control.
The key question shifts from:
Do we have Kotlin engineers?
to:
Do we have a system that lets engineers ship safely in any stack?
Conclusion
In the Sortly project, JetRuby showed that teams can deliver production Kotlin without a Kotlin-native team.
By applying an AI-Native SDLC (ADLC), we enabled a Ruby team to confidently operate in a new language while maintaining stability and delivery speed.
This approach doesn’t replace engineering expertise. It builds a system that manages complexity and helps teams adapt to new technologies without losing control.
If you want to explore ADLC for your product — whether it’s a stack challenge or a team scaling problem — let’s talk.
