Backend App Development Company: The Five Things the SERP Glosses Over (And What to Ask Instead)

A “backend app development company” is one of three things depending on who is selling it: an outsourced dev shop that builds the backend for you, a consulting firm that advises the team, or a managed platform that runs the API, the database, and the deploy so the team can build the backend themselves. The search results conflate the three because the keyword is broad and the SERP rewards whoever pays for the placement. The team that searches for a backend app development company is usually looking for the third kind, but the third kind is rarely the one with the sales team.

This post is for the technical lead or founder who typed the keyword and got back 30 outsourcing listings. The five things the SERP glosses over are below, plus the five questions to ask instead, plus the cases where the answer is “you do not need a vendor.”

Table of contents

• The three categories the SERP conflates
• The five things the SERP glosses over
• The five questions to ask instead
• The cases where a vendor is the right answer
• The cases where the answer is “you do not need a vendor”
• The contract red flags
• The right way to evaluate a vendor
• How this fits the rest of the stack
• FAQ

The three categories the SERP conflates

The three categories, same as the web app and back end services posts:

1. Outsourcing shops. Build the backend for the team, deliver a codebase, hand off. The contract is fixed-price or time-and-materials. The team inherits the codebase.
2. Consulting firms. Senior engineer or architect joins the team for a defined period, helps with a specific problem, leaves. The deliverable is a plan, a code review, or a feature.
3. Managed platforms. Run the deploy, the database, the storage, the scaling, the health checks. The team writes the backend. The platform runs it.

The SERP is dominated by category 1 because category 1 has the highest commercial intent for the keyword. The right answer for most teams is category 3, with optional category 2 help for the specific problem the team cannot solve alone.

The five things the SERP glosses over

The five things the SERP listings do not show, in order of how often they bite:

1. No code samples in the listing. The team’s listing is a sales page, not a portfolio. The team has to ask for code samples separately. The team that signs a contract without reviewing the vendor’s past code signs a contract for an unknown product.
2. No SLAs in the listing. The team’s listing is a sales pitch, not a service-level agreement. The team has to negotiate SLAs separately. The team that signs a contract without SLAs signs a contract for an undefined product.
3. No team resumes in the listing. The team’s listing is a brand, not a team. The team that signs a contract without meeting the engineers signs a contract for an unknown team.
4. No references the team can call. The team’s listing is a name, not a reputation. The team that signs a contract without talking to past clients signs a contract for an unknown vendor.
5. No migration path in the listing. The team’s listing is a contract, not a relationship. The team that signs a contract without a migration path signs a contract that ends in a panic when the vendor raises prices, misses deadlines, or disappears.

The five are the part of the contract the team should negotiate, not the part the team should assume. The right answer is to ask, in writing, before the contract is signed.

The five questions to ask instead

The five questions the team should ask the vendor, in order:

1. What is the team’s stack? The vendor’s stack should match the team’s. A vendor that specializes in Java is the wrong vendor for a Node.js team. A vendor that specializes in Python is the wrong vendor for a Go team. The right vendor has shipped in the team’s stack at least three times in the last two years.
2. What is the timeline? The vendor’s timeline should be realistic. A timeline that is “ASAP” is a timeline that will slip. A timeline that is “two weeks” is a timeline that is too short. The right timeline is one the team can verify against the vendor’s past projects.
3. What is the handover? The vendor’s handover should be a codebase, not a service. The team that receives a service is locked in. The team that receives a codebase can iterate.
4. What is the IP? The vendor’s IP clause should be clear. The right answer is that the team owns the codebase, the documentation, and the credentials, from day one. The wrong answer is that the vendor owns the IP until the final payment.
5. What is the cost? The vendor’s cost should be transparent. The right answer is a fixed price or a time-and-materials rate with a cap. The wrong answer is a “starting at” price with no ceiling.

The five questions are the minimum. The right answer is to ask more — what testing, what deployment, what monitoring, what handover documentation, what post-launch support, what exit clause.

The cases where a vendor is the right answer

The cases where a vendor is the right answer:

• Fixed-scope backend with a defined end. A REST API for a known data model, an ETL pipeline for a known source and destination, a custom CMS for a known workflow. The vendor writes the spec, builds to it, hands off the code, the project ends.
• Team does not have the skill in-house at all. A frontend team that needs a backend for the first time, a team that needs a specific technology (Rust, Elixir, a specific database), a team that needs a third-party audit.
• Third-party audit or security review. A penetration test, a SOC 2 audit, a HIPAA review. The team needs the audit, the audit is the deliverable, the team does not need the vendor to write code.

The three cases are the legitimate use of an outsourcing vendor. The right answer is a vendor that has shipped in the team’s stack, with a fixed scope, with a clear handover, with a clear IP clause.

The cases where the answer is “you do not need a vendor”

The cases where the answer is “you do not need a vendor”:

• The team has engineers who can build the backend. The right answer is a managed platform plus the team’s engineers. The platform handles the deploy, the database, the storage, the scaling, the health checks, the rollback. The team writes the backend.
• The backend is the product. The right answer is the team’s engineers, plus a managed platform, plus a consultant for the specific problem. The team that outsources the product codebase is a team that has given up the product.
• The team has the budget for one in-house engineer. The right answer is one in-house engineer at $120,000-180,000/year, plus a managed platform at $5-500/month. The total is $120,000-186,000/year, which is less than a 6-month outsourcing engagement at $50,000-150,000.

The three cases are the ones the SERP is targeting. The team’s pattern: the right answer is in-house plus platform, with optional consultant for the specific problem.

The contract red flags

The contract red flags, in order of how often they appear:

1. No fixed scope. The contract has a “phase 1” with a vague description. The right answer is a fixed scope with measurable deliverables. The wrong answer is a “phase 1” that the vendor can extend forever.
2. No IP transfer. The contract says the team owns the IP “upon final payment.” The right answer is “the team owns the IP from day one, with the license to the vendor’s pre-existing tools.” The wrong answer is “the team owns the IP upon final payment,” which means the team does not own the IP during development.
3. No code escrow. The contract does not say what happens to the code if the vendor disappears. The right answer is a code escrow arrangement with a third party. The wrong answer is “the team gets the code upon final payment,” which means the team does not have access to the code during development.
4. No exit clause. The contract has a fixed term with no early exit. The right answer is a 30-day notice clause. The wrong answer is a 12-month commitment with no exit.
5. No warranty. The contract does not say what the vendor will fix if the code is broken. The right answer is a 90-day warranty on bugs. The wrong answer is “the vendor will fix bugs for the duration of the contract,” which means the team has to renew the contract to get bug fixes.

The five are the parts of the contract the team should read carefully. The right answer is to walk away from a contract that has any of the five without negotiation.

The right way to evaluate a vendor

The right way to evaluate a vendor:

1. Ask for code samples. The vendor’s past projects, with the team’s permission to review. The team reviews the code for quality, style, and adherence to the team’s standards.
2. Ask for references. The vendor’s past clients, with permission to call. The team calls the references, asks about the timeline, the quality, the communication, the post-launch support.
3. Ask for team intros. The vendor’s engineers, with permission to interview. The team interviews the engineers, assesses the skill, the culture, the fit.
4. Ask for a trial project. A small project, with a fixed scope, with a fixed price, with a clear handover. The team uses the trial to evaluate the vendor’s work, communication, and reliability.
5. Ask for a sunset clause. A 30-day notice, with a clear exit, with the codebase handover on exit. The team uses the sunset clause to limit the risk.

The five are the right way to evaluate a vendor. The right answer is to walk away from a vendor that refuses any of the five.

How this fits the rest of the stack

The platform decision is also a cost decision. The deploy minutes, the build minutes, the database, the storage, the bandwidth, the workers, and the secrets each show up as a line item on the platform bill, and the team’s mental model for the project cost is the sum of those numbers. The right answer is to know the line items before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime size, the database tier, the storage, the bandwidth, the build frequency, and the secrets, and the calculator shows what the platform actually costs at the team’s actual usage.

Useful related references:

• services layer
• Postgres introduction
• environment variables

FAQ

What is a backend app development company?

A “backend app development company” is a vendor that builds or runs the backend of a web app. The category covers three buyer types: outsourcing shops, consulting firms, and managed platforms. The SERP is dominated by the first because that is the highest commercial intent for the keyword.

How much does a backend app development company cost?

Outsourcing shops charge $50-150/hour, with 6-month engagements typically at $50,000-150,000. Consultants charge $200-400/hour with 3-month engagements at $80,000-160,000. In-house engineers cost $120,000-180,000/year fully loaded. Managed platforms cost $5-500/month.

When should I use a backend app development company?

For fixed-scope backends (a known API spec, an ETL pipeline, a known data model), for teams that need a skill they do not have, and for third-party audits and security reviews. The wrong answer for a backend that is the product, for a regulated industry, and for ongoing development.

What should I look for in a backend app development company?

Code samples, SLAs, team resumes, references the team can call, and a migration path. The right answer is a vendor that has all five. The wrong answer is a vendor that refuses any of the five.

What are the contract red flags?

No fixed scope, no IP transfer, no code escrow, no exit clause, no warranty. The right answer is to walk away from a contract that has any of the five without negotiation.

When is the answer “you do not need a vendor”?

When the team has engineers who can build the backend, when the backend is the product, and when the team has the budget for one in-house engineer. The right answer is in-house plus platform, with optional consultant for the specific problem.

How do I evaluate a backend app development company?

Ask for code samples, ask for references, ask for team intros, ask for a trial project, ask for a sunset clause. The five are the right way to evaluate. The right answer is to walk away from a vendor that refuses any of the five.