Documentation
Chromoly is an AI-native business platform that replaces fragmented tools with one intelligent system. These docs cover everything you need to go from a plain-language description to a live, maintained system. Short by design - the platform does the heavy lifting, these docs explain what happens and what to expect.
Chromoly builds the software a business runs on: structured data, screens for working with it, workflows that move it, and AI where judgment is needed. If your process lives in a spreadsheet, an inbox, or someone's head, it's probably a fit.
Unsure about an edge case? Describe it in the prompt anyway - if it's out of scope, Chromoly says so before any credits are spent, and often the underlying process (the data and workflow behind the idea) is buildable even when the original framing isn't.
Plenty of tools generate an app from a prompt. The difference is what happens after - Chromoly is built for the years a system runs, not the minutes it takes to generate.
Comparing against a specific tool? We keep honest side-by-sides, including where the other tool wins: vs Retool · vs Zapier · vs Lovable · vs Bubble · vs Airtable · vs n8n · vs Power Apps · vs Make · vs Glide · vs Bolt.
You don't need perfect prompts - you can refine everything afterwards through chat. But a good first prompt saves iterations. Include:
A CRM for my agency. Leads come in via a form and email. Score each lead with AI against our ideal customer profile, route hot leads to the right person with a Slack alert, and remind the owner if a lead sits untouched for 3 days. Pipeline stages: New, Qualified, Proposal, Won, Lost.
Vague prompts still work - Chromoly asks follow-up questions or makes sensible assumptions and shows you the result to react to.
The prompt box accepts an attachment (.csv, .xlsx, .pdf, images, .docx). A spreadsheet does double duty: Chromoly reads its columns to shape the data model and imports the rows as your starting data - so "build a CRM from this" with your lead export attached gets you a working system with your leads already in it. A PDF or image gives the generator context, like a sample invoice for an extraction workflow.
If you'd rather not write a prompt at all, switch to the "Plan it with me" tab. Chromoly leads a short scoping conversation - what the system should manage, who uses it, where the process breaks today - and produces a build brief: the system, data, process, automations, and users, each editable. Nothing generates until you approve the brief, and the generation cost is shown on the button before you click it.
Every build has two environments:
{your-app}.artivex.app or your own custom domain (paid tiers).The rule never bends: every change is previewed before it goes live. That applies to the first generation and to every edit after it.
Every deploy is versioned. If a change causes a problem in production, open the build's deploy history and restore the previous version - the system returns to its last known-good state, and the change goes back to preview for fixing. Your records are not rolled back, only the system definition (screens, fields, workflows).
Live systems run on {your-app}.artivex.app by default. On paid tiers you can serve a build on your own domain:
portal.yourcompany.com).CNAME pointing your subdomain at Chromoly.Your team and your clients then log in at your domain - Chromoly branding does not appear in their flow.
Systems with a client-facing side (portals, approval flows) have two kinds of users: your team, and your clients' end users. End users get their own login - invite them by email from the system, or let them sign in via magic link. They see only the screens built for them (their projects, their invoices), never your internal views, and every end user's data is isolated the same way tenants are. End users are included in your plan - there is no per-seat pricing in either direction.
This is the part most tools get wrong, and the reason Chromoly exists. Change anything by telling the chat what you want ("add a budget field to projects and include it in the weekly digest"). Before applying, Chromoly checks the change against the system's dependency manifest - the map of what uses what.
Renaming a field that three workflows depend on silently breaks a Zapier stack. On Chromoly it produces a warning that names the three workflows, and the change updates them together.
Under every generated tool sits a structured data model:
Every entity automatically gets list, detail, create, and edit screens plus a REST endpoint. You never design a database - describing the tool defines the model, and you can inspect and refine it in plain language.
Any entity exports to CSV or JSON from its list screen, and the full system blueprint (the AppSpec: entities, fields, workflows, screens) exports from build settings. There is nothing proprietary holding your data - leaving Chromoly with everything is always possible, which is exactly why people stay.
Workflows are the automation layer inside a build. Each has a trigger, steps, and failure handling. Up to 20 workflows per system.
AI is available wherever a workflow needs judgment: classify, summarise, extract, score, draft. AI steps run on current frontier models (latest Claude and GPT models), with cost caps, retries, and provider fallback built in. Not every tool needs AI - a plain approval tracker generates without any - but it is native when you want it.
Any workflow step can require human approval. Gated items queue in a review inbox instead of executing - use it for anything consequential: sending external emails, changing money-related records, AI decisions below a confidence threshold. Nothing bypasses an approval gate, including MCP calls from connected AI clients.
Failed runs never disappear silently. Every run is logged with status and error detail, failed steps retry with backoff, and repeated failures alert you. Run history is visible per workflow.
Four connection types ship in V1: inbound webhooks, outbound webhooks, email, and Slack. Step-by-step recipes for popular tools live on the integrations page. Webhooks cover most connections in practice - if the other tool speaks HTTP, Chromoly talks to it. Native integrations (inbound email, calendars, accounting) arrive after launch.
Use these when another tool should start a workflow - a form submission, a payment event, a new row in another system.
curl -X POST {your webhook URL} \
-H "Content-Type: application/json" \
-d '{"name": "Anna Berg", "email": "anna@example.com", "source": "webinar"}'
The payload's fields map to workflow inputs - describe the expected shape in your prompt, or send a test request and map the fields Chromoly received. Requests can be verified against the signing secret, so nobody who guesses the URL can inject data. Every received request appears in the workflow's run history, including rejected ones.
Any workflow step can call an external API: method, URL, headers, and a JSON body built from your data ("when an invoice is approved, POST it to our accounting tool"). API keys for these calls are stored encrypted as credentials, never typed into the workflow itself. Failed calls retry with backoff and show up in run history with the response the other side returned.
Workflow steps can send transactional email (reminders, digests, client notifications) and post to Slack channels via a webhook URL from your Slack workspace. Both are described in plain language: "email the owner if the lead is untouched for 3 days", "post won deals to #sales".
Every deployed build exposes its own MCP endpoint, so AI clients like Claude, ChatGPT, and Cursor can work with your system directly: query data, create and update records, trigger workflows, check dependencies before changes, and read audit logs.
read - you can always create a second token with more access). The token is shown once; store it somewhere safe.https://{your-app}.artivex.app/mcp{
"mcpServers": {
"my-crm": {
"url": "https://{your-app}.artivex.app/mcp",
"headers": { "Authorization": "Bearer {your token}" }
}
}
}
Then just ask: "which leads went cold this month?", "log a call with Nordic Supply and set a follow-up for Friday". The AI sees tools named after your actual entities (list_leads, create_task, trigger_follow_up), so it understands your system without any prompting gymnastics.
read (query only), write (query, create, update, trigger), or admin (adds dependency checks and audit access). AI clients only see the tools their token allows.Credits meter what the platform does for you. Every tier includes a monthly allowance; top-ups never expire.
| Action | Cost |
|---|---|
| Generate a new system | ~60 credits |
| Chat edit to an existing system | 0.5 credits |
| AI step execution in a workflow | 0.4 credits |
| Automation run (non-AI) | 0.02 credits |
The free tier includes 150 credits per month - enough to generate a system and test it properly. Paid tiers start at $59/month. Full tier details are on the pricing section. Running low never breaks a live system: automations keep working, and you're warned well before the limit.
| Limit | Value |
|---|---|
| Entities per system | 20 |
| Fields per entity | 50 |
| Workflows per system | 20 |
| MCP requests (Free) | 10/min per token, 500/day per build |
| MCP requests (Starter, Builder) | 60/min per token, 10,000/day per build |
| MCP requests (Studio, Scale) | 120/min per token, 50,000/day per build |
The size limits are generous for real internal tools - a system approaching them is usually two systems. If you genuinely need more, talk to us about Enterprise.