Skip to main content

Stop Locking Yourself In: The Real Cost of Choosing Too Early

Every architecture choice has a cost. The wrong one just hides it longer. Pikku keeps your options open — same code, any runtime, no rewrites.

The Problem: Decisions That Age Badly​

Teams over-optimize early — for scale, for cost, or for the trend of the day. Then scale shifts, costs spike, and refactors begin.

🧱 Monolith Scaling Wall​

The Decision: "Keep it simple, build a monolith."

The Wall:

  • Can't scale parts independently
  • Deploy everything or nothing
  • One bottleneck affects all features

Result: Forced to rewrite when one feature needs different resources than the rest.

⚙️ Microservices Too Soon​

The Decision: "We'll need to scale, so let's start with microservices."

The Wall:

  • Coordination overhead kills velocity
  • Operational complexity from day 1
  • More infrastructure than features

Result: Slow to ship, expensive to run, team spends more time on DevOps than product.

💸 Serverless Lock-in​

The Decision: "Go all-in on [Cloud X] serverless."

The Wall:

  • Vendor-specific APIs everywhere
  • Costs spike unpredictably at scale
  • Migration means rewriting everything

Result: Stuck paying premium prices or facing 6+ month rewrite to switch.

The Pikku Way​

Instead of betting on one architecture upfront, Pikku lets you adapt:

  • Start with what's simplest for your current scale
  • Switch runtimes when economics or requirements change
  • Same code, same types, zero rewrites

Architecture becomes configuration, not commitment.

The Research Speaks​

The academic and regulatory consensus is clear: vendor lock-in creates real technical and economic barriers.

40% Cost Reduction​

"Hybrid architectures can run at 40% of the cost of single-cloud setups."

— Skedulix, IEEE Cloud 2020

Multi-cloud scheduling achieves significant cost savings by dynamically selecting optimal execution environments.

85% Fewer Violations​

"Mixing VM-based and serverless resources cut SLA violations by 85% and costs by 53%."

— LIBRA, 2021

Hybrid deployments provide better reliability and cost efficiency than single-architecture approaches.

Substantial Barriers​

"Vendor lock-in … demands substantial effort to overcome existing barriers."

— Opara-Martins et al.

Technical and economic switching costs create long-term constraints on architectural evolution.

Even regulators agree: egress fees and technical barriers discourage switching. The UK Competition and Markets Authority (CMA, 2025) highlighted these as major concerns in cloud markets.

Loading Cloud Cost Atlas...

Loading chart...

Keep the Cost of Changing Your Mind Near Zero​

The real cost of lock-in isn't just money — it's opportunity cost. Every month spent rewriting for a new runtime is a month not spent building features.

Pikku's Philosophy​

  1. Write portable code by default — No runtime-specific imports in your functions
  2. Choose your runtime at deploy time — Not at write time
  3. Switch without rewrites — Change config, not code
  4. Mix and match — HTTP on Lambda, WebSockets on a server, queues on BullMQ

Real-World Scenario​

// Day 1: Start with everything monolithic
import { PikkuExpressServer } from '@pikku/express'
import { PgBossQueueWorkers } from '@pikku/queue-pg-boss'

// HTTP server
const server = new PikkuExpressServer(config, services, createSession)
await server.start()

// Background jobs (using existing Postgres)
const queueWorker = new PgBossQueueWorkers(pgPool, services, createSession)
await queueWorker.registerQueues()

// Simple, fast to ship, low cost
// Month 6: Traffic spikes, don't want to think about scaling
import { corsHTTP } from '@pikku/lambda/http'

export const handler = async (event: APIGatewayProxyEvent) => {
  return await corsHTTP(event, services, createSession)
}
// Auto-scales, pay per request, no ops overhead
// Year 1: Launch enterprise edition, need on-premise deployment
import { PikkuUWSServer } from '@pikku/uws'

const enterpriseServer = new PikkuUWSServer(config, services, createSession)
await enterpriseServer.start()
// Runs fully off-cloud for compliance/data residency (uWS is way faster)
// Year 2: Lambda costs > VMs + maintenance
// Switch to dedicated workers for predictable load
import { BullQueueWorkers } from '@pikku/queue-bullmq'

const queueWorker = new BullQueueWorkers(redisConnection, services, createSession)
await queueWorker.registerQueues()
// Lower costs, full control, acceptable ops burden

Same logic, different economics.

The Bottom Line​

Build once, run anywhere. Keep the cost of changing your mind near zero.

Modern applications need flexibility more than they need early optimization. Pikku gives you that flexibility without sacrificing type safety, developer experience, or performance.

Get Started​

Further Reading​