Serverless for startups: what £20 a month buys you

In a serverless design, a function runs when a request or event needs processing. Static files can be delivered separately, and the database can use a capacity model appropriate to irregular traffic. This often suits an early product whose traffic arrives in bursts rather than at a steady rate.

The benefit is not that every service becomes free when the application is quiet. Stored data, logs, domain names, secrets and other services can still incur charges. Some network and database choices introduce a standing cost. Review the whole design before describing a system as pay-per-use.

Imagine a small public website with a contact form, a modest number of bookings and a staff administration screen. The files are small, API operations finish quickly and there is no large media library. That is a plausible workload to investigate against a £20 infrastructure target. It is an illustration, not a measured Nixim customer bill.

List monthly page views, transferred data, API calls, average execution time, database operations and retained storage. Include monitoring and backups. Then price that workload in the intended region using current service prices. Allow for currency conversion and applicable taxes; do not rely on introductory credits to establish the long-term baseline.

A single feature can change the economics. Uploading a large file costs more to store and deliver than sending a small JSON response. Generating an AI answer has a separate provider cost. A badly designed query can read far more data than it returns, while verbose logs may grow faster than the customer database.

Ask for a cost per useful event: a booking, a processed document or an active customer. Keep externally billed work behind server-side limits and permissions. A retry must not accidentally create a second paid job when the first request's outcome is uncertain.

Set budgets and alerts before real traffic arrives. Alerts tell someone that spending needs attention; they do not necessarily stop a service or create a hard spending ceiling. Add application-level rate limits, sensible upload limits and bounded retention where those controls fit the product.

Review actual usage after launch and compare it with the assumptions. If the product grows, an increasing bill can be healthy when it grows more slowly than useful activity. The target is an understandable cost model with no surprises, not an artificially low number that leaves out essential services.