Comparing Ruby on Rails agencies for UK businesses with existing software

Disclosure: this comparison is written by Bit Zesty, and includes our own services. It is not an independent ranking. We checked the linked agency descriptions on 23 September 2026 and present the agencies alphabetically.

Your Rails application already takes orders, coordinates work or serves customers. Perhaps its original developer has left. Perhaps your internal team knows what needs doing but cannot fit an upgrade around the roadmap. Choosing the next agency means deciding who can take responsibility for that situation.

This comparison looks at Bit Zesty, Foxsoft, Planet Argon, thoughtbot and Unboxed. Each publishes relevant Rails services and serves, or explicitly invites work from, UK businesses. The selection is not exhaustive. Their websites establish what they offer; an actual proposal must establish who will do your work, what is included and when help is available.

Decide what responsibility you are buying

Before drawing up a shortlist, describe the gap in your current arrangement. Three businesses running similar Rails applications could need quite different help.

A director without an internal technical team may need someone to manage the application's ongoing health, explain risks and propose work. A tech lead may want an experienced delivery team for a difficult upgrade while retaining architectural decisions. Another business may need technical leadership to settle priorities before it buys more development capacity.

Put that distinction in the brief. A proposal for developer time does not, by itself, assign responsibility for incident response, product decisions or work across other suppliers. Equally, an agency taking a wider role will need access to the people who can make business decisions.

Our earlier guide to choosing a digital product agency covers general selection questions. Here, the focus is how the named Rails offers might fit an application you already depend on.

Five agencies to compare

Bit Zesty

We are a small team of senior developers, predominantly based in the UK, with colleagues in other time zones contributing to support coverage. Our work covers building complex Rails applications, maintaining systems we have built or inherited, and helping existing development teams deliver changes.

Our Rails development and support and maintenance services provide fractional access to a wider team, including UX expertise and project-management oversight. AI expertise is available where there is a relevant requirement. Those disciplines are also offered elsewhere in this comparison; the useful discussion is which people and responsibilities your engagement needs.

For the King’s Awards for Enterprise, we built the web application used to manage award applications. It integrates with other government systems, including GOV.UK Notify and single sign-on.

We continue to maintain the application, applying security updates and patches as part of our ongoing support. Our role covers both the initial build and the continuing maintenance of a live government service.

Ask us to set out who will retain knowledge of your application, who coordinates delivery and how specialist input uses the agreed capacity. Our geographical spread is not a promise of staffed 24/7 support; coverage and escalation need to be agreed.

Foxsoft

Foxsoft describes a UK-based Rails team and makes a clear distinction between taking responsibility for a whole platform and delivering a defined piece of work alongside an internal team. Its published examples of the latter include upgrades, audits and performance work.

Its support offer covers application monitoring, patches, upgrades, performance improvements and reporting, with both ad-hoc and retainer arrangements. That makes it worth considering when the buying decision centres on keeping an established application running and improving.

Be specific about which engagement you want. If Foxsoft is joining your team for an upgrade, who handles unrelated incidents during that work? If it is taking wider responsibility, where does that stop when an issue involves your hosting provider or another application? Ask how the advertised business-hours response arrangements apply to your proposed package, including urgent issues and holidays.

Planet Argon

Planet Argon describes its Portland origins and distributed team. Its London service page explicitly addresses UK clients; that should not be read as evidence of a London office.

The company publishes maintenance and upgrade services, alongside fractional Rails development. The fractional model describes an assigned team learning the application and working with the client for agreed weekly or monthly capacity. Work can include fixes, features, performance and gradual modernisation. Its London offer also includes UX and interaction design.

This is worth discussing if you want continuing engineering input without staffing a complete internal Rails team. Ask how the assigned team will overlap with your working day, who can make decisions during that overlap and how requests move forward outside it. As with any distributed supplier, planned development across time zones and an urgent response commitment are separate arrangements.

thoughtbot

thoughtbot explicitly serves businesses across the UK. Its remote delivery model spans Rails development, research, design, product management and AI integration. It also offers fractional CTO and product leadership, so its offer extends beyond hiring developers for a new build.

The Rails maintenance service describes part-time support for existing applications, including upgrades, testing, performance and feature work. Capacity can vary with priorities and a monthly budget, with regular progress and prioritisation discussions.

Consider that breadth if you need to address both delivery and how the product team works. In a proposal, establish which roles are assigned to you and which require a separate scope. For an established application, ask how the maintenance arrangement interacts with larger development work: does the same team retain context, and who makes the call when an urgent issue displaces a planned feature?

Unboxed

Unboxed lists a London address and describes designers and technologists working with clients through embedded teams and other delivery arrangements. Its Rails service includes code, infrastructure and architecture assessment, upgrades, hosting and second-line support.

Its wider offer includes user research, service design and UX. That combination is worth discussing when the Rails application is one part of a service that also depends on staff, policies or several channels. The work may need changes to the service around the software as well as the code.

Ask how research and engineering would be staffed for your application, and who would carry responsibility once an initial improvement project finishes. Clarify what second-line support means in your arrangement: who receives the first report, who determines severity and how a request reaches the people able to change the system.

Compare the proposals on the same terms

A long list of capabilities will not tell you whether the right people are available for your application. Give each shortlisted agency the same short brief: what the system does, who currently looks after it, the business risks, the work waiting to happen and any fixed deadlines.

Ask for answers you can compare:

What to establish before choosing a Rails agency

Area	Evidence to request
Continuity	Named roles, cover for absence, knowledge-sharing arrangements and how team changes are handled.
Capacity	What is reserved for you, how additional work is agreed, and whether meetings, investigation and specialist input draw from the same allowance.
Accountability	Who prioritises, approves technical decisions, coordinates suppliers and reports risks to the business.
Support	Coverage hours, severity definitions, escalation contacts and the difference between response and resolution commitments.
Commercial fit	Assessment and onboarding costs, ongoing commitments, exclusions, change approval and arrangements for ending the engagement.

Use a realistic example in the discussion. An order integration starts failing on a Friday afternoon while the agency is partway through an upgrade. Who investigates, who contacts the other supplier, who tells your operations team and what happens to the planned work? The answer exposes assumptions that a list of included services can leave hidden.

Then ask for a relevant reference. A successful new-product launch may tell you little about supporting an inherited application. Look for experience with comparable operational responsibilities, and ask how the supplier handled uncertainty, interruptions and competing priorities.

Look beyond labels such as fractional and AI

Fractional describes how you buy time or access; it does not identify the person accountable for your application. UX capability could mean occasional design advice or sustained research with your users. Put the required activity and its owner into the proposal.

The same applies to AI. Using AI tools to write code is different from adding an AI feature to your application. If either matters to the brief, ask about the relevant experience, data handling, review and ongoing ownership. Avoid making an AI capability a deciding factor when the immediate requirement is reliable Rails maintenance.

Make a shortlist around your actual application

Choose a small number of agencies whose published offers match the responsibility you need them to take. Discuss the same scenario with each, meet the proposed delivery leads and compare the resulting scope. Keep unanswered questions visible rather than filling them in from a supplier's reputation.

If Bit Zesty looks relevant, our Ruby on Rails service explains how we approach new work, existing applications and additional team capacity. Bring an outline of the system, its integrations and your current support arrangement. That gives us a useful starting point for discussing whether our team fits the work.