From one domain
to a working server.
Nothing here is a stub. Every stage runs against real APIs, the live web and a real database. Where a credential is missing the stage degrades to a weaker but honest fallback, and says so.
Brand resolution
The Brandfetch Brand API returns the company record for the domain, and the Search API finds near matches for when the typed domain is the email domain or a regional site. The picker is keyboard first: arrow keys move, Enter selects. From that point the palette and marks are the real ones.
Brandfetch Brand API and Brand Search API, cached per vendor domain for thirty days.
Technology detection
Five independent sources, each contributing evidence rather than a verdict. BuiltWith for live web technologies. Fingerprints in the page source and response headers. Vendor names in press releases, case studies and job postings found through targeted search. A language model to infer the back office, which leaves no web trace at all. Scores combine with a noisy-OR, so three moderate sources beat one strong one, and everything is shown with the snippet that produced it.
Where a category is uncovered, the flow asks rather than guessing. The answer is saved against the company, so nobody has to answer twice.
Schema synthesis
Fourteen of the most common systems ship with hand-written manifests carrying the vendor's real object names, field names and picklist values. Anything else is synthesized: the vendor's API reference and MCP documentation are fetched from the live web and turned into a relational model. Manifests are cached per vendor, not per company, so the expensive work happens once globally.
Curated today: salesforce, hubspot, netsuite, zendesk, google-analytics, tableau, facebook, jira, stripe, shopify, workday, slack, servicenow, snowflake.
The world
One cast of characters is generated per instance and every system draws from it. The same fictional customer is a Salesforce account, a NetSuite invoice, a Zendesk organization and a Shopify buyer. The same employee owns the deal, answers the ticket and posts in Slack. Products, business lines and named leadership come from the company's real public profile.
Customer names are deliberately fictional, so nothing here can be mistaken for a leak.
Record generation
A language model writes exemplars: what a support ticket at this company actually says, what a deal is called, what a customer complains about. A seeded pseudo-random generator expands those to full volume, assigns foreign keys from the rows actually inserted, and shapes the numbers. Quantity times price equals the total. Funnels narrow. Closed deals have a reason. Every value is a pure function of the instance seed, the table and the row index, so re-seeding reproduces it exactly.
Model responses are cached by content hash, which is what makes the whole dataset deterministic.
Provisioning
A separate Postgres service per instance on Railway, with its own TCP proxy and its own credentials, created through the Railway public API. On deployments without a Railway token, instances become dedicated databases and roles on a shared cluster instead. Either way the isolation is real and either way the teardown is real.
Spinning down means the service is deleted, not paused.
Servers and documentation
One MCP server per system over Streamable HTTP, tools derived from the manifest, plus whatever bespoke tools the curated manifest defines. A REST API on the same schema. OpenAPI 3.1 generated from the same manifests that built the tables, so documentation cannot drift from data.
Every tool is read-only and every identifier is checked against the manifest before it reaches Postgres.
Knowledge graph
Deep research on the company: its own site crawled politely and within robots.txt, plus news, filings and third-party coverage found through search. Pages are stored once per domain and shared by every employee who signs up. Entities and relationships are extracted, passages are embedded, and both semantic search and graph traversal are exposed over their own MCP server. Refreshing re-reads only what changed.
This is the one part of an instance that is true rather than synthetic.
Four ways a database gets spun down
TTL
A free instance dies at twenty four hours. No exceptions, no grace, no manual override.
Entitlement
When a subscription lapses the instance drops to the free tier and inherits its clock.
Idleness
A paid instance nobody has touched in a week hibernates. The schema survives; the database does not.
Ceiling
Above a global concurrent-instance limit, the oldest free instances are reaped early.
Each check runs every minute and each one is sufficient on its own. Every teardown is written to the instance’s activity log, so nothing disappears without an explanation.
Try it on your own company
No account needed until there is a database to build.