Is serverless actually cheaper than a server?

Only if you are idle most of the time. Billing per millisecond of execution is a discount when a system sits quiet for twenty hours a day and a penalty when it works steadily through business hours. The first thing we do is look at your real traffic shape, and if a running machine is the cheaper answer we will say so rather than sell you the more fashionable one.

What is a cold start and will our users notice it?

When a function has not run recently the platform has to stand the environment up before your code executes, which adds somewhere between roughly a tenth of a second and a couple of seconds to that one request. Whether anyone notices depends on the path — a nightly report does not care, a checkout call absolutely does. We measure it on your real bundle, not on a sample function, because dependency weight is what drives it.

Can we move our existing application onto this?

Sometimes, and it depends on three things — whether the code holds state in memory or on local disk, whether any request runs longer than the platform's execution limit, and how it talks to the database. Applications that write files next to themselves are the usual blocker, because functions get no durable local disk. That work is a rewrite of specific parts, not a redeploy, and we scope it honestly before quoting.

How do we avoid a surprise bill?

By setting the ceilings during the build rather than after the first incident. Automatic scaling with no upper bound is exactly how a scraper, a retry loop or a misconfigured cron turns into a very expensive weekend. Every function we deploy has a concurrency cap, a timeout, and a budget alarm that reaches a person.

What happens when a function fails halfway through?

That has to be designed, not hoped for. Event-driven platforms retry automatically, which means your code must be safe to run twice on the same input — otherwise a retry sends the invoice a second time. Anything that fails past its retries goes to a dead-letter queue so the event is kept rather than lost, and somebody is alerted that it landed there.

Lambda or Cloudflare Workers — how do you choose?

By where the work sits and where the data is. Workers run close to the visitor and start fast, which suits edge logic, routing and light APIs. Lambda has the deeper integration with the rest of an AWS estate and fewer runtime restrictions, which matters when the function needs to talk to services already living there. Data transfer costs differ between platforms too, and that difference is worth real money for anything file-heavy.

Cloud, DevOps & Infrastructure

Serverless architecture build

Systems built on Lambda, Cloudflare Workers or Cloud Functions — with the idle-time arithmetic done first, and hard ceilings on concurrency and spend before anything goes live.

From: $1,500–$20,000
Typical time: 2–10 weeks
Usually bought by: Startups

What this actually solves

Two situations bring people to this page. The first is a bill that stopped making sense. Machines are running twenty-four hours a day to serve traffic that arrives in bursts - webhooks that fire when a customer does something, image processing that happens after an upload, a report that runs at two in the morning — and the invoice is being paid for the twenty hours of doing nothing rather than the four hours of work.

The second is scale that arrives unevenly. A campaign, a season, a launch: traffic triples for three days and then vanishes. Sizing permanent machines for the peak means paying for the peak all year, and sizing them for the average means the peak is the moment the system falls over — which is also the moment it matters most.

Serverless answers both, but only for the right shape of workload, and the honest version of this service starts by testing whether yours qualifies. Per-millisecond billing is a discount on idleness. If your system is genuinely busy through the working day, a running machine is cheaper and simpler, and we would rather tell you that in week one than build you something clever that costs more than what you already have.

There is a second constraint worth knowing before you commit. Functions have no memory between invocations and no durable local disk, so everything that has to persist — sessions, uploads, intermediate files — has to live in a database or object storage. For a new build that is a design decision. For an existing application that writes files beside itself, it is the largest single piece of work in the project, and it is better identified now than discovered in week six.

How the work runs

Test whether serverless is the right shape at all. We look at the real traffic pattern, the latency floor on each path, the longest-running operation, and how much of the day the system is actually doing something. This step sometimes ends with a recommendation not to proceed, and that is a legitimate outcome of it. Two to four days.
Design the functions, the triggers and the boundaries. What invokes each piece — an HTTP request, a queue message, a schedule, an upload event — where state lives, what each function is permitted to touch, and what breaks if any single one of them fails. Permissions are scoped here deliberately, because a function that can delete the production database has a blast radius equal to the whole business. Three to five days.
Build it with the infrastructure described in code. Twenty functions, their triggers, their permissions and their environment are far too much to click into a console and remember six months later. Terraform or OpenTofu, or the platform's own definition format, so environments are reproducible and reviewable — with the state file in a locked remote backend and never in the repository, because it contains secrets. Credentials go into a secrets manager rather than into the deployment bundle. One to four weeks, depending on the number of functions and integrations.
Set the ceilings and the failure paths before anything goes live. Concurrency maximums per function, execution timeouts, a database connection strategy that survives hundreds of simultaneous invocations, dead-letter queues for events that exhaust their retries, and a budget alarm that reaches a human. Two to four days.
Measure the cold path, then hand over properly. Cold start measured on the real deployed bundle rather than a trivial example, load applied along the paths users actually take, and logs and traces wired up so that "it was slow yesterday" becomes a question with an answer. Runbook, architecture notes, and the deployment pipeline handed across. Three to five days.

What moves the price

The range is $1,500–$20,000 across 2–10 weeks, and three factors decide where a given build sits in it.

How many functions there are, and how many things trigger them. A single webhook receiver sits at the bottom of the range. An event-driven system where uploads trigger processing, processing triggers notification, and failures route to review is a different build with a different testing burden — because most of the effort in event-driven work is in the paths where something goes wrong.

Whether the data layer is ready for it. This is the cost people do not anticipate. Traditional databases allow a fixed number of simultaneous connections, sized for a handful of application servers. Hundreds of concurrent function invocations will exhaust that limit precisely when traffic proves the product is working. Introducing a connection pooler, or moving to a data store designed for that access pattern, can be a meaningful part of the project.

Whether this is a new build or a migration off something running. Building fresh is straightforward. Moving a live system means running both in parallel, cutting over carefully, and keeping a route back — and the route back is not optional, because the fastest fix for an unexplained failure is always to return to the last thing that worked.

What usually goes wrong

Serverless is chosen for a workload that is busy all day. The per-millisecond model is sold as cheaper without anyone checking the idle fraction. A system handling steady traffic through business hours will frequently cost more on functions than on a modest machine, while also being harder to debug and slower on its first request. The arithmetic takes an afternoon and almost nobody does it before committing.

Concurrency and spend are left unbounded. Automatic scaling is the headline feature and the platform defaults are generous. Left alone, a retry storm, a scraper or a recursive trigger — a function that writes to the storage bucket that invokes it — will scale exactly as instructed and bill you for every millisecond. Ceilings and a budget alarm cost nothing to set and are the single most valuable thing added during a build.

Hundreds of functions are pointed at a database sized for one server. Each invocation opens its own connection, the limit is reached, and the error is "too many connections" at the busiest minute of the busiest day. It looks like a traffic problem and it is an architecture problem, and the fix — a pooler, or a data store suited to the pattern — is far cheaper to design in at the start than to retrofit under load.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Is serverless actually cheaper than a server?: Only if you are idle most of the time. Billing per millisecond of execution is a discount when a system sits quiet for twenty hours a day and a penalty when it works steadily through business hours. The first thing we do is look at your real traffic shape, and if a running machine is the cheaper answer we will say so rather than sell you the more fashionable one.
What is a cold start and will our users notice it?: When a function has not run recently the platform has to stand the environment up before your code executes, which adds somewhere between roughly a tenth of a second and a couple of seconds to that one request. Whether anyone notices depends on the path — a nightly report does not care, a checkout call absolutely does. We measure it on your real bundle, not on a sample function, because dependency weight is what drives it.
Can we move our existing application onto this?: Sometimes, and it depends on three things — whether the code holds state in memory or on local disk, whether any request runs longer than the platform's execution limit, and how it talks to the database. Applications that write files next to themselves are the usual blocker, because functions get no durable local disk. That work is a rewrite of specific parts, not a redeploy, and we scope it honestly before quoting.
How do we avoid a surprise bill?: By setting the ceilings during the build rather than after the first incident. Automatic scaling with no upper bound is exactly how a scraper, a retry loop or a misconfigured cron turns into a very expensive weekend. Every function we deploy has a concurrency cap, a timeout, and a budget alarm that reaches a person.
What happens when a function fails halfway through?: That has to be designed, not hoped for. Event-driven platforms retry automatically, which means your code must be safe to run twice on the same input — otherwise a retry sends the invoice a second time. Anything that fails past its retries goes to a dead-letter queue so the event is kept rather than lost, and somebody is alerted that it landed there.
Lambda or Cloudflare Workers — how do you choose?: By where the work sits and where the data is. Workers run close to the visitor and start fast, which suits edge logic, routing and light APIs. Lambda has the deeper integration with the rest of an AWS estate and fewer runtime restrictions, which matters when the function needs to talk to services already living there. Data transfer costs differ between platforms too, and that difference is worth real money for anything file-heavy.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Serverless architecture build All Cloud, DevOps & Infrastructure services