Kong Reviews

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.

Link the GitHub repo a saved plan is being built in, and check it: detect_stack reads the repo and each planned service is marked found or not found yet (normal while building), services the repo uses that the plan doesn't are listed as drift, and when every planned service is found the plan is marked built. Pass id (a saved plan from list_saved_stacks) and repo the first time; after that, id alone checks the linked repo again. Private repos need the Kong Reviews GitHub App on that repo. How to present: say whether it is built; list what is not found yet as the next setup steps (from get_build_pack); for each drift service, ask the user whether to keep it (price it with diff_stack, or re-plan) or take it out of the code. Needs sign-in.

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.

Asks the questions that decide an architecture (static or dynamic, who signs in, how much data, uploads and media, background jobs and live updates, data sensitivity, threat profile, cost of downtime, who runs the servers), then rates every architecture against the answers: static site on a CDN, frontend with Supabase, serverless Next.js on Vercel, Cloudflare Workers, containers on DigitalOcean App Platform, one server, one server behind Cloudflare, Firebase, or on the phone with no server. Returns the top three with a 0-100 fit, what each service does, the monthly cost now and at forecast, strengths and concerns; the rest it considered; and the ones ruled out with the reason. Interview loop: call it with the description first; show the user the questions (each has options, why it matters, and sometimes a suggested answer read from the description); ask the unanswered ones, a few at a time, and call it again with answers. It ranks with whatever is answered, so it is fine to stop early. No model is used for the questions or the ratings. Each architecture has plan_stack_arguments and share_url for the full plan. When the user adds a requirement later, call it again with the same answers and the new description or requirements.

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"}]}.

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.

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.

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).

What a code change does to an app's bill: pass the files before (base_files) and after (head_files) the change, such as package.json, requirements.txt, .env.example (names only) and deploy configs. Returns the services added and removed, each priced now and in 12 months at the given users, with cheaper options and cost jumps, the change in monthly cost, and comment_markdown ready to post on a pull request. Use it before adding a paid service or SDK, or to review a pull request. Rules only; nothing is stored.

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}.

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"}]}. When a migration playbook covers the move (Netlify to DigitalOcean App Platform so far) and switching.hours is left out, the switching cost uses its effort range, not a flat 40 hours; plan_migration gives the full plan. 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.

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.

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"]}}.

Everything needed to start building a planned stack: the decisions (each service, what it covers, the runner-up, cost now and at forecast), setup steps in order (domain, hosting, database, sign-in, email, payments, monitoring), the variable names as .env.example, KONG.md (a brief for the AI assistant: the stack, rules, cost cliffs, setup order, and what "done" means), an acceptance checklist and cost guardrails. For a plan built with an app builder (builder_profile non_developer), KONG.md is one prompt to paste into the builder instead. Pass the share_url of a plan (no sign-in needed) or the id of a saved plan (needs sign-in). Write KONG.md and .env.example into the project root, then follow the steps with the user. Values never pass through Kong Reviews: only variable names.

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

Re-run a saved stack or audit with today's catalogue and compare it with when it was saved: monthly cost then and now, picks (or plans) that changed, vendors whose pricing changed and, for audits, the grade; and any bills recorded with record_bills next to the estimate. Use it when the user asks about a stack they saved, or whether prices moved. Pass the id from list_saved_stacks. Its questions are what is still assumed; keep the user's answers on the stack with update_saved_stack (answers). 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, and each pick's "weighed" note when a cheaper vendor lost on lock-in, setup work or seed prices. Offer the alternatives (cheapest, fewest vendors) with what each changes, its cost and its share_url. List not_planned as needed but not in the totals. Ask the questions (most expensive first) and re-plan with the answers in the argument each names (per_user, revenue_per_mau_usd, builder_profile); when the user says an assumption is right, add the question id to confirmed so it isn't asked again. On a saved stack, keep answers with update_saved_stack (answers). 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 capability ids (features, compliance, regions) that requirements can reference, e.g. auth.saml_sso, region.eu, payments.merchant_of_record.

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.

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

Plan moving an existing app from one host to another (playbooks so far: netlify → digitalocean-app-platform). Reads the repo (files, pasted text or a GitHub repo, as detect_stack does) for the features the app uses on the current host. Returns, in this order: the verdict (monthly cost before and after, one-off hours low to high, the month the move pays off, and whether staying is cheaper; staying is a valid answer), the features (those with no equivalent or that need another service first, each with its effort, risk, steps and sources), what to check in the current host's dashboard because the repo can't show it, a draft .do/app.yaml, and a cutover runbook that keeps the old site live until the new one is proven. Pass features the person confirms from their dashboard (e.g. netlify-dns, forms, deploy-previews) in features. Nothing is deployed or stored; the person deploys the spec themselves. How to present: lead with the verdict and say plainly when staying is cheaper; then the features with no equivalent or needing a service; then the rest, the checks, the spec and the runbook. Show every caveat word for word.

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, and each pick's "weighed" note when a cheaper vendor lost on lock-in, setup work or seed prices. Offer the alternatives (cheapest, fewest vendors) with what each changes, its cost and its share_url. List not_planned as needed but not in the totals. Ask the questions (most expensive first) and re-plan with the answers in the argument each names (per_user, revenue_per_mau_usd, builder_profile); when the user says an assumption is right, add the question id to confirmed so it isn't asked again. On a saved stack, keep answers with update_saved_stack (answers). 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.

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"]}}.

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, and each pick's "weighed" note when a cheaper vendor lost on lock-in, setup work or seed prices. Offer the alternatives (cheapest, fewest vendors) with what each changes, its cost and its share_url. List not_planned as needed but not in the totals. Ask the questions (most expensive first) and re-plan with the answers in the argument each names (per_user, revenue_per_mau_usd, builder_profile); when the user says an assumption is right, add the question id to confirmed so it isn't asked again. On a saved stack, keep answers with update_saved_stack (answers). Link share_url so the user can open the full result on kongreviews.com. Do not add vendor…

Record what the user actually paid each service in a month, on one of their saved stacks or audits, and compare it with the estimate at the users it was saved with. Without id, the bills are kept on the account, not on a stack (for someone who has not saved one): they are recorded and listed, with no estimate to compare, and can be moved onto a stack later on the Billing page. Pass bills (month as YYYY-MM, the service as vendor_id or name as on the invoice, amount_usd), or csv: a billing export with columns for month or date, service or vendor, and amount, or invoice_text: an invoice's text as pasted from the PDF or email (the service, month and total are read from it, each with the invoice line it came from; preview: true reads it without saving, so the user can check it first). A bill replaces any earlier one for the same service and month; remove deletes a month (or one service in it). Returns, per service, the estimate, the bill and the difference, flagging bills more than 20% (and $5) over or under. With alerts on, a bill well over its estimate is emailed too. Needs sign-in. How to present: a table of service, estimate, billed and difference; then say what could explain the biggest gap (more users or usage than given, a plan above the one assumed, add-ons the catalogue does not price) and offer update_saved_stack with the real user count.

Save a recommended stack, or an audit of an existing app, 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, plan_stack or audit_stack (preferred) or the plan_stack arguments, plus a short name such as "Yoga booking MVP". Afterwards, offer update_saved_stack with alerts: true so they are emailed when prices or cost jumps change it. 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.

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. A provider can carry availability (acquired, shutting_down) and an admin_note: say so when you mention it. Services that shut down are left out unless include_closed is true. 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"}.

Change one of the signed-in user's saved stacks or audits: its name, how many users it has now (mau_now) or expects (mau_forecast), whether to email them when it changes (alerts), which build-pack steps are done (build_progress, for plans) and which steps of a host move are done (migration_progress, for audits). With alerts on, Kong Reviews checks it every day and emails when a vendor's price change moves its monthly cost, when a cost jump or a startup credit running out is about 45 days away, and once a month to ask for the current user count. Alerts need a confirmed email: pass email to send the confirmation link (GitHub sign-in shares no email). Updating users re-prices it and makes today the start of its projection. Needs sign-in.