You shipped it with AI.
Now make it production-ready.
A fixed-price production-readiness review for apps built with Cursor, Claude Code, Lovable or Replit. I find what breaks when real traffic arrives, what it costs you, and what to fix in what order. Report in your inbox within one week of access.
Founder rate for the first three teardowns — $2,500 instead of $3,500 — in exchange for a public case study and a named testimonial.
Talha Imtiaz
DevOps engineer
Software engineer first, DevOps second — so I read the codebase, not just the infrastructure around it. You work with me directly, start to finish.
~80 → 400+concurrent users on GKE, by scaling on product events rather than CPUI take 1–2 engagements at a time alongside my full-time role — async-first, ~4h daily US/EU overlap.
- Price
- $2,500$3,500
Full refund, no questions asked.
Fixed. Not an estimate that grows once I see the repo.
- Timeline
One week
Report in your inbox within one week of access.
- Payment
50% at booking, 50% on delivery.
Read a full sample report before you pay.
Seven things AI-built apps almost always get wrong on the way to production.
None of these are indictments of how you built it — they're what gets skipped when the priority is shipping something people want. They only start costing you once people actually turn up.
- 01
No environment separation
One project, one database, one set of keys. Staging is a branch, and production is where you find out.
- 02
No rollback path
Deploys go forward only. When a change breaks checkout at 9pm, the fix is another deploy written under pressure.
- 03
Secrets in the repo
API keys committed early and never rotated, still valid, still in the history after you delete the line.
- 04
Unbounded LLM API spend
No per-user cap, no budget alert, no cache. One loop or one scraper turns a model bill into a runway problem.
- 05
No rate limits
Every endpoint answers as fast as it's asked. The first bot to find your signup route decides your capacity.
- 06
Database and auth wired for a demo
Permissive access rules, no connection pooling, no migration path, and a session model that was fine for ten users.
- 07
No observability
When a user says it's broken, there's nothing to look at. You learn about outages from the people paying you.
Not ready for the full teardown? Start with the repo.
Read access to your GitHub or GitLab. Nothing else — no cloud credentials, no IAM role, no call.
Within 72 hours you get a written read on what breaks first in your deploy path: CI config, Dockerfiles, IaC, Kubernetes manifests, secrets handling, and your rollback story.
$900
Full refund, no questions asked.
Credited in full against the teardown for 60 days.
People who managed me and shipped production with me.
Three things land within a week — all yours to keep.
A written report
Your architecture drawn as it really runs — not a slide deck.
PDF + web
A ranked fix list
Every failure mode ordered by blast radius, quick wins flagged.
Severity × effort
A recorded readout
A 60-min call walking your engineers through it. Yours to replay.
60 minutes
Things break quietly for weeks before anything shows up on a dashboard.
- 01
Traffic grows
More users, more queries, more background jobs. Nothing looks wrong yet.
- 02
Something runs out
A connection pool, a socket limit, a disk. It hits a ceiling nobody set an alert on.
- 03
It takes the rest down
Health checks fail on services that are fine, deploys freeze, and now it is an outage.
Six things I go through, at the level of your actual config and code.
Your architecture, as it is
One true diagram of what's actually running — often the first time a team sees it whole.
Failure modes, ranked
Ordered by likelihood × blast radius, so you fix what matters first.
Where the money leaks
Idle capacity, oversized nodes, and forgotten environments still billing you.
What breaks first under load
Which piece gives way first, and roughly when — load-tested when it settles an argument.
Observability gaps
What's failing silently today — the breaks that never reach an alert.
Deploy safety & rollback
What a bad Friday-5pm deploy does, and how you get back to the last good state.
Quick wins are flagged separately — the fixes your team can ship in an afternoon, with the exact config or commands. Some teams stop there, and that’s a fine outcome.
A written intake, quiet work in the middle, one recorded call at the end.
Step 1
A written questionnaire, no call
Access and intake
Fifteen minutes of your time.
You spin up a read-only role and answer ~10 questions about what your team already worries about. Whatever you flag there goes to the top of the list.
Step 2
Heads-down, async
The actual work
You don’t hear from me much.
I read your infrastructure and the code that runs on it, trace the deploy path, and load-test where a number settles an argument.
Step 3
60-minute call, recorded
Report and readout
The report lands in the morning, before we talk.
Then we walk the ranked fix list with your engineers. Bring the person who’ll disagree with me.
The same read, already done on real systems.
Full write-ups with the architecture and the numbers — and, for the reference build, source you can read line by line.
Built a Production-Style GitOps Platform on AWS EKS with Zero Static Credentials
Designed and deployed a production-style AWS EKS platform using Terraform and GitOps. Eliminated static cloud credentials using IRSA and automated secret delivery with External Secrets Operator, enabling fully declarative infrastructure and application delivery.
Three teams this is built for, and three it isn’t.
Who it’s for
- You shipped fast with AI tooling.Cursor, Claude Code, Lovable, Replit — the product exists because you didn’t wait for a platform team to build it first.
- Real users are on it now.Money, data, or both move through something that has never been tested by traffic you didn’t send yourself.
- Nobody owns the infrastructure.The system got built quickly, and keeping it standing isn’t anyone’s actual job.
Who it’s not for
- Pre-seed, no real users yet.There isn’t enough system to tear down. Ship first.
- You already have a platform team.You need headcount, not an outside read.
- You want someone to do the fixing.The teardown says what’s wrong and how — doing it is a separate conversation.
I never need production credentials.
One read-only role. That’s the whole ask.
- Read-only, scoped by you.An IAM role and repo access — logged on your side, revoked at the readout. I never hold production credentials.
- Fifteen minutes is all you owe me.You answer a written questionnaire; I read the config myself instead of booking an engineer to walk me through it.
Can’t grant access? A screen share works — it costs your engineers more hours, so it’s the fallback, not the default.
I read; I don’t touch.
- No scanning, no pen-testing.If a finding needs proving, I show you the command instead of running it.
- Nothing changes in your systems.Implementation is separate work, separately scoped.
Most teams take the list and do the work themselves.
That's what the quick wins are for, and it's the outcome I write the report around. If you'd rather I did some of it, here's the cost, up front.
$8,000–$12,000
quoted per engagement, scoped from the teardown's ranked list — a range, not a package.
$4,000/month
ongoing part-time support — ~25 hours a month, async, three-month minimum, 1–2 clients at a time.
Credit chain. The $900 Deploy Path Review credits in full against the teardown. The teardown credits in full against your first month on a retainer. Each credit holds for 60 days. Nobody pays twice for the same step.
Everything people ask before booking, answered up front.
01Do I have to hire you afterwards?
No — and it's never a condition.
The report stands on its own: findings, the ranked fix list, and the exact config or commands for the quick wins. Most teams fix it themselves, and that's the outcome I write it for. Implementation is a separate conversation, after you've read it.
02What access do you need?
A read-only IAM role and read access to your repos.
Never production credentials, never an admin account, never write access. You scope it, every call I make lands in your own audit log, and it's revoked at the readout — about ten minutes of setup. There's no walkthrough call to book: intake is a written questionnaire. If your policy won't allow read-only access, we can work off a screen share instead; that costs your engineers more hours, so it's the fallback.
03Is this a penetration test or a security audit?
No. It's a production-readiness review.
How you deploy, scale, observe and spend — and where that's fragile. I'll flag security posture I can see, like exposed secrets or missing access controls, but I don't run scanners or probe your systems, and this isn't SOC 2 or compliance work. If security is your main concern, say so on the call and I'll weight the review that way.
04What exactly do I get, and what's out of scope?
A written report, plus a 60-minute recorded readout.
Findings ranked by severity and effort, quick wins with the actual config or commands, and a risk map across CI/CD, deploys, Kubernetes, IaC, observability and cloud cost. Out of scope is implementation: the teardown finds and prioritizes, it doesn't fix.
05What's the difference between the $900 review and the $3,500 teardown?
The review reads your repo only, and covers the deploy path.
Read access to GitHub or GitLab, a written read within 72 hours on CI config, Dockerfiles, IaC, Kubernetes manifests, secrets handling and rollback. The teardown adds cloud infrastructure, load behaviour, observability and cost, and includes the readout call. The review is credited in full against the teardown for 60 days.
06Will you sign an NDA?
Yes — send yours and I'll sign it as-is.
Before I get access, ideally. If a clause is genuinely unusual I'll tell you which one and why. No NDA of your own? A standard mutual one is fine.
07What happens to our data and access after you're done?
Access is revoked the moment we wrap.
Since it was read-only, there's nothing to clean up beyond removing the role. I don't copy your code or data out — anything I reference lives in the report as a finding. Happy to delete my working notes on request.
08What if you find something serious mid-review?
You hear about it that day.
I don't sit on a critical issue until the readout. An exposed secret or an open door to production gets a message with enough to act on immediately. The full report still lands in your inbox within one week of access.
09What timezone are you in, and will that be a problem?
About four hours of daily overlap with US and EU hours.
Intake is written, so the readout is the only call — and it's scheduled inside your working day. The work in between is heads-down, so the overlap matters less than it sounds. Your afternoon is my evening, so replies tend to land faster than you'd expect.
10How do I pay?
You'll get an invoice with a card or US bank-transfer link — the same way you'd pay any US vendor. Prefer Payoneer, Wise, or direct wire? Those all work too; just say so and I'll send details.
50% at booking, 50% on delivery. The invoice goes out when we book, and the report lands within one week of access either way. Full refund, no questions asked.
Founder rate for the first three teardowns — $2,500 instead of $3,500 — in exchange for a public case study and a named testimonial.
Book the teardown.
Thirty minutes to see whether your system is a fit. If it isn't, I'll say so on the call — I'd rather lose the $2,500 than write a report you didn't need.
- Written report + ranked fix list
- 60-minute recorded readout call
- 50% at booking, 50% on delivery
- Zero production credentials needed
Or email hello@talhaimtiaz.me