A vibe-coded app can get surprisingly far.
You can build the interface, connect a database, wire up payments, add authentication, and put something in front of customers in days instead of months.
That is the good part.
The problem starts when the prototype stops being a prototype.
A few customers become dozens. Then hundreds. More data comes in. More people depend on the product. A small bug is no longer annoying. It becomes a support issue, a lost payment, a security problem, or a broken customer workflow.
At that point, the question is no longer:
“Does it work?”
The better question is:
“What breaks when this becomes real?”
Here are 10 prompts I would run before increasing traffic, onboarding more customers, or calling an AI-built prototype production-ready.
A note before you start: do not let the agent immediately rewrite everything. Ask it to inspect first, explain what it found, rank the risks, and only then decide what is worth fixing.
Find the security problems before someone else does
Start broad.
Use this before spending time on individual security areas.
Why I like this prompt:
It forces the agent to move from “I see something questionable” to “this is how someone could actually exploit it.”
That distinction matters.
Check whether one customer can access another customer's data
A login screen does not mean your application is secure.
Authentication tells you who someone is.
Authorization decides what they are allowed to do.
That second part is where a lot of fast-built products get into trouble.
Audit every authenticated endpoint and user action for authorization vulnerabilities.
Look specifically for IDOR/BOLA, privilege escalation, missing ownership checks, role bypasses,
admin-only operations exposed to standard accounts, and access restrictions enforced only in the frontend.
Try to identify ways one customer could read, modify, or delete another customer's data.
Audit every authenticated endpoint and user action for authorization vulnerabilities.
Look specifically for IDOR/BOLA, privilege escalation, missing ownership checks, role bypasses,
admin-only operations exposed to standard accounts, and access restrictions enforced only in the frontend.
Try to identify ways one customer could read, modify, or delete another customer's data.
Audit every authenticated endpoint and user action for authorization vulnerabilities.
Look specifically for IDOR/BOLA, privilege escalation, missing ownership checks, role bypasses,
admin-only operations exposed to standard accounts, and access restrictions enforced only in the frontend.
Try to identify ways one customer could read, modify, or delete another customer's data.
If you are building a multi-tenant SaaS product, I would run this early.
Then run it again after major permission changes.
Find exposed secrets
This one is simple.
And worth doing almost every time.
The important word here is rotated.
Deleting a leaked key from the current version of your repository does not make the old key safe again.
Audit your dependencies
Your own code may be fine.
The package your coding agent added five minutes ago may not be.
Audit all application dependencies
for security and production risk.
Identify:
known vulnerabilities
abandoned or poorly maintained packages
outdated major versions
unnecessary dependencies
suspicious transitive dependencies
packages with excessive permissions
libraries that duplicate functionality already available
elsewhere in the stack
Separate the findings into
Audit all application dependencies
for security and production risk.
Identify:
known vulnerabilities
abandoned or poorly maintained packages
outdated major versions
unnecessary dependencies
suspicious transitive dependencies
packages with excessive permissions
libraries that duplicate functionality already available
elsewhere in the stack
Separate the findings into
Audit all application dependencies
for security and production risk.
Identify:
known vulnerabilities
abandoned or poorly maintained packages
outdated major versions
unnecessary dependencies
suspicious transitive dependencies
packages with excessive permissions
libraries that duplicate functionality already available
elsewhere in the stack
Separate the findings into
That last instruction matters.
“Update all dependencies” is not a production-readiness strategy.
Sometimes it is just a good way to spend a weekend fixing things that were not broken.
Ask what happens when dependencies fail
Prototypes are usually built around the happy path.
Production is where the unhappy paths start showing up.
Perform a production-failure review of this application.
Analyze what happens when:
the database is slow
the database is unavailable
an external API times out
an external API returns invalid data
the same request is submitted twice
a background job fails halfway through
object storage is unavailable
the application process restarts unexpectedly
traffic suddenly increases 10x
For every failure mode, explain
Perform a production-failure review of this application.
Analyze what happens when:
the database is slow
the database is unavailable
an external API times out
an external API returns invalid data
the same request is submitted twice
a background job fails halfway through
object storage is unavailable
the application process restarts unexpectedly
traffic suddenly increases 10x
For every failure mode, explain
Perform a production-failure review of this application.
Analyze what happens when:
the database is slow
the database is unavailable
an external API times out
an external API returns invalid data
the same request is submitted twice
a background job fails halfway through
object storage is unavailable
the application process restarts unexpectedly
traffic suddenly increases 10x
For every failure mode, explain
This is often where a product starts looking very different from a prototype.
Find what breaks first at 10x traffic
Do not redesign the entire system because someone said “we need to scale.”
First find the constraint.
Analyze the application's
likely bottlenecks if traffic increases 10x.
Review:
database queries and indexes
connection pools
synchronous API calls
expensive computations
memory usage
file handling
caching
queues and background work
third-party API limits
rate limits
infrastructure configuration
session handling
Rank the likely bottlenecks by probability and customer impact.
Separate
Analyze the application's
likely bottlenecks if traffic increases 10x.
Review:
database queries and indexes
connection pools
synchronous API calls
expensive computations
memory usage
file handling
caching
queues and background work
third-party API limits
rate limits
infrastructure configuration
session handling
Rank the likely bottlenecks by probability and customer impact.
Separate
Analyze the application's
likely bottlenecks if traffic increases 10x.
Review:
database queries and indexes
connection pools
synchronous API calls
expensive computations
memory usage
file handling
caching
queues and background work
third-party API limits
rate limits
infrastructure configuration
session handling
Rank the likely bottlenecks by probability and customer impact.
Separate
The third category is important.
Premature scaling work is still premature optimization, even when AI can generate it quickly.
Look for ways data can become inconsistent
A crash is obvious.
Bad data can sit quietly for months.
Review this application for data-integrity risks.
Look for
Review this application for data-integrity risks.
Look for
Review this application for data-integrity risks.
Look for
This is especially important once money, orders, permissions, inventory, or customer-generated content are involved.
Check whether backups would actually save you
Having backups and being able to recover are not the same thing.
Review the application's backup and recovery approach.
Identify what data is backed up, how often, where backups are stored,
how long they are retained, and what is not covered.
Then answer
Review the application's backup and recovery approach.
Identify what data is backed up, how often, where backups are stored,
how long they are retained, and what is not covered.
Then answer
Review the application's backup and recovery approach.
Identify what data is backed up, how often, where backups are stored,
how long they are retained, and what is not covered.
Then answer
If the answer is “we think the platform handles it,” keep digging.
Find what you will not know when production breaks
A system can fail perfectly while giving you no clue why.
Audit the application for observability gaps.
Review logging, error tracking, metrics, tracing,
health checks, alerts, deployment visibility, database monitoring,
external API monitoring, and background jobs.
Identify failures that could affect customers without generating a useful signal.
For each gap, recommend the minimum monitoring needed to answer
Audit the application for observability gaps.
Review logging, error tracking, metrics, tracing,
health checks, alerts, deployment visibility, database monitoring,
external API monitoring, and background jobs.
Identify failures that could affect customers without generating a useful signal.
For each gap, recommend the minimum monitoring needed to answer
Audit the application for observability gaps.
Review logging, error tracking, metrics, tracing,
health checks, alerts, deployment visibility, database monitoring,
external API monitoring, and background jobs.
Identify failures that could affect customers without generating a useful signal.
For each gap, recommend the minimum monitoring needed to answer
You do not need fifty dashboards.
You need enough information to understand a bad Tuesday morning.
Ask whether the codebase can survive another year of AI-generated changes
This is the one I would run after the application has accumulated a lot of rapid changes.
Review this codebase for maintainability and architectural risk if humans and
AI agents continue adding features for the next 12 months.
Look for:
duplicated logic
oversized modules
unclear boundaries
inconsistent patterns
hidden coupling
circular dependencies
business logic inside UI components
unclear ownership
missing tests around critical behavior
undocumented architectural decisions
code that requires unusually large amounts of context to modify safely
Do not propose a rewrite.
Identify the five changes that would most improve
the team's ability to keep extending the product safely.
Review this codebase for maintainability and architectural risk if humans and
AI agents continue adding features for the next 12 months.
Look for:
duplicated logic
oversized modules
unclear boundaries
inconsistent patterns
hidden coupling
circular dependencies
business logic inside UI components
unclear ownership
missing tests around critical behavior
undocumented architectural decisions
code that requires unusually large amounts of context to modify safely
Do not propose a rewrite.
Identify the five changes that would most improve
the team's ability to keep extending the product safely.
Review this codebase for maintainability and architectural risk if humans and
AI agents continue adding features for the next 12 months.
Look for:
duplicated logic
oversized modules
unclear boundaries
inconsistent patterns
hidden coupling
circular dependencies
business logic inside UI components
unclear ownership
missing tests around critical behavior
undocumented architectural decisions
code that requires unusually large amounts of context to modify safely
Do not propose a rewrite.
Identify the five changes that would most improve
the team's ability to keep extending the product safely.
That last line is deliberate.
A messy codebase does not automatically need a rewrite.
Usually it needs a few constraints removed in the right order.
Do not run all 10 prompts and then rebuild everything
That would miss the point.
The goal is not to turn a two-month-old MVP into an enterprise platform.
The goal is to understand where the risk has changed.
If you have five customers, some problems can wait.
If you have 500 customers paying you every month, the same problems may suddenly matter a lot.
That is the transition founders need to learn to recognize.
Build fast while you are proving the idea.
Then, when customers start depending on it:
Harden what matters. Scale what reality exposes. Leave the rest alone.
That is usually a much better engineering strategy than rewriting the prototype because it no longer feels clean.
A simple way to use these prompts
Run them in this order:
Security
Authorization
Secrets
Dependencies
Failure modes
Traffic/scaling
Data integrity
Recovery
Observability
Architecture
Save the findings.
Do not accept every recommendation automatically.
Ask the agent to show evidence.
Then rank the findings using three questions:
Can this hurt a customer?
Can this lose or expose data?
Will this make the next stage of growth materially harder?
Fix those first.
The rest can probably wait.
DarkLime has helped 30+ clients build, harden, and scale digital products.
If your prototype is working but you are no longer sure whether the architecture, cloud setup, security, or codebase is ready for the next stage, start with a Prototype-to-Production Assessment.
👉 Send us a link to what you are building at darklime.tech.
