# Chromoly product guide

Canonical website: https://chromoly.io
Documentation: https://chromoly.io/docs
Updated: 2026-09-20
Support: hello@chromoly.io

Status (10 September 2026): this guide describes the launch build as it runs on Chromoly’s development environment. Early access opens in January 2027; access is not self-serve yet. Features described here have not yet been used by paying customers.

## Getting started

Chromoly turns a plain-language description into a structured app blueprint, then compiles that blueprint into an app you can preview and edit. Access is currently being prepared for early users. [Contact us for early access](mailto:hello@chromoly.io?subject=Early%20access); the development environment is private.

1. Sign in using an available method and accept the Terms of Service and acknowledge the Privacy Policy.
2. Describe your app, or use Plan to work through the requirements first.
3. Choose an available planning model and processing mode before submitting your description.
4. Review the generated app, add or import records, and test its important actions.
5. Configure any email, Slack or payment connections, then deploy when ready.

Email/password sign-in is the current starting point. Google and GitHub sign-in depend on production configuration; they are not prerequisites for building an app.

## What you can build

Explore the use-case guides: [CRM](https://chromoly.io/custom-crm), [website](https://chromoly.io/website-builder), [booking portal](https://chromoly.io/booking-portal) and [portfolio](https://chromoly.io/portfolio-builder). Each includes an example prompt and a practical review checklist.

### Internal tools

Build apps that help your team manage its day-to-day work:

- **CRMs:** manage companies, contacts, deals and follow-up tasks.
- **Operations dashboards:** track workload, key metrics and trends over time.
- **Booking portals:** manage services, availability, bookings and customer notifications.
- **Invoice and approval tools:** track invoices, payment records and review steps.
- **Onboarding tools:** organise customer checklists, assignments and progress.

### Websites and portfolios

Build business websites, landing pages and portfolios with responsive layouts, project showcases and contact forms. Describe your audience, pages, visual direction and any owner-only content management. You can add a public AI advisor grounded in published content.

### AI automations

Add AI to repeatable tasks inside your apps:

- **Request triage:** suggest a category and priority for incoming requests and route them through a configured workflow.
- **Document processing:** extract fields from supported documents for review before saving.
- **Summaries and reports:** summarise saved records and highlight items that need attention.
- **Drafting:** prepare replies and follow-up messages for a person to review.

Connect the services each automation needs and test the complete flow before enabling it.

### AI agents (planned)

Building AI agents in Chromoly is planned for a future release. It is not currently available as a native build option.

You can combine internal tools and AI automations in the same app. A booking portal does not automatically include invoicing or onboarding; describe the features you need.

### Not for

Games, native mobile apps and consumer apps at scale are outside Chromoly’s intended scope.

## How the build works

The selected AI model plans the build and proposes edits. The compiler assembles the app from its structured definition. Shared components provide tables, forms, charts and business workspaces; the saved blueprint describes the data and behavior.

Generation includes structure and behavior checks. Larger apps can be split into saved phases. A completed build still needs your review with representative records and connected services before it is used for important work.

## Writing a useful prompt

Describe who will use the app, the records it manages, the actions they need, and what should happen automatically. Include the language, reporting time zone and any design preferences. Ask for demonstration data explicitly if you want it.

Example prompt

Build an internal request tracker for our operations team. Let staff submit requests, assign an owner and track status and due dates. Show open requests by category and completed requests over time. Use AI to suggest a category, priority and reply for review. Use a clean, neutral design.

You can request a color by name or an exact hex value. English and Swedish app interfaces are supported. Supported attachments and import controls are shown in the builder and generated app.

## Preview, edit and deploy

Use the builder preview to check navigation, forms, charts and settings. Make changes from the builder controls and review the result before deploying. Open app gives you the app experience without the builder editing controls.

Use the deployment URL shown for your app. Preview is not a disposable data sandbox: actions can save real records or use configured services. Use synthetic records and test credentials for acceptance testing.

### Custom domains

**Availability: built, and not enabled on the platform yet.** Email [hello@chromoly.io](mailto:hello@chromoly.io?subject=Custom%20domain) before you plan around it. Production delivery also depends on your deployment setup and plan. Do not configure DNS from a guessed hostname, and contact support if your deployment screen does not provide the connection details.

Once it is released, the flow will work like this. Deploy the app, then open **Deployment → Custom domain** and enter a hostname such as example.com or app.example.com, without https:// or a path. Add the ownership TXT record shown in Chromoly at your DNS provider and choose **Check connection**, then add the DNS records the hosting provider returns: root domains use A records, and subdomains normally use CNAME records. Open the site when the connection says Connected. DNS propagation and certificate issuance take time, and checking again resumes the saved setup.

Connecting a domain will not purchase or transfer it, and disconnecting will remove the hosting connection, not your registration or DNS records. Only the app owner will be able to add, verify or disconnect a domain, and the included app address stays available either way. The flow covers one hostname at a time: www is connected separately, and redirects and wildcard domains are not included.

## Changing an existing app

Describe the change in the builder, review the affected structure, and test the saved version. Version history and the dependency map help you understand what changed. A version restore does not automatically reverse data edits, sent messages or payments.

### The dependency map

Open an app in the editor and choose **Dependency map**. Select a field, table, API, component, page, route, workflow, integration or role to see what depends on it. Search, filter by type, focus on a highlighted item, or use the relationship list when the graph is crowded. Viewing the map is read-only and uses no AI credits. A blueprint health panel lists deterministic findings with links to the node they concern.

### Reviewing a proposed change

Use **Review changes** before you apply an edit. The review compares the saved version with the actual generated candidate and lists additions, modifications, removals and dependent features. Nodes are marked Safe, Affected or Breaking, and removed items remain visible with their dependents. You can open the same pending candidate in the map, then apply or cancel it in either place. Applying saves a new version and refreshes the map and preview. A review expires when another version is saved, or after 30 minutes.

Safe, Affected and Breaking come from static dependency analysis, not from running your app. A field edit conservatively flags every consumer of its table, and dynamic table names, custom code and external services can have effects the map cannot see. Highlighting means review this dependent, not this is definitely broken. Test the saved version before you rely on it.

### Version history

The editor History tab browses saved versions, compares them and restores one. A restore is guarded against a stale version, and it does not reverse data edits, sent messages or payments.

## The app blueprint

The blueprint, called AppSpec, describes your app’s pages, records, APIs and workflows. The compiler uses it to build the interface and supported behavior. Keep requested features clear so the definition stays focused on your business process.

## Records and imports

Apps start with empty states unless you explicitly request demonstration data. Charts and statistics use saved records rather than invented totals. Add records with forms or use supported CSV imports, reviewing mappings and validation before saving.

Supported record tables can import text-based PDFs for reviewed extraction and export loaded, filtered rows as a PDF report. Scanned PDFs require OCR, which is not included in this flow. A table PDF is not a full dashboard or chart export. Review AI-extracted values before creating records.

## Charts, months and time zones

Reporting apps benefit from category charts and an over-time chart. Supported visuals include bar, line and pie charts. They use real data; a pie chart needs a positive total, and a trend needs a real date field or saved snapshots.

Rolling monthly charts advance automatically in the app’s reporting time zone. You do not need to prompt in a new month. Older fixed reports may need a one-time change to connect their date field. An empty month can appear as zero without creating records or inventing historical activity.

Set your account time zone in Profile and the app’s reporting time zone in its Settings. These are separate preferences. Booking availability uses the booking workspace’s time zone.

## Branding and appearance

App owners can add a name and logo, choose a theme and adjust the app’s appearance. The logo is reused on supported customer booking pages and as the favicon in standalone app views. Embedded previews keep the platform’s tab icon.

**App default** follows the generated design, including its background treatments and restrained section colors. **Light** and **Dark** provide alternative appearances. Owners save the shared theme; supported customer pages can have a separate owner-selected theme. Visitors do not choose the public page’s theme.

Automatic designs include muted colors and neutral palettes. Explicit color requests take priority. Already exported sites need redeployment to receive updated branding.

## Booking portals and payment links

Start with services, descriptions, durations, prices, working hours and a booking time zone. Review the customer page, then enable public booking when ready. The owner workspace includes month/week calendar views, while customers use the booking page and their private management link.

Configure which booking events should notify the owner by email or Slack. Customer emails require a verified sending setup. Owners provide their own one-time, fixed-price Stripe Payment Links for services.

1. Create a payment link matching the service amount and currency in your Stripe account.
2. Configure the booking app’s Stripe webhook destination and save its signing secret and test/live mode in settings.
3. Connect customer email and enable the desired owner payment notifications.
4. Test a booking, its payment email, Stripe payment confirmation and the owner notification before going live.

A successful browser return does not mark a booking paid. The app requires a verified Stripe event with matching booking, amount, currency and mode. Refunds, disputes and tax decisions remain in your Stripe account. Cancelling a booking does not automatically refund a payment.

## Workflows and notifications

Supported workflows connect app events, rules, schedules and reviewed actions. Configure destinations and credentials before enabling delivery. Email and Slack notifications depend on the connected account, permissions and selected event settings.

Review run history when a workflow fails. Missing credentials, revoked access, limits or provider errors can stop a step. A delivery attempt is not proof that a person received or read a message. Use explicit test actions with destinations you control.

## Planning models and in-app AI

**Global planning:** A frontier OpenAI model is the default, with a Claude model as an alternative. **Global in-app AI:** a faster Claude model is the configured runtime model. Calls use direct OpenAI, Anthropic and Mistral integrations; OpenRouter routing has been removed.

**EU processing:** the Mistral route uses separate reviewed planning and runtime models. It is available only when the account, regional and privacy requirements are satisfied. An unavailable EU route stops instead of silently switching to Global.

The model selector and processing details show the choices available in your environment. New releases appear after review. An app without an executable AI feature does not show in-app AI settings just because AI was used to plan it.

All shared-gateway AI requests have audit events, including planning, runtime calls, moderation and retries. The audit records model, provider, timing, outcome and available usage information. It does not store prompts, responses or private reasoning. App-level AI audit is shown when the app contains AI; account-level history covers builder activity.

Built-in AI can use saved records across the app, calculated chart and metric values, and relevant text from saved PDFs. Suggested question cards appear only when their chart or metric data is available. Large record sets use complete calculated totals with selected detail excerpts; document answers use relevant page excerpts. This does not fetch unsaved browser changes, external services or scanned documents automatically.

Use AI for drafts and proposals that people can review. AI can make mistakes. Untrusted records and uploaded content must not be treated as permission to send messages, reveal secrets or perform unrelated actions.

## Connecting services

Use the integration and business settings exposed by your app. Email, Slack, webhooks and booking payment confirmation each need their own setup. A provider name in an example does not mean a ready-made connector exists for it.

Keep secrets in the provided credential fields, never in prompts or customer-visible content. Verify a connection using its test controls and check the receiving service before enabling recurring work. See [integration guides](https://chromoly.io/integrations) for connection patterns.

## External AI client connections (MCP)

**Availability: deployed and verified on our development environment; public rollout is pending.** MCP connections are for Global-mode apps only. Contact [hello@chromoly.io](mailto:hello@chromoly.io?subject=MCP%20access) to check availability before depending on an external client. EU-mode apps cannot enable MCP.

MCP (Model Context Protocol) lets a compatible external AI client use selected parts of your app. You choose its permissions in **App settings → AI client connections (MCP)**. The connection belongs to one app, and no access is selected by default.

### What a connected client can do

- **Read and analyse:** search permitted records, calculate totals and trends, and read saved chart data. Aggregates use a complete bounded set of saved records; a data limit returns an error instead of a partial total presented as complete.
- **Use documents:** search saved PDF text with page citations. Imported CSV records are available through their app tables. Scanned images, arbitrary files and unsaved browser changes are not automatically available.
- **Request app actions:** propose supported booking, invoice, onboarding and other saved actions. Available actions depend on the app. For example, assigning a lead requires an eligible saved lead-assignment action. Business actions use the app’s validation and permitted workflows.
- **Monitor workflows:** inspect progress, results metadata and failures. Request cancellation or resume an eligible failed step without restarting completed work.
- **Stay within your permissions:** access only selected tables, fields, actions and workflows. Documents and chart context have separate grants. Chart access requires all public app tables and fields so partial access is not mistaken for a complete report.

### Connect a client

1. Open **App settings → AI client connections (MCP)** in your app, then manage access as the app owner in Chromoly.
2. Use a compatible client’s remote MCP connection with the app’s connection URL. OAuth sign-in opens a consent screen where you select access and review the client’s destination. Clients supporting Bearer tokens can use the configuration template and a token displayed once.
3. Select the smallest useful set of tables, fields, actions and workflows, choose an expiry and review the data-sharing notice. Nothing is shared until you approve the connection.
4. Test a permitted read, then review a proposed action in Chromoly before using the connection for work. Client compatibility and availability must be checked during rollout.

Connection expiry options are 7, 30 or 90 days. OAuth uses short-lived access tokens and rotating refresh tokens within that connection’s lifetime. A new app version requires a new connection and a fresh permission review. Never put tokens in prompts or support messages.

### Review actions and stop access

**Record changes, app actions and workflow controls require owner approval in Chromoly.** The external client cannot approve its own requests. Review the exact input before approving or rejecting it. Direct record edits do not execute business actions or their hooks; use a supported app action for a business operation.

Use **Disconnect all AI clients** or revoke a single connection to block future access and reject pending requests. This does not stop already approved workflows; cancel eligible runs separately. An external action already in flight cannot be recalled. Safe retry is available only for confirmed eligible failures; uncertain outcomes require review.

Connection activity records access and approval events. Workflow history shows run progress separately. External clients process shared data under their own provider’s terms; they do not inherit Chromoly’s in-app AI provider or EU processing controls. MCP does not expose blueprint editing or unrestricted autonomous access. Chromoly does not offer a public REST API.

## Plans, credits and custom requirements

The landing page lists planned Free, Builder, Pro and Managed offers. Builder (€99/month, 3,500 credits) is for building and launching your first system. Pro (€299/month, 10,000 credits) includes Builder features with more monthly credits and priority email support, for teams running multiple systems. Both are self-service plans; personal implementation and ongoing development are quoted under Managed. Custom domains are planned for both paid plans, with setup included in the agreed Managed scope; platform rollout is pending and domain registration is separate. See [custom domain availability](https://chromoly.io/docs#preview-deploy). Managed has custom pricing following a discovery call. [Book a discovery call](https://calendly.com/hello-chromoly/30min). We map your workflow, build your system to an agreed scope and maintain it. The initial build and ongoing service are quoted separately; your proposal defines the credits, revision rounds and acceptance criteria. Managed includes priority direct support with an initial response within one business day, and direct feature and integration requests. Larger changes and integrations are scoped and quoted separately. [Review the current offer](https://chromoly.io/#pricing) or contact [hello@chromoly.io](mailto:hello@chromoly.io?subject=Custom%20plan) about a custom plan.

Planned extra credit packs for paid plans are 3,500 for €119, 10,000 for €329 and 50,000 for €1,499. These are one-time top-ups; purchased credits carry over and monthly credits are used first. Packs can be purchased again when needed once checkout is available. Contact [hello@chromoly.io](mailto:hello@chromoly.io?subject=50%2C000%20credit%20pack) about the 50,000-credit pack. Credit-pack checkout is not available yet. Purchasing depends on the production billing configuration. Your account’s plan, credit balance and checkout terms determine its actual allowance. Do not infer an unlimited build allowance or a fixed number of builds from a credit balance; model choice and build size affect usage. Automatic credit top-ups are not currently available.

## Data processing and access

Chromoly uses Supabase in Ireland for its application database. Database location is separate from AI processing location. Global AI requests may be processed outside the EU and use the relevant provider’s commercial retention terms.

The EU AI route requires regional controls, applicable processing terms, training restrictions and zero-data-retention coverage for supported stateless requests before activation. ZDR approval alone does not establish where all processing occurs. Custom integrations have their own data flows.

Access controls, audit history and privacy settings support responsible operation. The correct legal basis, customer notices, retention choices and configuration still depend on your use case. Review the [Privacy Policy](https://chromoly.io/privacy), [DPA](https://chromoly.io/dpa) and [subprocessor list](https://chromoly.io/subprocessors) before sending personal data.

## Your data and account

Use the record export controls available in your app. Contact support about blueprint exports, account deletion or migration requirements. A saved version and an exported record set serve different purposes; confirm what you need before deleting data or cancelling a service.

## Support

**Email [hello@chromoly.io](mailto:hello@chromoly.io)** for setup help, build problems, billing questions and privacy requests.

For a build problem, include the app name or build reference, what you expected, what happened, and the approximate time with your time zone. A screenshot without private customer data helps. Never email passwords, API keys or payment secrets.

For larger deployments, integration requirements or a support agreement, contact us before rollout. Do not assume an uptime or response-time SLA unless it is included in your agreement.

## Languages

Generated app interfaces support English and Swedish. State the desired language in your prompt. Language does not determine the reporting time zone or automatically convert currencies; specify those separately.

## Larger apps and build limits

Larger structured apps are generated in saved phases so completed work can be reused. Builds can queue, pause for provider limits or stop when validation fails. Follow the displayed recovery guidance and keep the build reference when contacting support.

There is no promise that every app size or prompt will succeed. Hosting limits, model capacity and end-to-end workload tests determine real capacity. Discuss a large rollout with us before relying on it.

## Key terms

- **AppSpec:** the structured definition compiled into your app.
- **Planning model:** the AI that interprets your requirements and proposes the build.
- **Runtime AI:** AI used by a feature inside an app.
- **Audit trail:** recorded events that help explain who did what and when.
- **Processing mode:** the configured region and provider policy for AI requests.