Kong Reviews

Start here. Describe the product in plain language and get a recommended stack with costs now and at scale, in one call. Write the description as the user would: what the product does, who signs in and how, how it charges, which emails it sends, compliance or data-region needs, and expected users now and in 12 months. Example: "A booking app for yoga studios. Members sign in with Google and pay a monthly subscription. Studios get paid out. EU data. 2,000 users at launch, 20,000 within a year." Pass a PRD as the description if you have one. Numbers you pass (mau_now, mau_forecast, budget_monthly_usd, profile_id, app_type) override what is read from the text. Without a user count it assumes a new product of that app type at launch and its typical growth, and lists that in defaults_used. Before treating the plan as final, show the user the requirements it read (each quotes its sentence) and the open questions, and ask them to confirm or correct them; then call plan_stack with the corrected requirements. How to present the result: show the stack table (pick and runner-up per category, monthly cost now and at forecast) and the totals. For each price give its source's verified date, or say it is unverified seed data. Show every caveat word for word; never round, merge or drop one. Mention requirement gaps, blockers and trade-offs. Link share_url so the user can open the full result on kongreviews.com. Do not add vendors or prices that are not in the result.

List vendors in the pricing catalogue, optionally for one category (hosting, database, auth, email, payments, observability, ai, edge, app_store, coding).

List capability ids (features, compliance, regions) that requirements can reference, e.g. auth.saml_sso, region.eu, payments.merchant_of_record.

Search the directory of developer services (hosting, databases, auth, email, SMS, payments, analytics, monitoring, LLM APIs, vector databases, search, CMS and more): what each provider sells, its free tier, its lowest paid price, caveats and the pricing page it came from. Wider than the cost engine: use it to find options or check a provider the other tools don't price. Entries marked candidate have no prices yet. Example: {"query":"postgres","category":"database"}.

Browse products startups have built and the stack each runs on: what it is, whether it is a website, a mobile app, both or a desktop app, its category and pricing, and every framework and service it uses (services link to the directory and, where priced, the cost engine). Use it to find real stacks to learn from, e.g. apps built with Supabase. Results list each filter value with counts. Example: {"tech":"supabase","form":"app"}.

Structured pricing and capabilities for one vendor: every plan, base fee, metered usage, limits, unmodelled costs, lock-in notes, source URL and verification date.

Monthly cost for one vendor at a given scale. Give mau (monthly active users) and a usage profile, or exact usage numbers. Picks the cheapest plan that fits unless plan_id is set. Example: {"vendor_id":"clerk","mau":25000}.

Rank vendors in one category at a given scale. Vendors meeting every must-have come first, then cheapest. Ranking is by cost and fit only. Example: {"category":"auth","mau":50000,"requirements":[{"capability":"auth.saml_sso"}]}.

For each vendor, show whether each requirement is met on its cheapest plan, needs a higher tier (with that tier's cost), or is missing.

Month-by-month cost for a whole stack as users grow, with startup perks applied if requested, plus cost cliffs (forced plan upgrades, sharp jumps, credits running out). Example: {"vendors":[{"vendor_id":"supabase"},{"vendor_id":"vercel"}],"start_mau":2000,"monthly_growth":0.15,"months":24,"apply_perks":true,"founder":{"gateways":["mercury"]}}.

Scan a range of user counts for one vendor and report where cost jumps: forced plan upgrades and points where usage charges start. Example: {"vendor_id":"clerk","from_mau":1000,"to_mau":200000}.

Startup credits for the given vendors, and whether you qualify based on your bank, incorporation provider, accelerator or funding. Example: {"vendor_ids":["supabase","posthog"],"founder":{"gateways":["mercury"]}}.

Turn PRD or spec text into structured requirements (scale, capabilities, compliance, regions, budget) for plan_stack, without planning. recommend_stack does both in one call. Each requirement quotes the sentence it came from. Show them to the user to confirm before planning. Without a model on the server it reads the PRD with keyword rules (mode "rules") and also returns the capability vocabulary and instructions: as an assistant, prefer doing the extraction yourself and use the rules result only as a starting point.

Given confirmed requirements as capability ids, recommend a vendor per category with a runner-up, requirement fit, cost now, cost at forecast scale, year-one cost after perks, cost cliffs, trade-offs and blockers. Use recommend_stack instead when you only have a plain-language description. Example: {"mau_now":5000,"mau_forecast":20000,"profile_id":"booking_marketplace","requirements":[{"capability":"auth.google"},{"capability":"payments.merchant_of_record"}],"founder":{"gateways":["mercury"]}}. How to present the result: show the stack table (pick and runner-up per category, monthly cost now and at forecast) and the totals. For each price give its source's verified date, or say it is unverified seed data. Show every caveat word for word; never round, merge or drop one. Mention requirement gaps, blockers and trade-offs. Link share_url so the user can open the full result on kongreviews.com. Do not add vendors or prices that are not in the result.

When something changes (bill too high, growth, a missing feature such as SSO, a renewal), compare staying on the current plan, optimising with the same vendor, and switching vendor, including one-off switching cost and the month switching pays off. Example: {"category":"auth","current":{"vendor_id":"clerk","plan_id":"pro"},"mau_now":11000,"monthly_growth":0.18,"requirements":[{"capability":"auth.saml_sso"}]}. How to present the result: show stay, optimise and switch side by side with cumulative cost at each month given, the break-even month and any problems; show every caveat word for word.

Work out which services an existing app runs on, from its files, a public GitHub repo, or its live website. From an AI coding app, read the project yourself and pass the files that say the most: package.json (or requirements.txt, pyproject.toml, Gemfile, go.mod, pubspec.yaml, Podfile), .env.example (names only, never secret values), and deploy configs (vercel.json, netlify.toml, fly.toml, render.yaml, .do/app.yaml, wrangler.toml, firebase.json, Dockerfile). Returns each catalogue vendor found with its evidence and confidence, services the catalogue can't price yet, frameworks and platforms. Rules only; nothing is stored. Then call audit_stack with the services (and their plans, if the user knows them).

Assess the stack an existing app runs on and recommend what to do. For each service: its plan, cost now and in 12 months, must-haves it lacks, cost jumps in the next year, lock-in, and a verdict (keep, watch, optimise, switch or fix) with savings, one-off moving cost and the month a switch pays off. Then a scorecard (cost, requirements, ready to scale, lock-in; A to F, weighted by priorities 0-3) and recommendations ranked by what the user cares about. Categories the requirements need but nothing covers are suggested too. Use the vendor ids from detect_stack; pass plan_id when the user knows their plan (otherwise the cheapest that serves today's users is assumed and said so). How to present: lead with the summary and overall grade, then the ranked recommendations with savings or added cost, then the scorecard; show every caveat and assumption word for word.

Save a recommended stack to the signed-in user's Kong Reviews account so it can be reopened later and compared with current prices. Pass the share_url from recommend_stack or plan_stack (preferred) or the plan_stack arguments, plus a short name such as "Yoga booking MVP". Needs sign-in: if the user isn't signed in, the app will ask them to connect their Kong Reviews account. Only save when the user asks to keep or save a stack.

List the stacks the signed-in user saved, newest first, with their monthly cost when saved and a link to each. Use it when the user mentions "my stacks", "the stack I saved" or a saved stack by name; then call get_saved_stack for one of them. Needs sign-in. How to present: a short table of name, saved date and monthly cost when saved, each name linked to its share_url.

Takes no parameters.

Re-run a saved stack with today's catalogue and compare it with when it was saved: monthly cost then and now, picks that changed, and vendors whose pricing changed. Use it when the user asks about a stack they saved, or whether prices moved. Pass the id from list_saved_stacks. Needs sign-in. How to present the result: show the stack table (pick and runner-up per category, monthly cost now and at forecast) and the totals. For each price give its source's verified date, or say it is unverified seed data. Show every caveat word for word; never round, merge or drop one. Mention requirement gaps, blockers and trade-offs. Link share_url so the user can open the full result on kongreviews.com. Do not add vendors or prices that are not in the result.

Permanently delete one of the signed-in user's saved stacks by id. Only call it when the user explicitly asks to delete that stack; confirm the name first. Needs sign-in.

Permanently delete the signed-in user's Kong Reviews account: their GitHub sign-in link and every saved stack. This cannot be undone. Only call it when the user explicitly asks to delete their account, after telling them what will be removed; pass confirm exactly as "delete my account". Needs sign-in.