Vibe coding for purchasing managers in SaaS.
You buy the software a software company runs on: the cloud bill, the hundred SaaS subscriptions, the contractors and the one vendor whose outage takes your product down. The tension is that engineering signs up for tools on a card faster than you can review them, and the renewal you find out about is the one that already auto-renewed.
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 purchasing manager in SaaS builds first.
01The shadow SaaS discovery feed
Card transactions, single sign-on logins and expense claims matched against your vendor list every morning. It finds the fourth project management tool and the duplicate monitoring subscription before the annual invoice does.
02The cloud cost by team view
The AWS or Google Cloud bill split by tag, team and environment, next to last month. Engineering sees the number they own, and the negotiation for committed spend starts from data instead of a guess.
03The vendor security review queue
Every new vendor request lands with its SOC 2 report, data processing agreement and data-access answers in one place, with the security lead's sign-off recorded before the contract is countersigned.
Purchasing managers in every industry tend to build the same four things. The purchasing manager page has that list.
The discovery tool gets a card key that spends
To read transactions the tool gets a corporate card API key, and the AI picks a key that can also issue virtual cards and raise limits. A bug or a stolen key spends before anyone notices, and the finance team learns about it from the statement. Read-only scopes cost nothing and were one sentence away.
The pattern underneath is the one every purchasing manager hits: the dashboard has no login or one login for everyone. Negotiated rates, contract terms and supplier margins are one shared URL away from a competitor or a supplier's rival.
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 purchasing manager in SaaS.
A CTO in your corner treats your procurement tool as a control, not a convenience. Approvals are enforced on the server where they cannot be skipped. ERP access is read-only until there is a reason for it not to be. Supplier documents are private and pricing is behind a login with roles. You still build the tool purchasing has needed for years. It just passes the audit it was built to help with.
What purchasing managers 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.