Web App Development Service: What You Are Actually Buying (And When to Skip It)

A “web app development service” is one of three things depending on who is selling it: an outsourced dev shop that builds the app for you, a consulting firm that advises your team, or a managed platform that runs the deploy, database, and observability so your team can build the app themselves. The search results for the keyword are almost entirely the first kind, which is why most of the pages feel like sales decks. The third kind is what most teams actually need, and it does not have a sales team because the right answer is a platform, not a vendor.

This post is for the founder, technical lead, or solo developer who typed the keyword and got back 30 outsourcing companies and one Wikipedia article. The three categories above are the shape of the market. The rest of the post is the part the search results do not show — when each one is the right answer, when each one is the wrong answer, and what to look for in each.

The three things the keyword actually means
Outsourcing: when it is right, when it is wrong
Consulting: the underrated middle path
Managed platforms: the default most teams should pick
The cost comparison the search results skip
How to evaluate a web app development service
What a good managed platform actually looks like
FAQ

The three things the keyword actually means

When a team searches for a “web app development service,” they are usually one of three buyers:

A non-technical founder who needs someone to build the app. The market for this buyer is the outsourcing shops at the top of every SERP. The deliverable is code, the contract is fixed-price or time-and-materials, and the artefact is a codebase the founder inherits.
A technical team that needs help on a specific problem — performance, scaling, a database migration, an audit. The market for this buyer is the consulting firms, which usually do not rank for the keyword because their buyers are finding them through referrals, not Google.
A technical team that wants to ship faster without hiring more ops people. The market for this buyer is the managed platforms — Render, Railway, Fly.io, Vercel, Netlify, RunxBuild, and a few dozen smaller ones. The deliverable is not code, the contract is monthly, and the artefact is a running service with deploy logs.

The reason the SERP is dominated by category 1 is that category 1 is the largest buyer pool and the highest commercial intent for the keyword. The reason your team is probably not category 1 is that the people reading this post already know how to build the app. The question is what to do with it once it is built.

The rest of this post is the part for category 2 and category 3 buyers. If you are category 1, the search results are actually the right answer, and the rest of the post is not for you.

Outsourcing: when it is right, when it is wrong

Outsourcing a web app is the right answer in two situations and the wrong answer in most others.

Right when the app is a fixed scope with a defined end. A marketing site, a custom CMS for a known workflow, an internal tool for a known process — these are the cases where outsourcing works. The vendor writes the spec, builds to it, hands off the code, and the project ends. The contract is fixed-price, the timeline is months, and the deliverable is a codebase the in-house team can maintain.

Right when the team does not have the skill in-house at all. A team that needs a mobile app and has never built one is a real candidate for outsourcing, because the gap is too wide to close in the timeline. The trade-off is real: the team is paying for the vendor’s learning curve, the codebase will reflect the vendor’s preferences, and the maintenance will be the team’s problem after the contract ends.

Wrong when the app is the product. A startup whose product is a web app should not outsource the app. The codebase is the product, the iteration speed is the moat, and the team’s understanding of the codebase is the asset. Outsourcing the product codebase is a fast way to ship a first version and a slow way to ship a second version. The two cases are very different, and the second one is the one most teams are actually in.

Wrong when the team is in a regulated industry. Healthcare, fintech, and government work have compliance constraints that compound with every external party. An outsourcing vendor adds another party to the audit. The math usually works out to “the vendor costs more than an in-house engineer would have” once the audit overhead is included.

Wrong when the budget is for ongoing work. Outsourcing is structured around projects, not products. A team that needs ongoing development has to either keep re-scoping the project (which is what agencies do, badly) or hire the vendor’s people directly (which is what happens when outsourcing “works”). Both paths cost more than hiring in-house at the same point in the product’s life.

Consulting: the underrated middle path

The middle path is the one the SERP does not show. A consultant is a senior engineer or architect who joins the team for a defined period, helps with a specific problem, and leaves when the problem is solved. The deliverables are not a codebase — they are a plan, a code review, an architecture decision, or a hands-on implementation of one feature.

Consulting is the right answer when:

The team has a specific problem it cannot solve alone. Database performance, scaling, a security audit, a migration off a legacy system. The consultant has solved the same problem for other teams and brings a perspective the in-house team does not have.
The team needs an architectural second opinion. The team is about to commit to a direction (a database, a queue, a deploy platform) and wants a senior voice to challenge the assumptions. The consultant reads the code, asks the questions, and writes the recommendation.
The team is migrating to a new stack. A consultant who has done the same migration 10 times will get the migration done in a quarter. The in-house team, doing it the first time, will get it done in a year. The cost of the consultant is a third of the in-house cost, and the team gets the migration done.

Consulting is the wrong answer when the team wants ongoing development. Consultants do not write features at the rate in-house engineers do, and the cost-per-feature is higher. The trade-off the consultant is buying is expertise, not capacity.

Managed platforms: the default most teams should pick

A managed platform is the third category, and it is the one most teams in the search-results audience are actually looking for. The pitch is: the platform runs the deploy, the database, the storage, the logs, the scaling, the health checks, and the rollback. The team writes the app. The platform runs it.

The reason this is the right default for most teams:

The team owns the codebase. The codebase is the team’s, the platform is the platform’s. When the team outgrows the platform (which happens to a small percentage of teams), the team takes the codebase and goes elsewhere. The platform lock-in is on the deploy, not on the code.
The platform is the team’s first ops hire. A managed platform that does the deploy, the database, the storage, the logs, the scaling, the health checks, and the rollback is the team’s first ops hire, but it costs $5-50/month instead of $100,000/year. For a small team, the math is obvious.
The platform gets out of the way. The team writes the app the same way it would write any other app. The platform’s contract is small: provide a package.json or a Dockerfile, a port to listen on, a health check. The team does not learn a new framework to use the platform.

The reason this is the wrong default for some teams:

The platform is the wrong shape for the workload. A small static site does not need a managed platform. A team that already has a Kubernetes cluster and an ops team does not need a managed platform. The right answer for those teams is a static host or a self-managed cluster.
The team needs a feature the platform does not have. Most managed platforms have a long list of features, but the feature the team needs is sometimes not on the list. The right answer is to check the feature list before committing, not to assume.

The cost comparison the search results skip

The search results for the keyword do not show the cost comparison, because the cost comparison makes the outsourcing answer look bad. The rough math:

Outsourcing shop at $50-150/hour. A 6-month engagement at 1,000 hours costs $50,000-150,000. The deliverable is a codebase the in-house team inherits.
Consultant at $200-400/hour. A 3-month engagement at 400 hours costs $80,000-160,000. The deliverable is a plan, a code review, or a specific feature.
In-house engineer at $120,000-180,000/year fully loaded. A full-time engineer costs $120,000-180,000/year. The deliverable is ongoing development.
Managed platform at $5-500/month. A managed platform costs $5-500/month for a typical web app. The deliverable is a running service.

For a small team with a defined first version, the in-house engineer plus the managed platform is almost always cheaper than the outsourcing shop, and the codebase stays in the team. For a team that needs a specific problem solved, the consultant plus the managed platform is the cheapest path. The outsourcing shop is the right answer only for the two cases above.

The cost that does not show up in any of these numbers is the cost of the team not understanding the codebase. A team that outsourced the codebase has to spend the first six months understanding the codebase before they can iterate on it. The opportunity cost of that six months is usually more than the cost of the outsourcing.

How to evaluate a web app development service

For the cases where outsourcing or consulting is the right answer, here is the evaluation checklist.

For outsourcing:

The vendor’s portfolio includes three or more projects in your stack. A vendor that does not have portfolio in your stack will be learning on your dime.
The vendor’s references are in your industry. A vendor that has built marketing sites for restaurants is not the right vendor for a fintech.
The contract has a clear definition of “done” with measurable criteria. A contract without a clear “done” is a contract where the vendor can run forever.
The vendor’s engineers are the engineers who will work on the project, not a sales-team promise of “senior engineers” that turns into “the most junior people on the bench.”
The vendor’s code review and testing process is documented. A vendor without a documented process produces code that the in-house team will rewrite.

For consulting:

The consultant has a public track record of solving the specific problem. A blog, a conference talk, a paper, or a code contribution to a relevant open-source project.
The consultant’s deliverable is a written report or a code change, not “advice.” A consultant who gives advice in meetings is a consultant who charges for the meeting, not the outcome.
The consultant’s hourly rate is high, but the engagement is short. A consultant who wants to stay for a year is not a consultant, they are a contractor.
The consultant will tell the team things the team does not want to hear. A consultant who agrees with the team on everything is a consultant who is not being useful.

For a managed platform:

The platform’s pricing is on a single page, with the line items visible. A platform that hides pricing is a platform that will surprise the team on the bill.
The platform’s features the team needs (database, storage, deploy logs, scaling, custom domains) are in the base plan, not in an enterprise add-on.
The platform’s documentation has a working example for the team’s stack. A platform that does not have a Node.js example is a platform that does not support Node.js well.
The platform’s status page is public and has a track record of being honest. A platform that hides outages is a platform that has more outages than the team thinks.

What a good managed platform actually looks like

A good managed platform for a web app has the same shape regardless of vendor. The features the team needs are:

A Git-based deploy. Push to main, the platform builds, deploys, and runs the new version. No FTP, no manual uploads, no “did you remember to push the build artifacts.”
A managed database. Postgres, MySQL, or whatever the team needs, with automated backups, point-in-time recovery, and a connection string the app reads at startup.
A managed storage layer for blobs. S3-compatible, with the access keys managed by the platform, not by the team.
Deploy logs and runtime logs in the same place. The team can see what the app did at every step of the deploy and at every step of the request.
A health check that the platform uses to decide when to roll back. The platform restarts the app when the health check fails, and the rollback is automatic.
A custom domain with managed TLS. The team does not have to renew a cert every 90 days.
Environment variables in a secure store. The team does not have to put the database password in the repo.
A pricing model that scales with usage, not with the team’s size. A platform that charges per user is a platform that penalises the team for growing.

A platform with all eight is a platform the team can build on for years. A platform with five is a platform the team will outgrow. A platform with three is a platform the team will leave in a year.

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:

FAQ

What is a web app development service?

A “web app development service” is one of three things: an outsourcing shop that builds the app, a consulting firm that advises the team, or a managed platform that runs the deploy and database so the team can build the app. The keyword is dominated by the first kind because the third kind does not need to rank for the keyword — its customers find it through referrals and the platform’s documentation.

How much does a web app development service cost?

Outsourcing shops charge $50-150/hour, with 6-month engagements typically costing $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. The right choice depends on the team’s stage, scope, and in-house capability.

When should I outsource a web app?

Outsourcing is the right answer for fixed-scope projects with a defined end (marketing sites, internal tools, custom CMS) and for teams that need a skill they do not have in-house. Outsourcing is the wrong answer for a product that is the company’s main asset, for regulated industries, and for ongoing development.

When should I use a managed platform instead of a development service?

A managed platform is the right default for any team that has engineers who can build the app. The platform handles the deploy, the database, the storage, the scaling, the health checks, the rollback, and the secrets. The team writes the app, the platform runs it. For most teams in the search-results audience for this keyword, the managed platform is the right answer.

What should I look for in a managed platform?

A Git-based deploy, a managed database with backups and recovery, a managed storage layer, deploy and runtime logs in the same place, a health check with automatic rollback, custom domains with managed TLS, secure environment variables, and usage-based pricing. A platform with all eight is one the team can build on for years. A platform with three is one the team will outgrow.

Can I use a managed platform and outsource parts of the project?

Yes, and this is the most common pattern. The team uses the managed platform for the deploy and database, the in-house engineers for the product code, and the consultant for the specific problem (performance, scaling, a migration). The combination is cheaper than any single-vendor answer.

What is the difference between a PaaS and a web app development service?

A PaaS is a platform that runs the app. A web app development service is a vendor that builds the app. The two are different categories, and the search results blur them because the keyword is broad. The right answer for most teams is a PaaS plus in-house development, with a consultant or a small outsourcing engagement for the specific problem the team cannot solve alone.