Three rescue projects in numbers: what 'cheap developer' actually cost these founders

I didn't go looking for rescue projects. They found me — three founders in 18 months, each with the same story: "We hired someone cheap, it didn't work, now we need it fixed."

This post isn't about shaming cheap developers. It's about making the math visible. Every rescue project I took had a paper trail: the original quote, the hours burned, the cost to rebuild. When you put the numbers side by side, the "savings" disappear.

All three projects are anonymized. The numbers are real.

Project 1: the e-commerce site that couldn't handle 50 orders

Original scope: Shopify-like custom storefront for a niche product brand. Product catalog, cart, Stripe checkout, order management dashboard.

Original developer: Freelancer from a marketplace. €3,500 fixed price. Delivered in 6 weeks.

What went wrong:

The site looked fine with 5 products. At 50 products, the product listing page took 11 seconds to load — the developer was fetching every product with all images on every page load, no pagination, no caching. The cart used localStorage with no server-side validation, so customers could manipulate prices by editing browser storage. The Stripe integration was test-mode only — the developer had never switched it to production and didn't know how to handle webhooks.

What I found during the audit (8 hours, €640):

• No server-side cart validation — prices were client-side only
• Stripe webhooks weren't implemented — order confirmation relied on a redirect, which fails if the user closes the tab
• No database indexes — 50 products, but queries were scanning the full table
• No image optimization — 4MB product images served as-is
• Admin dashboard was a single 2,000-line React component
• No error monitoring, no logging, no way to know when things broke

The rebuild (62 hours, €4,960):

I didn't patch it. The cart security issue and missing webhook handling meant the payment flow was fundamentally broken. I rebuilt the storefront on Next.js with proper server-side cart management, Stripe webhooks, image optimization, and pagination.

Total cost to the founder:

A proper build from scratch would have been €7K–€9K. The "cheap" option cost nearly double — plus 3 months of a broken store.

Project 2: the SaaS that leaked customer data

Original scope: Multi-tenant SaaS for a consulting firm. Client portal, document upload, team management, basic reporting.

Original developer: A friend's nephew who "knows React." €2,000 paid informally over 4 months.

What went wrong:

There was no multi-tenancy. Every user could see every other user's data by changing the ID in the URL. The developer had built a single-user app and assumed "we'll add permissions later." Document uploads went to a public S3 bucket — anyone with the URL could access any file. Passwords were stored in plain text in the database.

The founder only discovered this when a client called and said "I can see someone else's documents."

What I found during the audit (6 hours, €480):

• No authentication middleware — every API route was publicly accessible
• Passwords in plain text (not hashed, not even salted)
• S3 bucket with public read access — every uploaded document was accessible via URL
• No input sanitization — SQL injection possible on the search endpoint
• No HTTPS enforcement on the API
• React app was a create-react-app ejected build with 847 npm vulnerabilities

The rebuild (78 hours, €6,240):

This was a security emergency. I took the site offline immediately, notified the founder about the data exposure, and rebuilt from scratch. Next.js with proper auth (Auth.js), row-level security in Postgres, private S3 with signed URLs, input validation on every endpoint.

Total cost to the founder:

A proper build: €8K–€11K. The "cheap" option cost more, exposed client data, and nearly killed the business relationship with their largest account.

Project 3: the mobile app that couldn't pass App Store review

Original scope: React Native event companion app. Ticket display, QR codes, push notifications, event calendar.

Original developer: Agency in a low-cost country. €5,000. Delivered a "working" build in 10 weeks.

What went wrong:

The app worked in the simulator but crashed on real devices. The developer had never tested on physical hardware. Push notifications were hardcoded to a single device token (the developer's phone). The QR code was a static image embedded in the app bundle — it didn't pull real ticket data.

Apple rejected the app three times: once for crashing on launch (missing entitlements), once for placeholder content (the developer had left "Lorem ipsum" in the settings screen), and once for the app not doing what the description claimed (QR codes didn't work).

After three rejections in 6 weeks, the founder came to me.

What I found during the audit (4 hours, €320):

• App crashed on iOS 17 — developer built against iOS 16 only
• Push notification implementation was non-functional — single hardcoded token
• QR code was a static PNG, not generated from ticket data
• No API calls — all data was hardcoded JSON in the app bundle
• Expo was 3 major versions behind with known critical bugs
• No CI/CD — builds were done manually on the developer's machine

The rebuild (54 hours, €4,320):

I rebuilt the app from scratch on current Expo. Real API integration, real push notifications via Expo Notifications, dynamic QR codes, proper offline storage. Passed App Store review on first submission.

Total cost to the founder:

A proper build: €6K–€8K. The agency's €5K "savings" cost the founder their entire launch season.

The pattern

All three projects share the same failure mode:

1. Low quote attracts the founder. The price sounds reasonable because the founder doesn't know what "reasonable" means for software.
2. Developer delivers something that looks like it works. Demos in a browser, screenshots in Slack, a staging link that loads. The surface looks fine.
3. The invisible work is missing. Security, error handling, production configuration, edge cases, testing. Everything that separates a demo from a product.
4. The founder discovers the problems in production. Usually through a customer complaint, a security incident, or a failed App Store review.
5. The rebuild costs more than building it right the first time. Because now there's urgency, lost revenue, and the overhead of auditing what exists before building what should.

How to avoid this

I wrote a detailed red flags checklist for vetting developers. The short version:

Ask for production references. Not portfolio screenshots — URLs of things that are live, processing real transactions, serving real users. If a developer has never shipped to production, they'll miss everything that only shows up in production.

Ask what happens when. "What happens when a payment fails?" "What happens when two users edit the same record?" "What happens when the API is down?" A developer who has thought about failure modes will answer immediately. One who hasn't will say "we'll handle that later."

Pay for the spec phase separately. A good spec before the build costs €500–€1,000 and reveals whether the developer understands your problem. If the spec is vague, the code will be too.

Get a breakdown, not a lump sum. If a developer can't tell you how many hours go to auth vs. core features vs. testing — they haven't scoped the project. They're guessing. Here's what a real breakdown looks like.

If you're sitting on a project that's broken, half-built, or stuck — I do rescue builds. Let's look at what you have and what it would take to fix it. The audit is usually 4–8 hours and tells you whether to patch or rebuild.