Packaged software
Fits when
The standard data model and workflow already match the job.
Production responsibility
The vendor runs the product. Your team configures it, drives adoption, and handles the work that falls outside it.
Choose based on fit and who owns production.
First decide how closely the software must match the operation. Then name who will own hosting, identity, credentials, long-running work, failures, and future changes.
Each option puts the production burden somewhere different.
Automation and low-code
Fits when
The job is one bounded automation or internal tool, and the team wants a visual builder.
Production responsibility
Your team owns the connections, shared data, permissions, and failure handling across the assembled tools.
Managed AI
Fits when
The company needs a general assistant with vendor-managed administration.
Production responsibility
The vendor runs the assistant. Your team owns the process, source systems, and any software around it.
Agent framework
Fits when
Engineers need framework-level control over one agent and will build everything around it.
Production responsibility
Your team owns the App, data, identity, deployment, infrastructure, integrations, and operations.
Conventional custom software
Fits when
The requirements need arbitrary code and justify a dedicated software team.
Production responsibility
Your team or development partner owns the architecture, code, hosting, releases, security, and maintenance.
Manual work
Fits when
The process is unstable, low-volume, or cheaper to perform than to formalize in software.
Production responsibility
The operating team handles every step, exception, check, and recovery.
Service provider
Fits when
The business wants an outside expert to define, build, support, and improve the system.
Production responsibility
The contract defines what the provider operates and which business decisions stay with the client.
One system language. One managed runtime.
You define the exact system in .swirls and keep control of its intended behavior. Swirls provides the hosting, durable execution, identity boundary, credential delivery, managed state, and operational history behind it.
You declare
One business system in .swirls
Apps
Data
Workflows
Agents
Connections
Access
Swirls managed runtime
The production services are part of the platform.
Hosting
Serve supported Apps and endpoints.
Durable execution
Carry waits, retries, and long-running work.
Identity and access
Apply supported entry and resource boundaries.
Credentials
Supply stored secrets to declared work.
Managed state
Keep declared records and workflow state.
Operations
Keep runs, traces, reviews, and failures visible.
The business gets
One system that stays in service
People use the App
Events start work
Runs keep their state
The job needs custom fit on one managed production model.
A technically capable builder understands the operation, can direct a coding agent, and will own business correctness as the system changes.
The job is standard, temporary, or needs arbitrary code.
Buy packaged software when it already fits. Use a small automation for a bounded task. Build conventionally when full framework and infrastructure control are requirements.
Bring the job the standard product misses.
Describe the people, rules, data, outside systems, and result. Decide whether the Swirls production boundary fits.