Palladium / EXISTING RAILS APPLICATION DEVELOPMENT
A new API. An existing portal that keeps working
Built an API and backoffice for a new portal without disrupting the old one. Reused and refactored the existing backend, protected data integrity and unblocked delivery across teams.
THE EXISTING PRODUCT
Public API development for Palladium
Palladium needed an API for a new portal being built by another team. The existing portal had to keep working as before. We delivered the API and backoffice, improved the backend code used by both portals and prevented data integrity issues during the changes.
Extend the Rails application your business already depends on. Reusing and improving the existing backend helped deliver a new portal without an unnecessary rewrite or disruption to the old one.
THE BUSINESS CHALLENGE
GraphQL API development & technical leadership
We implemented a GraphQL API for a stack using Ruby on Rails, PostgreSQL and Next.js.
Instead of implementing the same business behavior twice, we reused code from the existing portal's backend. That meant changes made for the API also affected code the old portal depended on. We made local refactoring changes to support both interfaces, stabilize the existing system and keep their data consistent.
- Ruby on Rails
- PostgreSQL
- Next.js
- GraphQL
The API was consumed by a third-party team. Our work also depended on a service that team was responsible for, creating a circular dependency: we needed their integration to finish parts of our implementation, while the teams' work depended on each other. Waiting would have held up both the API and the backoffice. At the same time, existing users still needed the old portal to function normally.
THE WORK WE DELIVERED
Improve the product. Keep the business moving
- 01
Deliver the API and backoffice
We built the new API with GraphQL and introduced a service adapter so our implementation could proceed independently of the unavailable external integration. It provided the behavior our side needed while the other team continued its work. This removed the immediate blocker and let us build the API and backoffice without waiting for that service to be ready.
- 02
Refactor the shared Rails backend
In parallel, we refactored the specific backend code that the new API reused. We kept the existing portal's behavior intact, stabilized the affected functionality and addressed data integrity risks rather than carrying them into the new interface. We coordinated the API work with the third-party team throughout delivery.
VALUE FOR THE BUSINESS
Public API development for Palladium: the results
The new API and backoffice were completed despite the cross-team dependency. The old portal continued working without disruption. The shared backend was improved through local refactoring, the existing system was stabilized and data integrity issues were prevented. The service adapter gave our team a way to continue delivery instead of letting another team's unfinished integration stop the project.
WE TAKE OWNERSHIP OF EXISTING RUBY ON RAILS APPLICATIONS
Need technical ownership for your existing Rails app?
Need someone to take over your Rails app? We maintain, stabilize and improve existing Rails applications, from production issues and upgrades to new features and infrastructure. Keep your product moving without unnecessary rewrites or rebuilding your engineering team.
Looking for a fractional CTO for Rails? Discuss the technical direction, cross-team coordination, and ongoing ownership your application needs.
Discuss your Rails app Fractional CTO and technical leadership →Meet our Rails engineering team →Explore existing Rails app takeover