My favorite kind of call is the rescue project.

A new client comes to us, frustrated. They just paid a ‘modern’ tech agency for a platform that’s completely unmaintainable.

We pop the hood, and it’s magnificent.

It’s a state-of-the-art “Cloud-Native,” “AI-Powered,” “Event-Driven,” “Serverless” system. A stunning monument to modern engineering, designed to handle 10 million concurrent users for a B2B app that has 500.

The previous agency didn’t solve the client’s problem. They solved their own problem: how to get “GenAI” “Kubernetes” and “VectorDB” onto their developers’ resumes.

Welcome to the most toxic trend in our industry: Resume-Driven Development as a Service (RDDaaS).

The RDDaaS Playbook (How to Scam Your Client)

It’s a brilliant, cynical business model, and it works like this:

Step 1: The Future-Proof Pitch You show the non-technical client a beautiful slide deck. You blind them with charts showing massive ROI, impressive KPIs, and tech buzzwords like “infinitely scalable,” “AI-powered,” and “Future GenAI-ready.”

Step 2: The Training Ground Your mid-level developers, who have only read about “RAG Pipelines” and “Kubernetes,” now get to learn them right on the client’s dime.

Step 3: The Over-Engineering Phase The project, which should have been a 3-month simple CRUD app, now takes 9 months. They’re not solving the client’s problem. They’re solving Google’s problem and Meta’s problem.

Step 4: The Successful Handoff The system is delivered. The chatbot confidently hallucinates the wrong phone number. The vendor’s developers proudly update their LinkedIn profiles. The vendor gets paid.

Step 5: The Victim’s New Life

The client is now the proud owner of an intelligent thing that requires a team of ex-FAANG SREs just to add a new form field.

Their new life includes:

  1. The Hiring Nightmare: Their in-house “IT guy,” John, quits after seeing a terraform script that spawns 15 AWS services (EKS, Lambda, VectorDBs…). The first real candidate who understands this mess demands $250k.

  2. The Wrong Web-Scale Performance: The app is slow. A simple request now makes 5 HTTP calls through a service mesh and a $0.02 call to gpt-4-turbo just to say “Hello.”

  3. The “WTF” Cloud Bill: The first few bills look okay (thanks, AWS Free Tier). Then, Month 4 hits. (Trust me, you really don’t want this.) The real bill arrives, full of NAT Gateways, EKS Control Planes, Managed Vector DBs (99% empty), and OpenAI API fees. Their plumbing costs 20x more than their app.

  4. The Simple Change Request: The client asks: “Can we just add a normal search bar? The AI one is too expensive.”

    • In the old monolith: 1 hour.
    • In this modern system: “Uh, that’s not how the RAG pipeline works. We’d have to re-architect the whole data flow. That’ll be a new 2 sprints.”

The Root Cause: Why Did This Happen?

Why does this scam always work? It takes two:

1. The Vendor’s Hidden Agenda: The client isn’t the customer. They’re the training ground. The agency didn’t solve the client’s problem “I need a reliable app”. They solved their own problem “Our developers need ‘GenAI’ and ‘K8s’ on their resumes”.

2. The Client’s Blinders: The client lets this happen. They get blinded by the ROI slides and tech buzzwords. They’re so terrified of being “legacy” that they actively forget to ask the two boring, critical questions:

  • “What is my actual problem?”
  • “What’s the Year 2 maintenance and cloud bill going to look like?”

The architecture was optimized for Imaginary Scale and Imaginary Intelligence, not Current Maintainability.

How to Not Get Scammed

This isn’t just a rant. This is a pattern I see many times. It’s the entire reason my philosophy is built on Boring Technology

The antidote to RDDaaS is to stop being impressed by buzzwords and start asking the questions that actually matter.

Next time a vendor pitches you a “Cloud-Native AI-Powered” solution, just ask them these things:

  • “Can you justify why we need Kubernetes for this?”
  • “Walk me through the full development process—from ticket to deployment—for adding one new database field to the ‘User’ model.”
  • “What is the fallback mechanism when the AI/RAG pipeline fails or hallucinates?
  • “Show me the Year 2 cloud bill for this architecture.
  • “What kind of engineer do I need to hire to maintain this after you leave?”

You don’t need FAANG-scale complexity. You need Product-Market Fit.

Start buying maintainable solutions that actually let you find it.