Documentation

How Chromoly works

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.

On this page
  1. Getting started
  2. What you can and can't build
  3. What makes Chromoly different
  4. Writing a good prompt
  5. Preview and deploy
  6. Changing a live system
  7. Entities, fields, records
  8. Workflows and AI steps
  9. Integrations
  10. MCP: connect your AI
  11. Credits
  12. Security and your data
  13. Limits and fair use
  14. Glossary

1. Getting started

  1. Sign up free. The free tier is permanent - 150 credits per month, no card required.
  2. Describe what you need in the prompt box. Plain language. One tool per prompt.
  3. Review the preview. Chromoly generates a working system - real screens, real data model, real workflows - in a preview environment. Previewing costs nothing beyond the generation itself.
  4. Deploy when it's right. One click moves the reviewed version live. Nothing reaches production without your approval.

2. What you can and can't build

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.

Good fit

Not 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.

3. What makes Chromoly different

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.

4. Writing a good prompt

You don't need perfect prompts - you can refine everything afterwards through chat. But a good first prompt saves iterations. Include:

Example prompt

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.

Attach a file

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.

Plan it with me

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.

5. Preview and deploy

Every build has two environments:

The rule never bends: every change is previewed before it goes live. That applies to the first generation and to every edit after it.

Rolling back

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).

Custom domains

Live systems run on {your-app}.artivex.app by default. On paid tiers you can serve a build on your own domain:

  1. In build settings, open Custom domain and enter the domain you want (for example portal.yourcompany.com).
  2. Add the DNS record shown there at your DNS provider - a CNAME pointing your subdomain at Chromoly.
  3. Verification and the SSL certificate are automatic once DNS propagates (minutes to a few hours).

Your team and your clients then log in at your domain - Chromoly branding does not appear in their flow.

Giving clients access

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.

6. Changing a live system

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.

7. Entities, fields, records

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.

Importing existing data

  1. Export your current data (spreadsheet, old CRM) to CSV - one file per entity.
  2. On the entity's list screen, choose Import CSV and map your columns to the entity's fields. Unmapped columns are skipped, and rows that fail validation are reported instead of silently dropped.
  3. Import into preview first if you want to sanity-check the result before it touches live data.

Exporting your data

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.

8. Workflows and AI steps

Workflows are the automation layer inside a build. Each has a trigger, steps, and failure handling. Up to 20 workflows per system.

Triggers

AI steps

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.

Human in the loop

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.

Failure handling

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.

9. Integrations

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.

Receiving data: inbound webhooks

Use these when another tool should start a workflow - a form submission, a payment event, a new row in another system.

  1. Give a workflow the trigger type Webhook (say it in the prompt, or add it in chat: "trigger this when my Typeform sends a submission").
  2. Chromoly generates a unique URL for that trigger, shown in the workflow's settings along with a signing secret.
  3. Paste the URL into the sending tool. Send JSON via POST:
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.

Calling other tools: outbound webhooks

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.

Email and Slack

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".

10. MCP: connect your AI to your tools

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.

Set up in three steps

  1. Create a token. In build settings, open MCP access and create a token. Pick the scope (start with read - you can always create a second token with more access). The token is shown once; store it somewhere safe.
  2. Copy your endpoint URL. It's shown on the same screen: https://{your-app}.artivex.app/mcp
  3. Add it to your AI client:
    • Claude - Settings → Connectors → Add custom connector. Paste the endpoint URL and the token.
    • ChatGPT - Settings → Connectors → Add MCP server with the URL and token.
    • Cursor / other IDE clients - add the server to your MCP config with the token as a bearer header:
    {
      "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.

The rules that keep it safe

11. Credits

Credits meter what the platform does for you. Every tier includes a monthly allowance; top-ups never expire.

ActionCost
Generate a new system~60 credits
Chat edit to an existing system0.5 credits
AI step execution in a workflow0.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.

12. Security and your data

13. Limits and fair use

LimitValue
Entities per system20
Fields per entity50
Workflows per system20
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.

14. Glossary