Skip to Content
We are live but in Staging 🎉
Use CasesEnterprise software

Enterprise software

The outcome

Your company pays for a stack of enterprise SaaS — a CRM, a helpdesk, an HRIS, an ITSM tool, expense, contracts, procurement — and rents every one, forever, on someone else’s schema and someone else’s roadmap. On Dodil you rebuild those systems as software you own and run — the whole application, end to end, on one platform.

Not just the data layer: the entire lifecycle and the runtime. You write the code, Git reviews it, CI builds it, the registry stores the image, and the app itself — frontend, backend, services — runs on Dodil, served publicly or internally, auto-scaling to zero, over your own data. Instead of stitching GitHub + a CI service + a container registry + a PaaS + a database + a vector DB + an inference API into an integration you own forever, it’s one platform, one bill, one auth. And you don’t hand-assemble it — you drive the dodil CLI with Claude and let the agent stand each piece up.

Build and run the whole app on one platform

This is the spine: the full software lifecycle and the runtime, all on Dodil.

  1. Write the code → Dodil Git . Repos, branches, pull requests, reviews, and CI checks — source control lives on the platform, not a separate SaaS.
  2. Build & test → Dodil Git CI . Actions-style workflows run on push/PR — jobs like ci/build and ci/test build the app and gate the merge, reported as checks on the pull request (the console’s Actions tab renders the job graph).
  3. Store the images → Dodil Registry . The CI job pushes the built container image here, CVE-scanned at push.
  4. Deploy & run the app → Ignite Compute / Apps . The same CI job deploys the image, and the actual application — frontend, backend, services — runs here, served publicly or internally, auto-scaling to zero. This is the app itself, not just model inference.
  5. Data layer → DataK3 . SQL + graph + vector + objects in one bucket, over one copy of the rows.
  6. AI → Ignite Models . OpenAI/Cohere-compatible inference for the classify / screen / risk-score / policy-check gates.
  7. Orchestration → Scriptum  (typed, durable workflows); identity → one IAM token across every one of the pieces above.

The git → CI → registry → deploy loop is a single motion: push to Dodil Git , Git CI  builds and tests the app, the CI job pushes the image CVE-scanned into Dodil Registry  and deploys it to Ignite , which rolls out the new version of the running app — auto-scaling, public or internal. Nothing to wire between GitHub, a separate CI runner, a registry, and a PaaS, because it’s all one platform behind one CLI.

The data + AI layer: one bucket, four pillars, a model gate

The systems below share the same data spine. Each is one DataK3  bucket — over one copy of the rows you get all four pillars at once:

  • SQL  — the records: contacts, tickets, incidents, contracts, invoices. Merge-keyed, upsertable, queryable.
  • Graph  — relationships over those same rows: account hierarchies, org charts, CMDB dependency maps, approval routing, party graphs — traversed for rollups and blast-radius.
  • Vector  — semantic search as a column: similar tickets, resume ranking, clause search, duplicate-receipt detection.
  • Objects  — the attachments: documents, receipts, resumes, signed contracts.

An Ignite Models  gate makes the judgment call and writes its verdict back onto the row; K3 pipelines  keep the vector and graph derived columns current as rows change.

Proof: the rebuilds

The team wrote each of these end to end — a named enterprise product, rebuilt on one bucket. They’re the evidence for the data + AI layer; the full lifecycle above is how the running app around them ships. See the full builds on the Dodil blog .

  • CRMreplaces Salesforce — merge-keyed contacts and deals in SQL, an account-hierarchy graph, semantic search over notes, and a cost-gated lead pipeline. (Dodil’s own GTM CRM is literally a DataK3 bucket.) SQL + graph + vector + a model gate.
  • Helpdeskreplaces Zendesk — tickets and a knowledge base in SQL, KB and similar-ticket vector search for deflection, auto-triage / auto-reply. SQL + vector + a model gate.
  • HRIS + ATSreplaces Workday + Greenhouse — workers, positions, and candidates in SQL, the org chart as a graph you traverse, resumes as a vector column you KNN-rank, a screening gate. SQL + graph + vector + a model gate.
  • ITSMreplaces ServiceNow — incidents and changes in SQL, a CMDB dependency graph for blast-radius, similar-incident search, auto-triage. SQL + graph + vector + a model gate.
  • Expensereplaces SAP Concur — reports and receipts in SQL, vector duplicate- and split-detection, an approval-routing graph, a policy-check gate. SQL + vector + graph + a model gate.
  • CLMreplaces Ironclad / DocuSign — contracts, clauses, and obligations in SQL, semantic clause search, a party graph for counterparty concentration, a clause-risk gate. SQL + vector + graph + a model gate.
  • Procurement (source-to-pay)replaces Coupa / Ariba — suppliers, requisitions, POs, and invoices in SQL, a spend graph for concentration risk, contract-clause search, a 3-way-match engine, a gated approval step. SQL + graph + vector + a model gate.

The same data spine powers warehouse rebuilds too: Customer-360 (one bucket instead of Postgres + Pinecone + Neo4j), a marketing leads warehouse (enrich, classify, and link hundreds of thousands of orgs on low-cost inference), a trading-signal warehouse (batch-analyze a filings firehose), and a multimodal e-commerce catalog (image + text search plus analytics).

How you build it

Describe the system to Claude and let it drive the CLI across the whole lifecycle:

See also

  • Use Cases — what teams build on Dodil, and why it ships faster than assembling the pieces
  • CLI · MCP — the typed surface you (and Claude) drive to build this
  • DataK3  — one bucket, four engines, one copy of the rows
  • Ignite  — build from git, deploy, and run the app; Dodil Git  · Registry 
  • Get an Access Token — the single IAM token used across all of it