Frontend vs. Backend Development Cost — Why Quotes Do Not Split Them, and How to Map the Line Items

Search for frontend development cost or backend quote rates and little comes back. It is not that the work has never been documented. It is that the quotes actually being issued do not split the two.

None of the 81 quotes Freesi issued in 2026 (unique projects, duplicates removed) carry a frontend or backend line item. Types are recorded by deliverable — "API integration / backend," "web app / SaaS platform" — and within each one, screens and server are priced as a single unit. The median across those 81 quotes is 380,000 KRW (approx. USD 280), stated as a project total. The sample skews toward small, one-off jobs, which is why the median sits low. The underlying aggregation is in the 2026 quote report.

So this guide does not offer a split ratio such as "40% frontend, 60% backend." There is no sample to derive one from. A ratio invented without data cannot be used to check a quote you have received, and it installs a false benchmark in its place. What follows instead is what actually moves each side of the number, and which published rate-table item belongs to which side.

Splitting the work into two contracts does split the quote. It does not shrink the total. What the two quotes added together usually leave out is integration verification and the effort of arbitrating where one side's responsibility ends — work a bundled contract absorbs inside a single vendor. That comes back in the split-versus-bundled section below.

When two quotes for what sounds like "one website" differ by two or three times, it is usually one of these four.

1. Screen count — and counting only user-facing screens is the common mistake. Clients count the screens their users will see. In practice an admin side is usually needed as well, and it can carry more screens than the user side. Check whether the screen list in your request includes admin screens before anything else.

2. Responsive scope. Desktop only, or mobile as well, changes the effort on the same screen. On the published rate table, mobile layout support for an admin dashboard is an add-on of 800,000 KRW (approx. USD 580), which is a fair measure of how large this variable is.

3. State complexity. Does a screen only display information, or does it hold in-progress input, filters, and selections that affect one another? Two query screens tangled with filters and sorting can cost more than ten static information pages.

4. Whether design is supplied. Handing over finished design files (Figma or equivalent) and asking the vendor to work out the layout as well are different scopes. "Just make it look good" is an unbounded requirement: revision rounds repeat, and the cost of those rounds sits in neither quote until it becomes a dispute.

A backend quote is harder to check because none of it is visible on screen. These four account for most of the variance.

1. Authentication and permissions. "A login" and "a login where different roles see different things" are different builds. That is why the rate table prices an additional permission tier as an add-on of 400,000 KRW (approx. USD 290). Split roles into three or four tiers and this line alone passes 1,000,000 KRW (approx. USD 720).

2. Number of external integrations. Payments, social login, shipment tracking, public data APIs — each one attached is separate effort. The effort is not in the successful response; it is in what happens when the call fails. Retries, token refresh, webhook receipt, and logging all live here.

3. Real-time or not. Data refreshed once a day and data pushed as it changes are different architectures. It is the same reason the large tier of API server and backend builds on the rate table (15,000,000 KRW / approx. USD 10,900 and up, project total) is defined by real-time and high-volume requirements.

4. Data volume and structure. The more kinds of data and the more relationships between them, the more design effort, and a structure set wrong early is expensive to change later. [Why DB design and ERD have a major impact on your quote](/guide/database-design-impact) covers that separately.

The table below rearranges already-published rate-table items by which side of the stack the money mostly goes to. The amounts are unchanged from the source; nothing here is a new figure.

One thing reads straight off that table. The backend has standalone rates; the frontend does not. The "website / web app" rows are screens and server priced together. The reason a market rate for frontend work alone is hard to find is structural, not accidental.

Feature-level add-on rates allow a slightly finer split. Below are the add-ons that attach to the base admin dashboard package (3,500,000 KRW / approx. USD 2,540, project total); the full per-feature breakdown is in admin dashboard development cost.

Drawing one more screen (600,000 KRW / approx. USD 430) and building one more permission tier (400,000 KRW / approx. USD 290) are not far apart in price. Screens are visible and permissions are not, but they cost about the same — which also means the single line reading "3 permission tiers" on a quote is worth roughly two or three screens.

This mapping is a center of gravity, not a boundary. No item is 100% one side. A view screen carries the server work that feeds it data; a permission tier carries the screen branching that reflects it. Splitting by percentage requires the actual task breakdown for that specific project, and that comes from the basis of estimate on the quote, not from a rate table.

When splitting works

When one side already exists. Attaching new screens to a server already in operation, or building the screens in-house and outsourcing only the server. Here there is nothing to split in the first place — you are contracting one side.

When you have that skill in-house. If you have a frontend developer on staff and are outsourcing only the backend, that person can review the API specification, so the boundary is far less likely to fail.

When scale forces parallel work. Even then, someone on your side has to coordinate the two.

When bundling works

A small project built from scratch. Coordination cost exceeds whatever the split saves.

When nobody on your side can review an API specification. This condition is close to decisive. Split the contract without someone who can read the specification and, when the two vendors blame each other, no one is in a position to judge.

Stated plainly, the hidden cost of splitting is three things. First, integration verification: connecting screens to server and getting them working is frequently in neither quote. Second, the responsibility boundary: determining whether a screen failing to render is a response-format problem or a rendering problem takes time, and that time goes unbilled until it surfaces as schedule. Third, schedule synchronization: when the backend runs late the frontend waits, but the frontend contract term keeps running.

So if two quotes added together look smaller than a bundled one, the right move is to find which of those three the difference is hiding in. Handing the whole thing to one full-stack contractor sits in the same logic: coordination cost disappears, but that person's stronger and weaker areas show up directly as variance in the deliverable.

Where a quote covering both sides later goes wrong is fairly predictable.

1. Who writes the API specification. The document stating what you request at which address and what comes back. Confirm whether the backend writes it, the frontend supplies requirements for it, or nobody writes it at all. This is the single most commonly missing item in split contracts.

2. Where the boundary sits. Excel export, for example, can be built on the screen or generated as a file on the server. Confirm as a line item which quote it is in.

3. Whether the screen list includes admin screens. Counting only user-facing screens and signing, then receiving admin screens as a change order, is common.

4. Whether an integration test environment is in scope. External integrations such as payments require a sandbox where no real transaction occurs, and setting that up is separate work.

5. Deployment and maintenance scope. Getting the build onto a server and keeping it running is separate from development. On an annual basis, maintenance is generally budgeted at 10–20% of build cost per year — an annual rate, not a monthly one — and the quote should state whether that covers the frontend only or server operations as well. The estimation methods are set out in [monthly maintenance costs and SLA standards](/guide/maintenance-cost-sla).

Reading a quote line by line in general is covered in how to read an outsourcing quote.