Vibe coding for CPOs in SaaS.
In a SaaS company the CPO sits one door down from the engineers who own the product, and every prototype you build gets compared to it. The tension is that your discovery build shares the product's customers, its login and often its database, so a throwaway that leaks into the product surface is not a throwaway.
What is true about software in SaaS before you write a prompt.
In a SaaS company the software is the business, which means an executive's side build is never really on the side. It sits next to the product, shares its customers, and often ends up connected to the same database. The bar is production from day one, because customers cannot tell the difference between the product and the tool you built on a Sunday.
Multi-tenant means one mistake leaks every customer
Every table has a customer ID and every query must filter by it. The AI often forgets on the second screen. The first check on any SaaS build is whether customer A can see customer B.
Security questionnaires are coming
Enterprise buyers will ask how the tool stores data, who has access and whether it has been reviewed. A homemade tool with no answers can stall a deal.
Uptime is a contract
If customers use it, it needs monitoring, a backup and a way to roll back. The free tier of a hosting platform is not an SLA.
It will be integrated with the product
Someone will connect it to the main database or API. That connection needs its own key with the minimum access, or your side tool becomes the weakest door into the product.
What a CPO in SaaS gets back first.
01The request that keeps losing the sprint
The thing five accounts keep asking for, behind a feature flag and switched on only for them. You get real usage instead of another prioritisation debate, and the rest of the base never sees a prototype.
02The pricing change announced on a hunch
A checkout mirroring the real Stripe products but charging a test account, so you can watch which plan names and price points get clicked before anything is announced. The packaging argument gets numbers.
03The churn post-mortem the vendor dashboards cannot run
Product events joined to subscription status, showing which features last quarter's cancellations never touched. The retention roadmap starts from that join rather than from intuition.
Four more hold for CPOs in any industry. They are on the CPO page.
The prototype reads the production database directly
To make the discovery build realistic you point it at the product's Postgres with the admin connection string, then share the link with three customers. The build has no tenant filter, so every account's data is one query away for anyone holding the URL. In SaaS that is a breach notification, a security questionnaire answer you cannot give, and a renewal conversation with every affected customer.
The pattern underneath is the one every CPO hits: sales saw the demo. A customer signed. Now the exploratory build with no error handling and no tests has a contract attached, and 'we will rebuild it properly' has no date.
What a safe build in SaaS usually runs on.
Typical builds run on Next.js or a similar framework with Postgres, hosted on Vercel or a comparable platform, with Stripe for billing and the product's own API for customer data. The same stack the free course teaches, which is deliberate.
What changes for a CPO in SaaS.
A CTO in your corner draws the line between discovery and production, and helps you cross it on purpose. Prototypes stay cheap and disposable. The ones that are going to live get the ten things production needs before a customer touches them. When engineering takes over, it comes with a written account of what was decided and why. Discovery stays fast. The handover stops hurting.
What CPOs in SaaS ask.
A CTO who has read SaaS apps before yours.
Thirty minutes, free, no card. What you built, what is going on with it, whether we can help.
In your corner.