AIBuilder Marketplace: software pricing dossiers

Find software products by task or name, with optional filters. Returns compact rows (id, entry price, cost-trap ids, pricing date). Ranking is text relevance only, never commission.

The full record for one product: plans, every cost trap with its full evidence sentence, pricing date, unknowns, price rules if any, and the vendor handoff with affiliate disclosure.

Compare 2 to 6 products side by side. Every requested id is returned, found or not. With units, adds the cheapest fitting plan's cost where price rules exist.

The evidence behind a product's cost traps and free-plan flag: the exact sentences from our pricing notes, the date they were read and the source.

Cost of each plan at a team size (or companies/orders, per the product's axis) on monthly or annual billing: monthly equivalent, amount billed per period, commitment, minimums, add-ons and usage. Only for products with price rules; says so otherwise. Never guesses between published price steps: returns a range.

Cost as a team grows: the cheapest fitting plan at each size and the points where the best plan changes.

Check a software choice against requirements before buying. requirements (all optional): units, billing ('monthly'|'annual'), plan_id, budget_month {amount, currency}, needs_monthly_billing, max_commitment_months, needs_free_plan, avoid_cost_traps [quote_only, per_seat, usage_metered, renewal_jump, addons_extra, annual_lock], features [text], addons [ids], usage {id: quantity}, service (price only that part of a vendor's ladder, e.g. eor, contractor, contractor_of_record, global_payroll). Each requirement gets fits / does_not_fit / unknown / conflicting / recheck_needed / not_flagged / mentioned, with evidence. Outcome is no_blocking_requirement_found, blocking_requirement_found or insufficient_evidence; unknown never counts as a fit.

What we observed when we ran products ourselves. Search by task words, product id or result (passed_in_this_test, partial_in_this_test, failed_in_this_test, not_tested, not_available_on_tested_plan, observation). Each result applies to the product as it was on run_date, on the plan stated; a later version inherits nothing.

Build a purchase file for 1 to 6 candidate products against the same requirements (same fields as check_choice). Returns per candidate the check with evidence, the cheapest fitting plan's cost where computable, our hands-on test results, unknowns and the vendor handoff with affiliate disclosure; a fixed order that never uses commission; a summary_markdown to show the user as is (it starts with the share link and says whether any candidate has a confirmed fit); a share_url; and depends_on facts so the file can be re-checked later. A feature counts as documented only from the vendor's own pages, never as tested by us. When requirements.modules names a setup ([{id, role}], e.g. a help desk plus a phone line), read setup_check for the verdict on the whole setup (its known costs per currency, open items and the budget for the setup as a whole); each candidate's own budget line compares that product alone.

Re-check a purchase file built earlier: pass the whole dossier back. Reports which underlying facts changed (entry price, plans, cost traps, price rules, research status, pricing date) and which conclusions that affects. Never buys, cancels or switches anything.

Find reader offers and vendor offers on our deal pages (discounts, extra credits, longer trials, conditional pilots). Each row has the evidence and its date, the verification status and the deadline in UTC. Expired offers are left out unless include_expired. Ranking is alphabetical, never by discount size or commission.

The full record of one offer: type, benefit and its structure, eligibility as recorded (null = the vendor did not say), claim steps, code, limits, evidence with dates, deadline, cost after the offer where known, and the vendor handoff with affiliate disclosure. No offer has been tested at a checkout.

Check whether an offer fits a buyer's situation: {customer: new|existing, plan, billing: monthly|annual|biennial}. Returns matches, does_not_match (with reasons) or needs_confirmation (missing information, an unconfirmed offer, or a pilot granted case by case), plus what the vendor did not state. A match is not a checkout guarantee.

Compare 1 to 3 offers on the same billing term and period. prices maps offer_id to the monthly price the buyer would pay for that product without the offer (same currency as the vendor). Returns fit and cost per offer: pay today, cost over the period with and without the offer, saving, or why it cannot be calculated (credits, a longer trial, unknown duration).

All categories with their product counts.

Takes no parameters.