Team in Mumbai · Head office in Navi Mumbai
Ruby on Rails Development Company in Mumbai
We build Ruby on Rails platforms for Mumbai’s publishers, payment and fintech teams, retailers and marketplaces: sites that stay up when a story, sale or deadline sends everyone in at once, payment flows that reconcile, and audit trails your finance team can read.
Projects run on current Rails 8.x with background jobs, caching and a relational database, for customers in Mumbai and anywhere else.
- Rails 8.x
- Active Job
- Redis or Solid Cache
- PostgreSQL / MySQL
- Sidekiq or Solid Queue
- 7+Years in business
- 120+Brands served
- 55+Team members
- 250+Projects delivered
- 100+Certifications
A Ruby on Rails development company in Mumbai builds web platforms, back offices, marketplaces and APIs on the Rails framework. The Adroit has its head office in Navi Mumbai and a team in Mumbai. For publishers, payment and fintech teams, retailers and marketplaces we plan for traffic spikes (caching, background jobs, queues, read replicas), design payment and reconciliation flows, and add audit trails and role-based access. Work is scoped and reported remotely, with workshops in Mumbai where they help.
What does “a Ruby on Rails development company in Mumbai” actually mean?
The Adroit has its head office in Navi Mumbai and a team in Mumbai. When a publisher in Lower Parel, a payments team in Bandra Kurla Complex or a retailer in Andheri looks for a Rails partner, the useful question is not the vendor’s postcode. It is whether the people building the system understand how Mumbai businesses run: results-day and release-day traffic, month-end closes, settlement files, channel partners, and auditors who ask for evidence.
So we treat the city as context, not a boundary. Rails suits this work because its conventions (background jobs, caching, database migrations, encrypted attributes, a mature testing culture) cover the unglamorous parts that decide whether a platform survives its busiest hour. The questions every Rails buyer faces, such as framework choice and cost drivers, are covered on our Ruby on Rails services page, and the head-office view is on the Navi Mumbai Rails page.
What do we build in Ruby on Rails for Mumbai businesses?
Six kinds of system account for most of the Rails work we scope for companies in the city. Each is a place where a slow page, a duplicate charge or a missing log line costs money or trust, so each gets the controls described further down this page.
Publishing and editorial platforms
Story editor with drafts, scheduled publishing, image handling, tag and section pages, newsletters and subscriber areas, built so a breaking story or a match day does not take the site down.
Fintech and payments back offices
Merchant and partner dashboards, onboarding queues, settlement and payout screens, dispute handling and finance exports, with approvals and an audit trail on every sensitive action.
Marketplaces
Seller onboarding, catalogues, orders split by seller, commissions, payouts and returns, with a ledger that finance can trace from a buyer’s payment to a seller’s settlement.
Retail and commerce engines
Catalogue and pricing rules, promotions, carts and checkout, inventory holds during flash sales, loyalty and returns, plus admin tools for the merchandising team.
Operations and workflow tools
Work queues, approvals, document upload, status tracking and role-based screens that replace spreadsheets and email threads inside Mumbai operations teams.
APIs and integrations
JSON APIs for apps and partners, plus connectors to gateways, accounting and ERP tools, KYC and e-sign providers, and SMS and WhatsApp messaging, with retries and logs.
Need a phone app on the same back end? See mobile app development in Mumbai. Prefer PHP for part of the stack? See our PHP development page for Mumbai. For the wider picture, see web development services.
Which Mumbai sectors suit Ruby on Rails, and what gets built for each?
Rails is strongest where a team needs to ship and change a rule-heavy web product quickly: catalogues, workflows, money movement and admin screens. The board below shows what we typically scope by sector, the hard part we plan for first, and the Rails building blocks involved.
- Media
- Publishing
- Fintech
- Payments
- Retail
- Marketplaces
| Sector | Typical Rails build | Hard part we plan for | Rails building blocks |
|---|---|---|---|
| Media, publishing, OTT content sites | Editorial back end, scheduled publishing, subscriptions and paywalls, content APIs for apps and partner feeds | Bursts when a story, result or premiere lands; fresh content that is still cacheable | Fragment and HTTP caching with a CDN, Active Storage, Action Text, scheduled jobs, Action Cable for live updates |
| Fintech and payments back offices | Merchant dashboards, onboarding and review queues, settlement and payout screens, finance exports | Money that must reconcile, approvals that must be provable, duplicate events from gateways | Active Job, database transactions and unique indexes, versioning gems for audit, policy-based authorisation |
| Retail, D2C and flash-sale commerce | Catalogue, pricing and promotion rules, checkout, order management, returns and loyalty | Sale-day peaks, stock that must not oversell, promotions that stack in surprising ways | Optimistic and row-level locking, counter caches, query caching, queued emails and invoices |
| Marketplaces | Seller onboarding, split orders, commissions, payouts, ratings, dispute workflow | A ledger across buyers, sellers and the platform; search and listing quality at scale | Service objects around a ledger model, background jobs for payouts, a search service behind a JSON API |
| Broking, insurance and NBFC operations | Case and claim queues, document intake, agent and partner portals, reporting dashboards | Access control by role, document handling, month-end and regulator-ready reports | Role policies, Active Storage with private buckets, read-replica reporting, scheduled report jobs |
| Events, ticketing and bookings | Listings, seat or slot holds, checkout, ticket delivery, organiser dashboards | Everyone arriving when sales open; holds that expire cleanly; payments confirming late | Expiring holds with jobs, queue-based checkout steps, webhook handling, rate limiting |
A note on the media angle. The Adroit has a media-buying relationship with JioHotstar and Star Network. That relationship is in media buying, not in building their software, and we make no claim about results from it. It does mean our team is used to thinking about audiences that arrive in sudden waves, which is the same problem a publisher’s Rails site faces on a big day.
Where Rails is the right tool
Rule-heavy web products that change often: editorial platforms, marketplaces, commerce engines, back offices and the APIs around them. Rails 8.x gives conventions for jobs, caching, mail, storage and testing, so the team spends its time on your rules, not on plumbing.
Where we would say no, or use something else
Ultra-low-latency matching engines, heavy numerical or machine-learning workloads and very long-lived streaming connections belong in other technology. Rails can still run the web, admin and API layer around them, and we say so at discovery rather than after.
How does a Rails application survive the day everyone arrives at once?
Mumbai traffic is spiky. A sale opens at noon, a result or filing deadline lands, a premiere or match starts, a salary-day payout window opens. A test at average load says little about those minutes. We plan for the peak, and for how the system fails when the peak is bigger than expected. The tools are well known; the skill is putting each in the right place and knowing what it costs.
| Layer | What it does in a spike | Rails building block | Watch for |
|---|---|---|---|
| Caching | Answers repeat reads without touching the database or rebuilding the page, so one popular story or product page is built once, not thousands of times | Fragment caching, Rails.cache.fetch, HTTP caching with ETags, a CDN in front; Redis, Memcached or Solid Cache as the store | Stale content after an edit, so expiry rules are designed with the editors, not bolted on |
| Background jobs | Moves slow work (emails, PDFs, image variants, webhook processing, exports) off the request so pages keep responding | Active Job on Sidekiq or the Rails 8 default Solid Queue | Jobs that are not safe to run twice, so every job is written to be idempotent |
| Queues | Separates urgent work from bulk work, so a flood of newsletter sends cannot delay a payment confirmation | Named queues with priorities and separate worker pools | A backlog that grows faster than workers drain it; queue depth is monitored |
| Read replicas | Sends heavy read traffic, dashboards and reports to a copy of the database, keeping the primary free for writes | Multiple databases with automatic reader and writer role switching | Replica lag: a user who just wrote data may not see it on the replica yet, so those requests read from the primary |
| Database | Keeps each query cheap so the primary is not the bottleneck | Indexes, includes to remove N+1 queries, find_each for batches, a connection pool sized to the threads | One missing index on a hot query can undo every other measure |
| App servers | Handles more requests in parallel and sheds load gracefully when it cannot | Puma workers and threads, rate limiting, a waiting room or degraded mode for the worst minutes | Adding servers does not help if every request waits on the same lock or the same slow query |
Login, search, checkout or story load, tested before the event, not a generic home-page test.
Hot pages and product data built before the doors open, so the first wave is not a cold start.
Payment confirmation jobs get their own queue and workers that bulk mail can never starve.
Error tracking, queue-depth and database alerts, and a rollback that has been practised.
What we will not promise: a requests-per-second figure before a load test on your own flows. Capacity depends on hosting, database design and what each request does, so we measure it with you and write the result into the hand-over notes. For the general tuning story, see our post on speeding up a Rails application.
How should payment-gateway integration work in a Rails app?
Most payment bugs are not in the gateway. They sit in what happens around it: a customer closes the tab after paying, a bank confirms late, a webhook arrives twice, a refund is raised on an order that never became paid. We design the Rails side so each of these ends in a known state, and we test those cases on purpose.
- One order, one state machine. Pending, paid, failed, refunded: allowed transitions are written down, and a payment can only move forward through them.
- Idempotency everywhere. A unique index on the gateway reference and an idempotency key on create calls, so a retry never charges or fulfils twice.
- Verified webhooks, stored first. The signature is checked, the raw event is saved, and a job does the work, so a slow handler cannot make the gateway retry in a storm.
- Amounts as integers in paise, with the currency and rounding rule written down, never floating-point rupees.
- 1Checkout creates an orderSaved as pending with an idempotency key and the amount in paise.
- 2Gateway page or UPI intentCustomer pays on the gateway’s page or app; card and UPI secrets never touch your server.
- 3Late, failed or duplicate?The branch that causes support tickets. Handled by explicit states.
- 4Webhook arrivesSignature verified, event stored, job moves the order to paid exactly once.
- 5Ledger entry writtenDouble-entry style record with the gateway reference, ready for finance.
Where credentials live. Card and UPI credentials stay with your payment gateway and are not stored in your application. The gateway is your choice; we integrate with the provider your bank or finance team has approved.
| Pattern | How it works | Fits when | Rails-side care |
|---|---|---|---|
| Hosted checkout | Customer is redirected to the gateway’s page, then returned to you | Fastest route to launch with the least sensitive data on your side | Never trust the return URL alone; confirm via webhook or a status lookup job |
| UPI intent or collect | Customer approves in a UPI app; the result arrives asynchronously | Mobile-heavy audiences paying small and mid-size amounts | Pending state with a timeout job that checks status before expiring the order |
| Payment links | A link is created per invoice or order and sent by SMS, email or WhatsApp | Collections, B2B invoices, phone and field-sales orders | Link-to-order mapping, expiry rules and reminders as scheduled jobs |
| Split settlement and payouts | One buyer payment is divided between sellers and the platform | Marketplaces and platform businesses | A ledger that records each leg, and payout jobs that can be re-run safely |
| Refunds and reversals | Money goes back to the buyer, in full or in part | Any commerce or booking flow | Maker-checker approval for large refunds, limits, and a reason code on every record |
| Recurring billing | A customer authorises repeat charges under the rules of the payment network | Subscriptions, memberships, instalments | Renewal jobs, failed-charge retries and customer notices; rules to be confirmed with your gateway and bank |
How do reconciliation and reporting jobs work in a Rails back office?
Reconciliation is the job that proves the money in your ledger is the money that moved. It is dull, repetitive and unforgiving, which makes it a good fit for scheduled background jobs: they run the same way every night, write down what they did, and hand the exceptions to a person. Reports follow the same rule. A month-end export should be a job with a status, not a button that freezes the dashboard.
| Job | Runs | What it does | How failure is handled |
|---|---|---|---|
| Settlement import | After the gateway publishes a settlement file | Fetches or accepts the file, parses it in a stream, stores each line with its source file name | Re-running the same file adds nothing twice; a bad line is quarantined, not dropped |
| Matching | After each import | Matches lines to ledger entries by gateway reference first, then by amount, date window and order number | Anything unmatched goes to an exceptions queue with the reason |
| Exceptions review | Worked daily by a person | Shows missing, duplicate and mismatched items with the evidence side by side | Every resolution is recorded with who decided and why |
| Payout run | On the agreed payout cycle | Builds seller or partner payouts from settled ledger entries | Approval step before release; the run can be repeated without double payment |
| Month-end reports | On request or on a schedule | Builds exports in batches from a read replica and delivers a download link | Visible status and retry; a failed export never blocks the live dashboard |
| Retention clean-up | On a schedule | Archives or deletes records under rules agreed with your counsel | Dry-run output reviewed before the first live run |
What should an audit-ready, data-protection-aware Rails build include?
Mumbai’s regulated and finance-adjacent businesses carry duties that shape software: the Digital Personal Data Protection Act, 2023 and its rules for personal data, and RBI directions on payment data where they apply to you. We are engineers, not legal advisers. Please confirm with your compliance counsel which obligations apply, including current commencement dates.
What we do is turn their answers into build requirements and test the application against them. The checklist beside this text is the starting set we bring to a first workshop, then trim or extend with your counsel’s input.
Questions worth taking to your counsel first:
- Which of our data counts as personal data, and which processing needs consent?
- Are we a regulated payment entity under RBI directions, or only a merchant?
- Where may data be stored and processed, and where are the backups?
- How long must we keep records, and when must we delete them?
- Who-did-what history on sensitive records through a versioning library such as PaperTrail or Audited, with the acting user and reason.
- Role-based access with least privilege, enforced by policy objects, and maker-checker for refunds, limit changes and payouts.
- Append-only audit table where the application role can add rows but not edit or delete them.
- Encrypted attributes for sensitive fields using Active Record Encryption, with keys and secrets held in managed credentials, not in code.
- Consent and notice recorded per purpose, with a timestamp and the wording shown.
- Data-subject requests (access, correction, erasure) handled through an admin tool, not ad-hoc console edits.
- Safe logging: filtered parameters so personal and payment data stay out of logs.
- Release checks with Brakeman and bundler-audit on every build, plus the tests that guard the rules above.
What is it like to work with a Rails team in Mumbai and a head office in Navi Mumbai?
Most of the work runs remotely, which keeps projects moving across schedules and cities. For decisions that benefit from a whiteboard, such as scoping a payment flow or mapping a newsroom workflow, workshops can be arranged face to face in Mumbai. Where meetings happen is agreed in each proposal.
| Topic | How we work | What it means for you |
|---|---|---|
| Workshops | Discovery and design workshops can be held in person in Mumbai or on a call, as agreed per project | Your editors, finance and operations leads can sit in the same room as the engineers when it matters |
| Time zone | Same time zone as your team: India Standard Time, with no daylight-saving shifts | Questions during your working day get answered during your working day |
| Hand-over | Calls, documents and hand-over notes | Business users can review flows in the language they use daily |
| Reporting | A monthly progress report, plus a working staging site you can open at any time | You see progress in the product itself, not only in a document |
| Head office link | The Mumbai team works together with the Navi Mumbai head office on every project | One organisation accountable for the project from first call to hand-over |
| Other teams | Teams in Bangalore, Delhi can join when a project needs product or institutional experience | Specialist input without changing vendors |
Logistics-led Rails work, such as dealer portals, port and warehouse integrations, is covered on the Navi Mumbai Rails page. Remote-first delivery across India is explained on the India Rails page.
How does a Rails project run from first call to production?
Eight steps, each with something you can hold us to. Dates are set in the proposal after discovery, because the schedule depends on roles, integrations and compliance needs, not on a template.
- 1Discovery
Workflows, users, systems to connect, and the money and data paths mapped.
Deliverable: scope and flow diagrams - 2Architecture and checklist
Hosting approach, queues, caching plan, roles and audit needs agreed with your counsel’s input.
Deliverable: architecture note - 3Design
Screens per role, the data model and the API contract before code depends on them.
Deliverable: clickable designs, schema - 4Build in increments
Working slices released to staging and reviewed with you at each milestone.
Deliverable: demo per milestone - 5Test and rehearse
Automated tests, security checks and a rehearsed peak scenario on your real flows.
Deliverable: test and load notes - 6Release
Deployment with a rollback plan, data migration where needed and monitoring switched on.
Deliverable: go-live checklist - 7Hand-over
Documentation, admin guides and a walkthrough for your team.
Deliverable: documentation pack - 8Support and reporting
Fixes, updates and framework upkeep, with a monthly progress report.
Deliverable: monthly report
New builds target the current Rails 8.x line on a supported Ruby 3.x release. Support windows change, so check rubyonrails.org/maintenance for Rails and ruby-lang.org for Ruby before you commit, and ask us which pairing we would choose today.
We start with a short review of code, database, hosting and dependencies, then agree whether to stabilise, upgrade step by step or rebuild the weakest parts. Upgrade planning is covered in depth on the Rails services page.
Cost is quoted after discovery and moves with user roles, integrations, payment and compliance needs, design depth, data migration and the level of testing and support. Engagement models are explained on the India Rails page; to add people to an existing team, see hire Ruby on Rails developers.
Where to go next
Pick the page that matches your question, or tell us what you are building and we will suggest the right starting point.
Tell us what you are building
Share the workflow, the systems it must connect to and your busiest day. We reply with questions and a suggested scope.
Work That Works
Browse through our portfolio to view examples of our previous projects and see how we've assisted businesses like yours in reaching their online objectives using our Ruby on Rails solutions.
What's More
How Are We Different?
Dedicated Account Manager
SEO Enabled Websites
Responsive Websites
Site Security Upgrades & Maintenance
Website Speed & Performance Optimization
Timely Delivery
Easy to use CMS
Google PSI Score Above 80
Maximum 12 Hours TAT
Secured & Optimised Website Delivery
15 Days Cooling Period
Insights
Latest and Greatest Posts
Ruby on Rails
AI and Machine Learning Integration in Rails
Your Success, Our Reputation
Awards and Recognition
Reviews & Testimonials
What clients say about us
- 5.0Clutch rating from 19 reviews (opens in a new tab)
- 4.9DesignRush rating from 11 reviews (opens in a new tab)
- 4.9Google rating from 146 reviews (opens in a new tab)
"They’re a very efficient and professional team."
The Adroit has developed a website that meets the my specific needs and requirements. The team has helped improve the website's page rankings within the first two weeks of the project. The Adroit has been efficient, professional, supportive, communicative, and attentive to the client's needs.
Kunal Om Tavri - Artist,Kunal Om Tavri
"They were responsive and took action when required in urgency."
The Adroit delivered satisfying work that effectively matched the our ideas. The team was patient with the our requirements and changes and responded timely via WhatsApp, email and messaging apps, and in-person meetings. Ultimately, the team's responsibility made them a reliable partner.
Tejinder Singh Bhabra - COO & Director,ProNoesis
The Adroit is a team of passionate marketing professionals who have consistently contributed to our organization with digital support and assistance. They have always responded to our queries and helped us create an urban digital presence with modern designs that produced definite results.
Luvkesh Agarwal - Founder & CEO,Aertrip
"Their dedication, expertise, and commitment to delivering high-quality results have exceeded our expectations."
The Adroit team's dedication, expertise, and commitment have made the collaboration a pleasure. Their excellent communication kept us informed throughout the process, ensuring high-quality results from start to finish.
Sachin Javale - Project Manager,The SaltInc Consulting Pvt Ltd
The Team at The Adroit are a group of highly-skilled, experimental and fearless professionals in every sense of the word. It was a wonderful experience to see the instantaneous change and impact they drove on our page with their fun, strategic and consistent campaigns.
Mr. Ravi Hudda - Chief Digital Officer,Raymond Limited
"Their technical expertise and knowledge, and quick response time are impressive."
The Adroit team successfully increased website traffic and completed the project with zero downtime. We are quite happy with the service provided by the team. They always deliver on time and communicate well
Mayank Raturi - Director Digital Marketing,Checkmarx
"We want to express to you our warmest admiration for your unfailing service to us as one of our dependable partners."
The Adroit delivered the project on time, meeting the our expectations. They communicated frequently and promptly via email and virtual meetings, ensuring an effective workflow. Their agile responsiveness and transparency were hallmarks of their work.
Ravi Vyas - Founder & CEO,Sebone Technologies
Team at The Adroit is professional, quick, courteous, and very helpful. Their creatives & graphics are at par in the industry. Kaustubh, Creative Head does a phenomenal job on Social Topical creatives.
I appreciate their timely response & highly recommend The Adroit for Digital Marketing.
Ashwini Thakur - Regional Director - South Asia,Northumbria University
The Adroit Team is sharp, savvy, and surely ahead of the pack. With their clever and data-driven solutions, we’re now able to reach and convert new leads into loyal customers every day. Our numbers continue to grow consistently every month.
Naresh Soni - Manager Marketing,Weavings Manpower Solutions Pvt Ltd
"I appreciated their efforts and quality of work."
I was delighted, the project was completed in a timely manner. The Adroit followed a collaborative approach, which made me easy to work with. Moreover, they leveraged their knowledge and technical expertise to deliver quality and budget-friendly solutions.
Rahul Bhatambre - Director,Mindvein
Related work from our portfolio:
Questions
FAQs
Both. The head office is in Navi Mumbai, and there is a team in Mumbai that works on Ruby on Rails projects for businesses in the city. Projects are scoped, built and reported on remotely, and you receive a monthly progress report. Discovery and design workshops can be held face to face in Mumbai or on a call, and where they happen is agreed in each proposal, so a company in Mumbai or anywhere else works with the same team and process.
Typically an editorial back end with drafts, scheduled publishing and image handling, section and tag pages, subscriber areas and newsletters, content APIs for apps and partner feeds, and live-update features for events. The hard part is not the editor but the day a story or event sends a sudden wave of readers, so we plan caching with your editors, put a CDN in front, and move slow work to background jobs. The Adroit also has a media-buying relationship with JioHotstar and Star Network; that is a separate service from software development and carries no claim about results.
By planning for the peak rather than the average. That means fragment and HTTP caching with a CDN, background jobs and separate queues so slow work never blocks a page, read replicas for reports and dashboards, indexed queries with N+1 problems removed, tuned Puma workers and threads, and a rate-limit or degraded mode for the worst minutes. We rehearse real flows such as login, search and checkout before the event. We do not quote a requests-per-second figure in advance, because capacity depends on hosting, database design and what each request does.
Background jobs are tasks that run outside the web request, such as sending email, building a PDF or processing a webhook. Queues decide which jobs run first and on which workers, so urgent work like a payment confirmation is not stuck behind a bulk newsletter. A read replica is a copy of the database that serves heavy read traffic like reports, so the primary stays free for writes. The trade-off to plan for is replica lag, where a user who just saved something may not see it on the replica yet.
Treat the gateway as an asynchronous partner. Save the order as pending with an idempotency key, let the customer pay on the gateway’s page or app, and confirm through a signature-verified webhook that is stored before any work is done. Keep amounts as integers in paise, enforce allowed state transitions, and add a unique index on the gateway reference so a duplicate event cannot pay an order twice. Card and UPI credentials stay with your gateway and are not stored in your application. The gateway is your choice, and we integrate with the provider your bank or finance team has approved.
Reconciliation compares gateway settlement files and bank statements with your ledger and lists what does not match. In Rails it is a scheduled job that imports each file safely (running the same file twice adds nothing), matches lines by gateway reference and then by amount and date, and sends the rest to an exceptions queue where a person decides. Month-end reports follow the same pattern: built in batches from a read replica, with a visible status and a download link, so a large export never slows the live dashboard.
Access is designed around roles with least privilege, enforced by policy objects, so an agent, an approver and an administrator each do only what their job needs. Sensitive actions such as refunds, limit changes and payouts can require a second person to approve. Changes to important records are versioned with a library such as PaperTrail or Audited, and an append-only audit table records who did what, when and why, so auditors can export the history without asking a developer to query the database.
They turn into build requirements: consent and notice recorded per purpose, tools to handle access, correction and erasure requests, retention rules, safe logging, and, where RBI payment-data directions apply to you, decisions on where data is stored. We are engineers, not legal advisers, so please confirm with your compliance counsel which obligations apply to your business and when they take effect. We then convert their answers into a checklist that the application is built and tested against. Nothing on this page should be read as a statement that any system is certified or compliant.
Often, yes. Rails handles the catalogue, onboarding, order splitting, commission and payout rules, returns and dispute workflows well, and its background-job tooling suits payouts and settlement runs. The part that needs the most design is the ledger: each buyer payment, seller share, commission and refund should be a recorded entry that finance can trace end to end. Search at scale is usually delegated to a dedicated search service behind a JSON API. We assess these choices during discovery, before any estimate.
For a new build we use the current Rails 8.x line on a supported Ruby 3.x release, and we confirm the exact pairing against the official maintenance pages at the start of the project. Support windows change over time, so please check rubyonrails.org/maintenance for Rails and ruby-lang.org for Ruby rather than relying on a figure from a web page. If you run an older Rails version, an incremental upgrade is usually safer than a rewrite, and the Ruby on Rails services page explains the upgrade path.
We quote after discovery, so there is no list price and no fixed timeline we can honestly give in advance. The cost and schedule move with the number of user roles, the number and quality of integrations, payment and compliance requirements, design depth, data migration, and the level of testing and support you want. The proposal states the scope, the engagement model, the milestones and the monthly reporting. Engagement models are explained on our India Rails page.
Yes. We start with a short review of the code, database, hosting, dependencies and the slowest endpoints, then report what is sound, what is risky and what is missing, such as indexes, tests or a supported Ruby version. From there you choose between targeted fixes (caching, queues, query clean-up), a step-by-step upgrade, or rebuilding the weakest parts. We do not recommend a full rewrite unless the review shows that the existing code cannot be made safe.