Startups & product teams · Rails 8.x · API-first
Ruby on Rails Development Company in Bangalore
We help Bangalore startups and product teams take a Rails product from first commit to paying customers: multi-tenant SaaS, API-first back ends for React and mobile clients, subscription billing, background jobs and release pipelines.
Our head office is in Navi Mumbai and we have a team in Bangalore (Bengaluru) for stand-ups and sprint reviews. Scope is written down, work ships as small reviewed pull requests, and progress is reported monthly.
- Written scope agreed before the build starts
- Small pull requests your engineers can review
- Monthly progress report for the whole engagement
In short
A Ruby on Rails development company in Bangalore builds and runs the server side of web products on Rails: multi-tenant SaaS, JSON APIs for React and mobile apps, subscription billing, background jobs and release pipelines. The Adroit has a team in Bangalore and its head office in Navi Mumbai. We build on a currently supported Rails 8.x release (see rubyonrails.org/maintenance for what is supported today), agree scope in writing, quote after discovery, and report progress monthly.
@@ who this is for @@
What does Rails development look like for Bangalore startups and product teams?
Bangalore buys Rails differently from most cities. The buyer is usually a product company: a founder with a prototype and a first pilot customer, a seed-to-Series-A team whose early codebase now carries paying accounts, or a product group with a Rails monolith that wants a React web app and a mobile client on top of it. Questions about tenancy, API contracts, release pipelines and on-call arrive long before questions about page design.
That is the work our team in Bangalore is organised around. The head office is in Navi Mumbai, and the Bangalore team follows the same process as our other teams: written scope, sprints, demos and a monthly progress report. Rails suits this work because its conventions keep a small team fast. Rails 8.x ships with a database-backed job queue, cache and WebSocket adapter as defaults, an authentication generator and a deployment tool, so engineering time goes into your product rather than plumbing. For the full range of what we deliver, see our Ruby on Rails services overview.
If you are weighing an outside team against hiring in-house, the useful question is what you want to own. The roadmap and the domain knowledge stay with you; build capacity, upgrades and release engineering can be shared. The code lives in a repository you control, and the handover terms are agreed in the proposal.
@@ mvp → scale @@
What does each stage of a Rails product need, from MVP to scale?
Most Rails products are over-built at the start and under-built when the first large customer arrives. The log below reads like a commit history: each entry is a stage, the question it answers and the shape of Rails that fits, so you pay for what the current stage needs and can see what is coming next. How long each stage takes depends on scope and is set after discovery, never before.
- stage/1-mvp
Will anyone pay for this?
One Rails app, one PostgreSQL database, server-rendered Hotwire or Inertia pages.
Relative scope, illustrative: 1 of 5 - stage/2-first-customers
Can customers onboard without hand-holding?
Same monolith, tenant-aware from the first migration, background jobs for email and imports.
Relative scope, illustrative: 2 of 5 - stage/3-growth
Can the team ship often without breaking things?
Modular monolith, versioned API, staging, feature flags and a test suite that runs on every pull request.
Relative scope, illustrative: 3 of 5 - stage/4-scale-up
Can we serve larger customers reliably?
Several app servers, queues split by workload, read replicas only where measured, search and tracing.
Relative scope, illustrative: 4 of 5 - stage/5-enterprise-ready
Can we pass a customer’s security review?
SSO, audit trail, per-tenant export and deletion, documented architecture, separated environments.
Relative scope, illustrative: 5 of 5
| Stage | Rails shape that fits | What we put in place | Watch for |
|---|---|---|---|
| 1. MVP | Single app and database; Rails authentication generator or a maintained auth gem | One or two plans, basic roles, error tracking, deploys from CI | Building features nobody has asked for |
| 2. First customers | Tenant-aware models, Active Job for email and imports | Tenant scoping tests, audit trail, backups with a restore that has actually been tried | A tenant’s data leaking through an unscoped query |
| 3. Growth | Modular monolith, versioned JSON API, optional React front end | CI, staging, feature flags, caching, query review for N+1 patterns | Slow queries and a test suite nobody trusts |
| 4. Scale-up | Workers split by queue, Redis or database-backed cache, search engine, CDN | Load tests, tracing, rate limits, per-tenant concurrency limits on jobs | One tenant’s bulk import slowing everyone else |
| 5. Enterprise-ready | Documented architecture, hardened configuration, separate environments | SSO, access evidence, dependency audit in CI, incident runbook | Describing controls you do not actually operate |
@@ multi-tenancy @@
Row-level or schema-per-tenant: how should a Rails SaaS isolate its customers?
Tenancy is the hardest decision to reverse, so we settle it in discovery and write down why. In Rails the three common models are a shared schema with an account column on every table (row-level), one PostgreSQL schema per tenant, and one database per tenant using Rails’ multiple-database support. Gems exist for each approach, but their maintenance status varies, so we check them against your Rails version before relying on one. Sometimes a few hundred lines of your own code is the safer choice.
Whatever the model, the rule is the same: resolve the tenant once, early, and let it travel. In Rails that means loading records through the current account instead of the bare model, passing the account id into every Active Job, and carrying it through cache keys, Active Storage paths, Action Cable streams and log lines. In a row-level setup, PostgreSQL row-level security can act as a second lock if the application layer slips. We test the rule directly with request specs that sign in as one tenant and try to read another’s records.
Data-residency and restore requirements often decide the model more than cost does. Ask your largest prospect’s security contact what they expect before the schema exists, not after.
In Rails: an account_id on every tenant-owned table, loaded through the current account. Guard against unscoped and raw SQL.
In Rails: switch the search path per request; migrations run once per schema. Check how your chosen gem handles that switch.
In Rails: multiple databases with per-request connection switching. Connections, migrations and monitoring multiply with tenants.
The most common tenancy bug, as a diff
The fix is usually one line, which is why it is easy to miss in review. The same care applies to jobs: a worker has no signed-in user, so it must be told which account it is working for.
Removed lines carry a minus sign and a dashed edge; added lines carry a plus sign and a solid edge, so the meaning never rests on colour alone.
@@ app/controllers/invoices_controller.rb @@ def show− @invoice = Invoice.find(params[:id])+ @invoice = Current.account.invoices.find(params[:id]) end @@ app/models/invoice.rb @@− InvoiceEmailJob.perform_later(id)+ InvoiceEmailJob.perform_later(id, account_id)
| Model | Isolation | Effort to run | Restoring one tenant | Fits when |
|---|---|---|---|---|
| Row-level, shared schema | Logical; enforced by the application, optionally backed by row-level security | Lowest; one schema to migrate | Hard; rows must be extracted | Many small tenants on self-serve plans |
| Schema per tenant | Stronger; separate namespaces in one database | Medium; migrations run per schema | Moderate | Hundreds of mid-size tenants |
| Database per tenant | Strongest; separate databases | Highest; connections, migrations and monitoring per tenant | Easiest; restore one database | Fewer, larger tenants; contractual or residency needs |
@@ api-first / headless @@
How do you run one Rails back end behind a React app and a mobile app?
By deciding how much of the product is API, then writing the contract before the code. When a web front end, a mobile app and a partner integration depend on the same back end, an unreviewed change to a response breaks all three at once. Rails handles this well: one codebase can serve admin screens through Hotwire and a versioned JSON API to everything else.
/api/v1 · Hotwire admin screens| Pattern | What it is | Fits when | Trade-off |
|---|---|---|---|
| Hotwire (Turbo and Stimulus) | Server-rendered pages updated over the wire, minimal custom JavaScript | Dashboards, internal tools and products with one web client | A second client later needs an API added alongside |
| Inertia on Rails | React or Vue pages served on Rails routes with no separate API per screen | A React-minded team that wants one deployable app | Mobile and partners still need their own API |
| Separate API plus SPA and mobile | Versioned JSON API consumed by a React app, mobile apps and partners | Several clients need the same data and rules | Two codebases to release; contract discipline is essential |
| Hybrid | Hotwire for admin and back office, JSON API for customer clients | A product with a rich back office and mobile-first customers | Two ways to build a screen; agree where each applies |
Model the resources
Agree nouns, relations and permissions with product and front-end people.
Write the contract
An OpenAPI document, reviewed before any controller exists.
Mock and build
React and mobile work begin against a mock while Rails is built.
Contract-test
Request specs fail if a response drifts from the spec.
Version and retire
Changelog, deprecation notices and usage checks before removal.
Conventions that save the most rework
Pick one error shape, one pagination style and one date format, and make the contract tests enforce them on every endpoint. We default to short-lived access tokens with refresh for mobile clients, an allow-list for cross-origin requests, rate limits at the edge or in the app, and idempotency keys on any request that creates money-related records. JSON is rendered with a serializer layer rather than ad-hoc hashes, so a field cannot be exposed by accident.
Where the API must feed an ERP or a dealer system, see how we approach that in our Navi Mumbai Rails page. For the mobile side of the same API, see our mobile app development work and our web development services.
POST /api/v1/invoices Authorization: Bearer <short-lived token> Idempotency-Key: 4c1e-98ab { "plan": "growth", "seats": 25 } 201 Created { "data": { "id": "inv_1042", "status": "open" } } 422 same shape for every validation error: { "error": { "code": "invalid", "fields": ["seats"] } }
@@ subscription billing and metering @@
How do you build subscription billing and usage metering on Rails without tying it to one gateway?
By keeping billing as your own domain and treating each payment gateway as an adapter. Plans, subscriptions, entitlements, usage and invoices live in your tables; a thin adapter translates between that model and whichever gateway you use today. The checkout screen is the easy part. The work is in what follows: verifying webhook signatures, making handlers safe to run twice, applying upgrades and downgrades, retrying failed payments and keeping plan limits, invoices and account status in step.
If you bill on usage, metering needs the same discipline. Every billable action writes an append-only usage event with a unique key, so a retried job cannot count twice. A scheduled job then rolls those events into per-period quantities that feed the invoice. When a customer asks why a bill is what it is, you can show the events behind it.
Which gateway you can use depends on your business registration and the provider’s own approval, which neither we nor your developers control. Tax and invoice fields, such as GST details for Indian customers, should be confirmed with your accountant before launch. For products where payments spike around events, our Mumbai Rails page covers that angle.
Customer acts
Pays at checkout, or does something billable.
Event arrives
Gateway webhook, or an internal usage event.
Inbox
Signature verified, raw payload stored, unique key enforced.
Idempotent job
Runs per account; safe to run twice.
State updated
Entitlements, invoices and account status move together.
| Concern | How we model it | Failure it prevents |
|---|---|---|
| Plans and entitlements | Plans, prices and feature limits as rows; one service object answers what an account may do | Plan checks scattered across controllers and disagreeing |
| Gateway events | Webhook inbox table, processed in a job keyed by event id | Events applied twice, or lost during a deploy |
| Usage metering | Append-only usage events with unique keys, rolled up per billing period | Double-counted usage and invoices nobody can explain |
| Invoices | Generated in your domain, separate from the gateway | A later change of provider rewriting accounting records |
| Failed payments | Retry schedule, reminder emails and a grace period held as account state | Silent churn from expired cards |
@@ background jobs and events @@
Which background job and event pipeline setup suits a growing Rails product?
Almost everything slow in a SaaS product ends up in a queue: imports, exports, emails, billing runs, webhooks to your own customers. The choice of queue matters less than the rules around it. Rails 8 makes a database-backed queue (Solid Queue) the default, and Redis-backed and PostgreSQL-backed alternatives remain common. Check each project’s current documentation and licence before committing.
| Option | Backed by | Fits when | Watch for |
|---|---|---|---|
| Solid Queue (Rails 8 default) | Your relational database | A new app that wants fewer moving parts and moderate job volume | Database load as volume grows; measure, and consider a separate queue database |
| Sidekiq | Redis | High throughput and a mature ecosystem of add-ons | Redis memory and persistence; some features are commercial |
| GoodJob | PostgreSQL | A PostgreSQL-only stack that wants jobs enqueued in the same transaction as data | Database connections and load at higher volume |
Rules we apply whichever queue you pick
- One queue per workload. Emails, imports and billing runs do not share a lane.
- Retries with backoff, and idempotent jobs. A job that runs twice must be harmless.
- Per-tenant fairness. Concurrency limits so one account’s bulk job cannot starve the rest.
- Dead jobs get a human. Failures alert someone and can be re-queued after a fix.
- Recurring work is code. Rollups and clean-ups are scheduled jobs under version control.
Events without a message broker
Many products need to tell other parts of the system that something happened: send an email, call a customer’s webhook, update a search index. A transactional outbox does this with tools you already have. The record and an outbox row are saved in the same database transaction; a job then reads the outbox and fans the event out. If a consumer fails, the event is still there to retry. A dedicated broker can come later, if volume ever justifies it.
Request
A user or API client changes something.
One transaction
Record saved together with an outbox row.
Dispatcher job
Reads unsent outbox rows and marks them sent.
Consumers
Email, customer webhooks, search index, analytics.
@@ ci/cd and feature flags @@
How do CI/CD and feature flags let a Rails team release every week without drama?
Frequent releases are safe when each one is small, checked automatically and reversible. The pipeline below is the shape we set up for product teams. The tools named are examples of what we commonly use, and we adapt to what your team already runs.
Pull request
Small branch, clear description, linked ticket.
Automatic checks
Tests, RuboCop, Brakeman, dependency audit.
Human review
At least one engineer from your side or ours.
Staging
Deployed and smoke-tested before production.
Flag off
Shipped to production but dormant.
Gradual rollout
Internal users, then a few accounts, then everyone.
PASS bin/rails test (unit and request specs) PASS rubocop (style and lint) PASS brakeman (static security scan) PASS bundler-audit (known-vulnerable gems) FAIL strong_migrations (unsafe column rename) merge blocked until every line reads PASS
@@ db/migrate/add_plan_code_to_accounts.rb @@− rename_column :accounts, :plan, :plan_code+ add_column :accounts, :plan_code, :string+ # later deploys: backfill, switch reads,+ # then drop :plan in a separate release
@@ observability @@
What should observability cover in a multi-tenant Rails app?
A SaaS product is judged by how it behaves on its worst day. When a customer reports a problem, the question is how fast you can trace it to one request, one job or one tenant. These four layers are what we put in place before launch, and they stay useful as the team grows.
Structured logs
One line per request in a parseable format, carrying the request id and account id, so support can search by customer.
Error tracking
Exceptions from web requests and jobs grouped, tagged with release and account, and routed to someone who will read them.
Tracing and metrics
Request and job timings, database query time and queue depth, so slowness is located rather than guessed at.
Health and alerts
Health checks, queue-age alerts and backup checks that tell you before a customer does.
We set targets with you in the proposal; we do not publish uptime or response-time guarantees on this page.
@@ team augmentation @@
How does a Bangalore Rails team work next to your in-house engineers?
Your in-house team and ours share a time zone, so stand-ups, pairing and pull-request review happen in the same working day instead of waiting overnight. Our team in Bangalore joins your tools: your repository, your board, your branch rules and your definition of done. The head office in Navi Mumbai supports delivery, and calls and written updates follow the rhythm your team prefers.
The aim is a team that adds capacity without adding a second way of working. Pull requests follow your template, reviews go in both directions, and anything we learn about your system is written down where your own engineers will find it. Meeting arrangements, including any visits, are agreed in the proposal rather than assumed. For how we run projects for teams outside the city, see our Ruby on Rails development in India page.
A typical two-week sprint (length and timings agreed in the proposal)
| Way of working | What our team owns | What stays with you | Good fit when |
|---|---|---|---|
| Embedded engineers | Tickets taken from your board, delivered to your standards | Priorities, product decisions and final merge rights | Your process is solid but you are short of hands |
| Feature pod | One bounded slice end to end, such as billing or API v2 | Roadmap and acceptance of the slice | The slice has clear edges and an owner on your side |
| Quality and upgrade pod | Test coverage, N+1 clean-up, CI, Ruby and Rails upgrades | Feature work and release timing | Velocity is slowing under accumulated debt |
| Architecture review | A written review of tenancy, API, jobs and billing, with suggested pull requests | Implementation by your own team | A big decision is coming and you want a second opinion |
@@ scope and cost @@
How is a Rails product build scoped, and what moves the price?
Discovery comes first. We list features as launch-critical, soon and later, agree the architecture, and then quote the first group. The price follows scope rather than a rate card, and the terms of the engagement are agreed in the proposal. For a comparison of engagement models, see our India page.
| Cost driver | Why it moves the scope | Question to settle early |
|---|---|---|
| Tenancy model and roles | Stricter isolation and more user types mean more design and test work | How many tenant types and roles at launch? |
| Billing complexity | Flat plans are simple; seats, proration and metering are not | Do you bill on usage, seats or both? |
| Clients to support | Each extra client multiplies contract and testing effort | Web only, or web plus iOS, Android and partners? |
| Integrations | Gateways, accounting, CRM, email and partner APIs each add edge cases | Which systems must exchange data on day one? |
| Data migration | Moving customers off spreadsheets or an older system takes cleaning and checking | What data must come across, and who validates it? |
| Quality bar | Test depth, CI, observability and security-review readiness take engineering time | Which customers will review your security posture? |
Related: Ruby on Rails services · Rails for institutional portals, New Delhi · PHP development in Bangalore · Our clients
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)
"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
"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
Related work from our portfolio:
Questions
FAQs
It takes the product from idea to a running, billable service. That means scoping the first release, choosing the tenancy model, building the Rails back end and its API, wiring authentication and subscription billing, setting up background jobs, deployments and monitoring, and then maintaining it as customers arrive. Our team in Bangalore works to a written scope and a monthly progress report, with the head office in Navi Mumbai supporting delivery. The aim is a codebase your own engineers can later extend or take over.
Often yes, when the product is a database-backed web application with accounts, forms, payments and an admin side. Rails conventions let a small team ship quickly, and Rails 8.x includes a job queue, cache, authentication generator and deployment tool out of the box. Another stack may fit better if your team already standardises on it, or if the product is dominated by real-time streaming or heavy machine-learning workloads. A short architecture conversation before you commit is worth having either way.
Choose by tenant count and by how strict separation must be. A shared schema with an account column on every table is cheapest to run and suits many small tenants, but scoping must be enforced centrally and tested. Schema-per-tenant on PostgreSQL gives cleaner separation. Database-per-tenant gives the strongest isolation and the easiest single-customer restore, at the cost of running migrations and monitoring for every tenant. We settle this in discovery from your customer profile and contracts, and record the reasons.
Yes. A versioned JSON API can serve a React front end, iOS and Android apps and partner integrations from the same codebase that renders your admin screens. We write the API contract first, as an OpenAPI document reviewed before any controller exists, and add contract tests so a response cannot drift unnoticed. Whether you need a fully separate front end or something lighter, such as Hotwire or Inertia, depends on how many clients will use the API.
We keep billing as your own domain, with plans, subscriptions, entitlements, usage events and invoices in your tables, and treat each payment gateway as a replaceable adapter. Webhooks go into an inbox table, are verified, and are processed by idempotent jobs, so a replay changes nothing twice. Usage events are append-only with unique keys and rolled up per billing period. Which gateway you may use depends on your business registration and the provider's approval, and tax fields should be confirmed with your accountant.
Start with the default unless you have a reason not to. Rails 8 makes Solid Queue, which stores jobs in your relational database, the default, and it keeps the stack simple. Sidekiq on Redis and GoodJob on PostgreSQL are established alternatives. The more important rules apply to any of them: separate queues per workload, idempotent jobs, retries with backoff, concurrency limits per tenant and alerts for failed jobs. Check each project's current documentation and licence before committing.
By making each release small, automatically checked and reversible. Every change is a pull request that runs tests, a style check, a static security scan and a dependency audit. Risky features ship behind a feature flag that is off, then roll out to staff, a few accounts and finally everyone. Database migrations are written in expand-then-contract steps so old and new code can run together, and the rollback path is tried in staging first.
Four layers: structured logs carrying a request id and account id, error tracking for web requests and jobs, tracing and metrics for request, query and queue timings, and health checks with alerts, including queue age and backup checks. Together they let you trace a customer complaint to one request, job or tenant. We agree targets with you in the proposal; we do not publish uptime or response-time guarantees.
Yes. Our team in Bangalore shares your time zone, joins your repository, board and branch rules, and takes part in stand-ups, pull-request review and sprint reviews. Common set-ups are embedded engineers, a feature pod that owns one slice, a quality and upgrade pod, or a written architecture review that your team implements. Meeting arrangements, including any visits, are agreed in the proposal.
Start on a release that is still receiving fixes and that your key gems support, which today means a Rails 8.x series on a current Ruby 3.x or newer. Support windows change, so check rubyonrails.org/maintenance and ruby-lang.org before you choose, and pin the versions in your Gemfile and container image so production matches CI. Avoid starting on a series that is already security-only or end-of-life, because that turns into an upgrade project within months.
The code should live in a repository you control, and we recommend setting that up on day one. Ownership and intellectual-property terms are set out in the proposal. To make a handover easy we write short architecture notes, keep a runbook for deploys and rollbacks, and ask someone who did not write the setup instructions to follow them. That way your own engineers can take the product over, or extend it, without depending on us.
We quote after discovery, because cost follows scope rather than a rate card. The biggest movers are the tenancy model and number of user roles, billing complexity, how many clients the API must serve, integrations, data migration, and the quality bar for testing, observability and security reviews. For a defined MVP a fixed-scope quote usually fits; if requirements will change as you learn from users, time-and-material or a dedicated team is safer. Terms are agreed in the proposal.