Nanowork's entire developer surface — API, docs, demos, legal pages — is either suspended, missing, or contradicted by other parts of the marketing site. The homepage advertises a working bearer-authenticated REST API that returns 503 on every URL it lists, a gallery of "complete, working companies" whose live demos all 404, and revenue figures used to justify $2,200–$9,800 price tags with no methodology behind them.
1. Advertised API base URL is suspended on every documented endpoint (critical)
Problem: The homepage "API · EARLY ACCESS" section publishes a working curl example against https://api.nanowork.ai/v1/agents/sharpener with a 200 · 412 ms response banner, and lists six endpoints (sharpener, namer, researcher, landing, launch, ads). In reality, every URL the docs reference returns HTTP 503 — Service Suspended ("This service has been suspended by its owner."), including https://api.nanowork.ai/, https://api.nanowork.ai/v1, and https://api.nanowork.ai/v1/agents/sharpener.
Consequence: Any developer who gets an early-access key and runs the documented curl command gets a 503 with no path to recover — the docs don't acknowledge the API is down, don't list a status page, and don't define what 503 means in the (non-existent) error code table. An AI coding agent following the snippet will retry-loop against a permanently suspended host.
The fix: Either restore the host or remove the "API · EARLY ACCESS" section entirely until it works. At minimum, replace the fake 200 · 412 ms response chrome with an honest "API in private beta — endpoints not yet public" banner, and stop publishing a base URL that 503s.
2. Zero machine-readable API surface and no real docs site (critical)
Problem: For a product whose pitch is "Every agent that powers Nanowork, exposed as a single endpoint... typed contract," the entire developer-facing surface is one homepage section with six one-line summaries ("RETURNS pitch · ICP · wedge"). There is no /docs, no /api, no OpenAPI/Swagger spec, no JSON schema for any agent's request or response, no error code list, no rate-limit documentation, no auth-token lifecycle (how to get , how to rotate it, scopes, expiry). , , , and all 404. , , , all 404 (rendering the SPA shell). Brand-handle discoverability is also broken across channels: Twitter is but LinkedIn is (no suffix) — for a contact-only business with no GitHub org, that mismatch is the kind of thing that reads as a phishing signal to a careful agent or buyer.
Consequence: Agents (Claude Code, Cursor, Copilot) and humans both have to guess the request body shape from a single curl example per endpoint. The sharpener example shows {"idea": "..."} but the other five endpoints have no example payload at all — namer, researcher, landing, launch, ads cannot be called without writing to support. There is no way for an agent to programmatically discover what fields landing accepts to produce its headline · sections · copy return.
The fix: Publish an OpenAPI 3.1 spec at api.nanowork.ai/openapi.json covering all six agents with request/response schemas, error codes, and auth scheme. Add /llms.txt pointing to a /llms-full.txt that inlines the agent contracts. Document $NW_KEY issuance, rotation, and revocation explicitly. Normalize the social handles so both Twitter and LinkedIn use the same brand string.
3. Every "live demo" link in the gallery is a dead Vercel deployment (critical)
Problem: The gallery has 8 numbered listings (01–08), of which 6 are available, 1 is in escrow (Fieldnote), and 1 is sold (Nightkey, $12,500 historically). Available inventory is priced $2,200–$9,800 and headlined as "a complete, working company." Every available listing has an "Open live demo ↗" anchor pointing to https://demo.nanowork.app/<slug>. All of them — /, /lamina, /parcel — return Vercel's 404: NOT_FOUND / DEPLOYMENT_NOT_FOUND page. A buyer evaluating a $9,800 purchase (Parcel) cannot see the product they're being asked to wire money for.
Consequence: Buyers can't verify the asset before purchase, and the only remaining path to evaluate is the malformed sms: link (see issue 4). For a transactional gallery this is the single highest-friction failure on the site.
The fix: Either restore the Vercel project at demo.nanowork.app with subpath routing for each slug, or replace the dead anchors with screenshots, a Loom walkthrough, and a sandbox login. Don't ship buy buttons for a $9,800 product behind a 404.
4. All gallery "Buy" sms: links use malformed &body= query syntax, and the phone number is rendered without a country code (significant)
Location:https://nanowork.ai/gallery (anchor hrefs and rendered phone string)
Problem: Every "Buy <name>" CTA in the gallery is an sms: deep link of the form sms:+16506740193&body=Hey%20Nanowork%20.... The convention recognized by iOS Messages and Android default-SMS apps is sms:+16506740193?body=... (using ? as the first separator, not &). With &body= as the first separator, many platforms treat the entire string after the phone number as part of the address, and the prefilled body silently fails to populate. All seven extracted hrefs share the same defect. Separately, the href correctly uses E.164 +16506740193, but the page renders the number as (650) 674-0193 with no visible country code — for a service pitched globally on "Nanowork lives inside your messages," international buyers can't reliably text the displayed format.
Consequence: The gallery's only purchase mechanism is degraded: buyers tapping "Buy Lamina · $4,200" on iOS may land in Messages addressed to a garbled number with no body, with no fallback email or web form. International buyers reading the rendered number can't initiate the conversation at all without inferring the +1 country code. Combined with issue 3 (dead demos) and the absence of a real checkout, this leaves no clean path to actually buy a listing.
The fix: Change every gallery anchor from sms:+16506740193&body=... to sms:+16506740193?body=... (the cross-platform form). Render the phone number as +1 (650) 674-0193 so the country code is visible. Add a backup mailto: or a real form so the purchase flow doesn't depend on a single device-specific URL scheme.
5. Cross-page contradictions on price, availability, support window, and product domain (significant)
Problem: Multiple inconsistencies that an agent (or a careful buyer) will hit:
Gallery counter contradicts its own numbering. The header says "GALLERY · 6 AVAILABLE NOW" but listings are numbered 01 through 08, with Fieldnote labeled IN ESCROW and Nightkey labeled SOLD. A buyer scanning numbered tiles 01→08 reasonably expects 8 buyable units; the available/total split is never surfaced as a single number.
Support window contradicts itself. The gallery section header lists "30-day support · From the team that built it" and Lamina's WHAT'S INCLUDED says "30 days post-launch support," but Parcel's WHAT'S INCLUDED says "First 60 days of support." The "HOW A PURCHASE WORKS" footer then re-states "30d of included post-launch support" as a flat rule. Two listings, two different post-sale terms, with the global rule contradicting one of them.
Lamina's domain doesn't match its demo URL. The listing copy says "Domain transfer (lamina.app)" but the live-demo link points to lamina.nanowork.app (a subdomain of the suspended demo host). Buyers don't know which domain they're acquiring.
Pricing model is split across two products with no explanation. The hero and FAQ describe a $99/mo flat fee for build-with-us. The gallery sells one-time purchases at $2,200–$9,800 (with $12,500 historical on the sold Nightkey unit). The "Productized services" tile under "What you can build" still uses placeholder copy: "Turn what you're already good at into a $X/mo offer" — literal $X, never replaced. There is no /pricing page (it 404s), so the relationship between the $99/mo service and the gallery one-time prices is never reconciled.
Broken in-page anchor. The "Browse the gallery" CTA on /gallery points to /gallery/#listings, but no #listings element exists on the page.
Consequence: Agents parsing the site for pricing get three different answers ($99/mo, $2,200–$9,800 one-time, $X/mo). Buyers comparing Lamina vs. Parcel see different support terms with no rationale. The Lamina domain mismatch is a material misrepresentation in a transaction that includes domain transfer.
The fix: Replace "6 AVAILABLE NOW" with an explicit available/total split (e.g. "6 of 8 available") or skip non-available items in the numbering. Normalize all gallery listings to a single support window (or list per-listing terms in a structured table that the header reflects). Reconcile lamina.app vs. lamina.nanowork.app — pick one and update the listing. Replace the literal $X/mo placeholder. Publish /pricing covering both the recurring service and the gallery model. Either add a #listings anchor or remove the link target.
6. MRR figures used to justify $2,200–$9,800 price tags carry no methodology, time window, or proof (significant)
Problem: Five gallery listings publish current-revenue claims as a primary input to the price: Lamina $680 MRR at $4,200, Parcel $1,450 MRR at $9,800, Fieldnote $520 MRR at $6,400, Pressroom $920 MRR at $7,400, and the sold Nightkey $3,100 MRR at $12,500. These figures appear without a Stripe screenshot, a time window (trailing 30 days? trailing 90? best month?), a churn or refund disclosure, or any link to a verifiable source. The header even codifies the pattern as "Live revenue · Where noted, in MRR" without defining what "live" means.
Consequence: Listings are priced at roughly 4–7× MRR, but a buyer can't verify the revenue multiple they're paying. An agent helping a buyer evaluate Parcel at $9,800 (≈6.8× MRR) has no auditable input — it has to either trust the prose or recommend abandoning the purchase. Combined with the dead demos (issue 3), there is no independent way to confirm the asset is actually generating the revenue claimed.
The fix: For every listing with an MRR figure, publish a methodology line ("trailing 30-day Stripe MRR as of YYYY-MM-DD, refunds excluded") and a redacted Stripe or analytics screenshot in the listing. Add a one-paragraph disclosure at the top of the gallery defining what "current revenue" and "MRR" mean in this catalog. Treat unverified figures as marketing copy, not as price-anchoring data.
7. No Terms, Privacy, or transfer agreement for a service that ships code under a buyer's name and transfers Stripe accounts (significant)
Problem:/terms and /privacy both 404 (rendering the SPA shell), and no DPA or transfer-agreement link is surfaced anywhere on the site. The footer's COMPANY nav lists only How it works, What you can build, Gallery, API & agents, Why Nanowork, FAQ. CONTACT lists only the SMS number, Twitter, LinkedIn. Yet the FAQ says Nanowork helps users "set it up clean from day one, including entity, payments, and IP," the gallery transfers "100% of the code, assets, and accounts" (Stripe wired, customer dashboards), and the "How it works" section says work "ships in your name" — implying the buyer takes legal responsibility for output produced by Nanowork's agents and operators.
Consequence: There is no documented data-handling policy for the SMS thread (which contains business ideas, customer data, and payment context), no liability allocation for code Nanowork ships under a buyer's name, and no agreement governing the transfer of Stripe accounts and end-user PII in gallery sales. An API early-access user has no terms governing $NW_KEY use, output ownership, or rate-limit enforcement.
The fix: Publish /terms and /privacy, plus a transfer-agreement template linked from each gallery listing, before any further transactions. Link them from the footer. Add a separate API ToS for $NW_KEY holders covering output rights, prohibited uses, and uptime expectations.
What they do well
The agent-as-endpoint framing (pitch · ICP · wedge, etc.) is a clean conceptual contract — it just needs an actual schema behind it.
FAQ pricing answer is unambiguous about the recurring offer ("flat $99 per month. No tiers, no per-seat upsells, no usage meters, no equity").
The single curl example for sharpener is complete enough to copy-paste (auth header, content-type, body) — the pattern is right; it just needs to be repeated for the other five agents and to actually return 200.
Top 3 recommendations
Make the API real or take it down. Restore api.nanowork.ai, publish an OpenAPI 3.1 spec covering all six agents with request/response schemas and error codes, and add /llms.txt + /llms-full.txt. Until that's done, remove the fake 200 · 412 ms response chrome from the homepage.
Fix the gallery purchase path end-to-end and back the revenue claims. Restore demo.nanowork.app so every listing has a working demo, fix the malformed sms:&body= query syntax (use ?body=), reconcile the Lamina domain mismatch and the 30-vs-60-day support contradiction, and publish a methodology + screenshot for every MRR figure used in pricing.
Publish legal pages before the next transaction. Ship /terms, /privacy, and a transfer agreement covering Stripe/customer-list/IP handoff, and link them from the footer. A service moving payment infrastructure between parties on a flat fee cannot operate without them.