One-line summary: A YC-backed company that sells "production-ready APIs for any website" ships a marketing site, two blog posts, an open-source v0 CLI from the GPT-4o era, and effectively zero documentation for either the self-serve beta app or the generated APIs themselves.
1. There is no developer documentation for the actual product (critical)
Location:https://www.integuru.com/sitemap.xml and every page linked from the nav
Problem: The published sitemap contains exactly 15 URLs: homepage, FAQ, blog index, two blog posts, privacy, terms, and eight near-identical Solutions pages. There is no /docs, no /api, no /reference, no /guides, no /sdk, no /quickstart, no /auth. The Solutions pages and homepage market a product that "generates production-ready APIs" with "complete API schemas" and "full documentation of all request and response formats, with precise specifications for every field" — but none of that documentation is published anywhere a developer or coding agent can read it. The Features and Pricing nav items do not point to docs either; everything funnels to Talk to Us or app.integuru.ai.
Consequence: A developer evaluating Integuru cannot see a single example of a generated API's request/response shape, auth pattern, error format, rate limit behavior, or SDK call before signing up. An agent indexing the docs has nothing to index beyond marketing copy. The 99.9% reliability claim, the "complete API schemas" claim, and the <3 sec latency claim are unverifiable from public materials.
The fix: Publish a real /docs surface with at least: a sample generated API (one read, one write) including auth headers, request/response JSON, and an error envelope; a getting-started walkthrough for the beta app at app.integuru.ai; an OpenAPI spec template for what generated integrations conform to; and a reference page per the four authentication flows already listed in FAQ (session cookies, phone 2FA, email 2FA, "other verification steps").
2. The OSS repo and the commercial product are different products, with no bridge between them (critical)
Location:https://github.com/Integuru-AI/Integuru README vs. https://www.integuru.com/
Problem: The GitHub README describes "Integuru v0" — a local CLI you run via poetry run integuru --prompt "download utility bills" --model <gpt-4o|o3-mini|o1|o1-mini> after generating a HAR file with . The marketing site sells a managed cloud service priced at "$0.02 / read call, $0.10 / write call, with an $800 monthly minimum per platform" with "24/7 on-call engineers" and a self-serve beta at . The README never tells you the cloud product exists; the marketing site never tells you the OSS tool exists. There is no migration guide, no "v0 → managed" mapping, no statement of whether the managed product uses the same agent under the hood, and no explanation of which pricing applies to which.
Consequence: A developer who finds the GitHub repo first (4.6k stars, AGPL-3.0) will assume the product is a local CLI and self-host it. A developer who finds the marketing site first will sign in to app.integuru.ai and never learn the agent code is open source. Sales conversations get muddled because nobody knows what they bought.
The fix: Add a top-of-README banner in Integuru-AI/Integuru linking to the managed product with a one-paragraph comparison table (self-host CLI vs. managed app vs. fully managed service). Mirror it on integuru.com with an /open-source page.
3. The open-source agent still recommends GPT-4o, o1-mini, and o1-preview in 2026 (significant)
Location:https://github.com/Integuru-AI/Integuru README, Setup and Usage sections
Problem: The README says: "We recommend using an account with access to models that are at least as capable as OpenAI o1-mini. Models on par with OpenAI o1-preview are ideal." The CLI flag is --model <gpt-4o|o3-mini|o1|o1-mini> and the default is gpt-4o. The behavior note: "Recommended to use gpt-4o as the model for graph generation as it supports function calling. Integuru will automatically switch to o1-preview for code generation if available in the user's OpenAI account." These model names are from late 2024; o1-preview was deprecated, and GPT-5 / Claude 4-series models have been generally available for over a year by the date stamp on the latest blog post (April 13, 2026).
Consequence: A developer cloning the repo today and following the setup verbatim will configure deprecated/retired models, hit model_not_found errors, and conclude the project is abandoned. Coding agents reading this README will surface stale model guidance to their users.
The fix: Update the --model choices and recommendations to current GA OpenAI models (or accept any model id and let OpenAI return the error). Add a date-stamped "Last validated against" note. Drop the "automatically switch to o1-preview" branch or replace it with a configurable code-generation model flag.
4. llms-full.txt is 404 even though llms.txt exists and the convention is paired (significant)
Location:https://www.integuru.com/llms.txt (200) vs. https://www.integuru.com/llms-full.txt (404), and https://integuru.ai/llms-full.txt (308 → 404)
Problem: A well-formed llms.txt ships at the canonical host. The paired llms-full.txt — which is where agents look for the long-form, full-content concatenation — is not published. The llms.txt itself is essentially a re-statement of marketing bullets (customer logos, pricing line, latency numbers); it does not link to a single /docs page because none exist (see #1).
Consequence: Agents that follow the llms.txt convention will fetch the index, see no document links beyond /privacy and /terms, fail to find a llms-full.txt, and have nothing substantive to ground answers in about how Integuru's APIs actually work.
The fix: Either publish a real llms-full.txt once /docs exists, or remove the implicit promise by stating in llms.txt that no full corpus is published. Today's llms.txt should at minimum link to the GitHub README and the FAQ as the only quasi-technical pages.
Location: Brand uses hello@integuru.ai, richard@integuru.ai, app.integuru.ai, github.com/Integuru-AI; canonical site is www.integuru.com. https://integuru.ai/ 308-redirects to https://www.integuru.com/. https://integuru.ai/llms.txt and https://integuru.ai/llms-full.txt both 308-redirect to URLs on integuru.com that 404 (llms-full.txt) or work (llms.txt).
Problem: Every customer-facing identifier (email, app subdomain, GitHub org) lives on integuru.ai. The docs/marketing live on integuru.com. There is no documented reason for the split, and the redirect chain from integuru.ai/llms-full.txt lands on a 404 — meaning an agent following the email domain to look up an llms.txt gets a redirect to a dead page rather than a redirect to the working one on the new host.
Consequence: Coding agents that derive a docs root from the email address richard@integuru.ai will follow https://integuru.ai/llms-full.txt, get a 308, follow it, and receive a 404. Humans see two brand domains and wonder which is canonical, especially when the GitHub org is Integuru-AI but the website is integuru.com.
The fix: Pick one canonical brand domain and use it everywhere, or at minimum: make integuru.ai/llms.txt and integuru.ai/llms-full.txt proxy the integuru.com versions instead of issuing a redirect to a 404. Add a one-line "Why two domains" note in the FAQ.
6. The marketing copy contains "Interguru" misspellings of the brand name (minor)
Location:https://www.integuru.com/ body copy
Problem: The homepage body text reads, twice in the same section: "Interguru generates production-ready APIs for websites and web systems…" and "Interguru is backed by Y Combinator." The brand is "Integuru" (matching the domain, GitHub org, app subdomain, legal name suffix, and every other instance on the site).
Consequence: Search-engine snippets and agent summaries will sometimes echo the misspelling. It reads as inattention on the page where developers first decide whether to trust the platform.
The fix: Replace "Interguru" with "Integuru" on the homepage.
7. The animated terminal blocks across Solutions pages are syntactically invalid (minor)
Location: Homepage and all eight Solutions pages (/solutions/ai-agents, /solutions/healthcare, /solutions/fintech, /solutions/ai-transformation, /solutions/government, /solutions/legal, /solutions/logistics, /solutions/real-estate)
Problem: Each Solutions page shows a "bash" terminal block with lines like $ you automate --workflow = "tms_integrations" or, on the homepage, $integuru connect--industry = "AI Agents". The commands are not valid: the prompt sometimes has no space after $, the flag is concatenated to the verb (connect--industry), there are spaces around = (which would parse = as a positional argument in most shells/CLIs), and the CLI verb on every Solutions page is the pseudo-command you automate rather than integuru (the actual CLI name shown in the GitHub README). There is no real CLI called you and the real one is integuru.
Consequence: Developers and coding agents that interpret these blocks as real invocations will copy a command that doesn't exist. The graphic implies the product has a uniform CLI with --workflow and --industry flags; the actual CLI (integuru from the GitHub repo) has --prompt, --har-path, --cookie-path, --model, and --max_steps, none of which appear in the marketing visuals.
The fix: Either render these as clearly stylized non-shell visuals (no $ prompt, no bash label), or replace them with real invocations of the actual CLI so the marketing matches the product surface. If they remain as marketing-only graphics, label them "illustrative" and don't tag them as bash.
8. "HIPAA-compliant" is asserted with no supporting documentation (significant)
Problem: The healthcare page asserts: "Integuru is HIPAA-compliant and is backed by Y Combinator." Nowhere in the scraped content (privacy policy, terms, FAQ, blog, or any solutions page) is there a security/compliance page, BAA availability statement, audit attestation (SOC 2, HITRUST), data-residency note, or breach-response policy. The privacy policy describes that Integuru stores credentials, cookies, session tokens, access tokens, and API keys for Connected Platforms — i.e., extremely sensitive material — but provides no public statement of encryption-at-rest practice, key management, or compliance posture beyond the claim itself.
Consequence: Healthcare customers (Knowtex, Halo, Penciled, etc., per the customer list) who pass PHI through Integuru's generated APIs cannot point compliance teams at a public attestation. Procurement gates will stall every healthcare deal until that material exists; coding agents asked "is Integuru HIPAA-compliant" cannot cite anything beyond the marketing claim.
The fix: Publish a /security or /trust page covering: BAA availability, encryption-at-rest and in-transit specifics, secret-storage architecture (especially for the Authentication Data class defined in the privacy policy §3), and any SOC 2 / HITRUST status. Link from the healthcare page.
9. The companion APIs-by-Integuru repo has effectively no documentation (significant)
Problem: The repo lists 17+ submodule integrations (Venmo, Robinhood, AppFolio, BCBSAL, Brightree, Calendly, ECW, eSRP, Heno, Intuit, OfficeAlly, OncoEMR, Patreon, PracticeFusion, ServiceTitan, Songkick, Viventium, etc.). The README's only usage guidance is the single line "Reference main.py for usage." There is no per-integration auth flow, no per-integration endpoint list, no input/output schema, no rate-limit note, no example invocation, and no compatibility statement (is this still the API as of 2026, or 2024?).
Consequence: A developer who wants to use the Venmo "send money to other users" capability has to read the source of an unofficial integration with no docs to understand what arguments to pass — which is precisely the situation Integuru's whole value proposition claims to remove.
The fix: Add a per-integration README.md inside each submodule listing the supported actions, the arguments, and at least one example. Even auto-generated docstrings would be a meaningful improvement.
10. The "self-serve beta" app has no associated documentation (critical)
Location:https://app.integuru.ai/ (login page) and every marketing CTA on integuru.com
Problem: Every primary CTA on the homepage — "Start Now", "Try for Free", "Try now", "Sign In" — sends the user to app.integuru.ai, where the only visible content is a login/signup form. There is no public preview of what happens after login, no "what does the beta let me do" page, no documented API surface that the beta produces, and nothing in /docs, /blog, or /faq that walks through the beta flow end-to-end. The marketing says APIs are generated in "20 minutes" but there is no public artifact showing a generated API.
Consequence: Developers must create an account to learn what the product does. Coding agents asked "how do I integrate with Integuru's beta" can offer only "sign in and follow the prompts." Conversion friction aside, this is the single largest gap between what the product claims and what's externally observable.
The fix: Publish a /docs/quickstart that screenshots or walks through the beta flow (paste URL → describe action → receive generated API), shows the structure of a generated API (endpoint, auth header, sample response, error format), and links from every CTA button.
What they do well
llms.txt is present, well-formed, and includes the customer/platform lists in machine-readable bullet form. (The fact that llms-full.txt is missing — finding #4 — is the gap.)
The FAQ is candid about when Integuru is the wrong tool ("If you need to mass-scrape public data, we recommend using a dedicated scraping solution") and about edge-case failure modes (the breakage percentages in /blog/what-we-learned are the most concrete technical content on the entire site).
The Terms of Service §6 spells out the acceptable-use boundary clearly and forces the customer to own permissibility — uncommon for an automation vendor and useful for any engineer doing legal review.
Top 3 recommendations
Publish a /docs surface. Quickstart for the beta app, one real generated-API example (auth header, request body, response, error envelope), and the OpenAPI shape Integuru produces. Without this, the "complete API schemas" marketing claim is unfalsifiable.
Reconcile the OSS v0 and the managed product. Top-of-README banner in the GitHub repo, /open-source page on the website, and refreshed model recommendations (drop GPT-4o / o1-preview as the headline choices).
Stand up a /security page that backs the HIPAA claim. BAA availability, secret-storage architecture for the Authentication Data class already named in the privacy policy, and any SOC 2 status. Procurement for the healthcare customer list depends on it.