Serverless application development
on AWS Lambda and Firebase

Serverless fits four common patterns: spiky or unpredictable traffic (event-driven workloads, internal tools used heavily for short windows, scheduled batch jobs), event-driven architectures (file uploads triggering processing pipelines, webhook handlers, queue workers), backends where you don’t want to manage server fleets (small teams without dedicated DevOps capacity), and integration glue (API gateways routing to multiple services). For these workloads, serverless typically costs 30 to 70% less than equivalent traditional infrastructure once you account for actual usage patterns.

Serverless doesn’t fit four common patterns: long-running processes that exceed function timeout limits (Lambda caps at 15 minutes, Firebase Functions at 9 minutes for 1st gen and 60 for 2nd gen), predictable steady-state traffic where reserved instances are cheaper, applications with strict cold-start latency requirements where every millisecond matters, and workloads with substantial local state that doesn’t translate well to stateless functions. Honest scoping during discovery means we tell you which bucket your project is in before any code gets written. Backend development work covers the broader architecture decision framework.

AWS Lambda fits when you need the deepest ecosystem (SQS queues, DynamoDB, S3, EventBridge, Step Functions for orchestration) and willingness to manage IAM properly. Most complete feature set, steepest IAM learning curve. Firebase Functions fits when your frontend is already on Firebase (Firestore, Authentication, Hosting), making it the natural backend extension. Tighter ecosystem, less depth than AWS but faster to ship for typical web/mobile apps. Google Cloud Functions fits when you need Lambda-like capability in the GCP ecosystem (BigQuery, Cloud Pub/Sub, Cloud Storage), often chosen when teams already use GCP for data work.

Cloudflare Workers fits edge-compute use cases (request handling at the edge, A/B testing logic, security middleware) where global latency matters more than complex orchestration. Smaller per-invocation cost ceiling, V8 isolate runtime not full Node.js. Azure Functions fits when you’re already deep in the Microsoft ecosystem (Azure AD, Office 365 integrations, Azure SQL). We pick the platform that matches your existing stack and your team’s experience, not whichever has the loudest marketing in a given quarter. Custom software work covers the broader stack choice framework.

Serverless pricing combines two components: per-invocation cost (small fraction of a cent per function call) and per-millisecond runtime cost (depends on memory allocated to the function). AWS Lambda free tier covers 1 million invocations per month, Firebase Functions covers 2 million for 2nd gen functions. Realistic monthly costs after free tier: small SaaS backend with 5 million invocations averaging 200ms execution might run $20 to $80 depending on memory configuration. Mid-sized backend handling 50 million invocations might run $200 to $800. Enterprise workloads at hundreds of millions of invocations get more complex and benefit from cost-optimisation reviews.

Project pricing for our serverless work: typical greenfield serverless backend runs €15,000 to €45,000 depending on scope (5 to 20 functions, basic versus full observability, simple versus complex IAM). Migration of an existing application to serverless runs €20,000 to €80,000 depending on starting codebase quality. Our hourly rate is €60 to €65 across roles. Pricing and rates page covers the broader rate structure.

Cold starts are real but mitigatable. Lambda cold start on a Node.js function with light dependencies typically lands at 200 to 500ms, Java functions can hit 1 to 3 seconds. Mitigation options: reserved or provisioned concurrency (costs more but eliminates cold starts for the reserved capacity), lighter runtime choices (Node.js or Python over Java or .NET for cold-start-sensitive paths), code optimisation (lazy imports, smaller dependency graphs), and architectural choices (keeping cold-start-sensitive paths warm with synthetic traffic or scheduled invocations).

Vendor lock-in is real for some patterns, less for others. Pure function logic ports easily between platforms. Trigger configurations, IAM policies, and platform-specific services (DynamoDB streams, Firestore triggers, S3 events) don’t port. Mitigation: abstract platform-specific logic behind clean interfaces, keep business logic in pure functions tested independently of cloud SDK. Debugging is harder than traditional servers because you can’t SSH into the running function. Mitigation: structured logging from day one, distributed tracing (X-Ray, OpenTelemetry), local development tools (SAM CLI, Firebase Emulator Suite). Backend development covers the broader debugging and tracing approach.

Sometimes, often not. Worth it when: the application has unpredictable traffic patterns (spiky usage with idle periods), the team is small relative to ops burden of the current setup, you’re paying for reserved capacity that sits idle most of the time, or the application is already structured around clean function boundaries that translate to serverless cleanly. Migration cost typically pays back within 12 to 18 months in operational savings for these cases.

Not worth it when: the application has constant predictable load (reserved instances are cheaper), business logic is tightly coupled with long-running processes (background jobs that take hours, stateful workflows), or the existing infrastructure works fine and migration is being driven by serverless hype rather than concrete problems. Honest discovery sessions surface which bucket your situation falls into. Migration projects typically run 8 to 20 weeks and €25,000 to €80,000 depending on starting state and target architecture. Discovery call for situation-specific scoping.

Three security layers matter. First, IAM with least-privilege defaults: each function gets only the permissions it actually needs, with explicit policies rather than broad role assignments. We use IAM Access Analyzer (AWS) or equivalent tools to detect over-permissioned functions. Second, secrets management: API keys and database credentials live in AWS Secrets Manager, Google Secret Manager, or HashiCorp Vault, never in environment variables for production workloads. Third, code scanning: Snyk for dependencies, Checkov or tfsec for infrastructure-as-code, automated in CI before any deployment reaches production.

Compliance considerations: serverless platforms are typically certified for major compliance frameworks (SOC 2, ISO 27001, HIPAA on specific configurations, PCI DSS with constraints). These certifications belong to the cloud provider, not to your application. Your application still needs to be designed and operated in a compliance-respecting way. GDPR specifics: data residency matters (use EU regions for EU data), audit logging matters (CloudTrail, Cloud Audit Logs), and right-to-be-forgotten matters (deletion paths need to actually delete from all stores, including caches and event logs). More on how we work covers the broader compliance approach.

You own the code, the repository, the infrastructure-as-code definitions, the deployed cloud resources, and the cloud account credentials. IP transfers on payment as part of our standard terms. No proprietary frameworks that only Studio Ubique can maintain, no platform lock-in beyond what you’ve already chosen with AWS, GCP, Azure, or Cloudflare. Infrastructure-as-code (Terraform, CDK, SAM) means any team that understands these tools can take over.

Handover includes: codebase walkthroughs for the non-obvious decisions (cold start mitigation, retry logic, error handling boundaries), runbook for deployment and rollback, IAM policy documentation, cost monitoring setup walkthrough, and follow-up availability during the receiving team’s onboarding. For agency clients who’ve built serverless backends for their end clients with us under white-label arrangements, the handover is structured around the multi-stakeholder situation. White-label services cover the white-label handover structure.