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.

Palladium: Public API development for Palladium
ClientPalladium
Work deliveredAPI Development & Solutions Architecture
Business resultDelivered · API & backoffice

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.

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
What needed to change

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.

API Development & Solutions Architecture for Palladium

Improve the product. Keep the business moving

  1. 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.

  2. 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.

Palladium: delivered api development & solutions architecture

Public API development for Palladium: the results

API & backofficeDelivered
Existing systemStabilized
Data integrityProtected

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.

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
Back to TopBack to Top