Ship the Process, Not the Code.A production backend in days.
Flows, tables and endpoints are validated configuration Kipory checks on every save. A lean team runs them live, with AI that stays bounded, metered and on the record.


Our Pillars


Complex business logic at zero-code pace
A product on Kipory is a project: its flows, tables, endpoints, triggers, schedules, vocabularies and events are configuration rows, checked on save and authored through the design API or the operator UI. A save that would break a step is refused, and anything still unwired is reported as an open issue. Nothing is compiled or deployed, and a change can be dry-run against the live project before it is made.
- The Project as One Document
- Endpoints in Three Shapes
- Sign-In for the Product’s Users
- Schedules, Triggers and Sources
- Built-In Reach


One data layer: relational, graph and semantic
Tables hold typed, schema-validated records. Relations link them into a graph you can assert and walk. An embedding profile makes a table searchable by meaning - so one query filters on fields, follows links and ranks by similarity, with no pipeline between three stores. Vocabularies classify records across all three.
- One Query Across All Three
- Search Declared, Not Built
- Scores and the Matching Passage
- Self-Filing Vocabularies
- Swappable Embedding Models


LLM capabilities at a predictable cost
Every model call - generation, extraction, classification, embedding, transcription - is a step with a named model and a price in credits. Spend is metered per step, run and project; spending stops at a budget ceiling, with a warning on the way; what a run or preview cost is readable the moment it finishes. Each step chooses its own model, so routine decisions run on small, fast models and only hard ones pay for a large one.
- Decision Steps
- Prices Before the Spend
- A Ceiling per Kind of Spender
- Models Bound to Tasks
- Repeat Work From Cache


Deterministic and agentic AI in one hybrid core
A flow is a typed graph of steps. Deterministic handlers fetch, parse, store, branch, fan out and merge; model steps decide, extract, classify and write inside that structure. The model never controls the shape of a run - the flow does - so intelligent behaviour stays bounded and repeatable. Sub-flows and loops compose larger processes from proven parts.
- Typed Handoffs
- Rule-Based Routing
- Bounded Loops
- Per-Item Judgement, Reusable Parts


Full observability and auditing
Every run keeps a complete step log - never sampled - and a record of every write it made; sampled runs also keep a trace of what each output actually held. Compare a good run with a bad one, find the step that moved, reprocess the records it touched. Spend, events and configuration history are readable the same way, so the system can always account for what it did and why.
- One Run ID for Every Execution
- What Each Run Wrote
- The Exact Version That Ran
- Warnings That Tell Cases Apart
- Refused and Model Calls on Record


Testing and quality control built into every flow
An eval suite pins what “working” means: cases with pass/fail assertions, and scorer flows where quality is a matter of degree. A suite can re-run on its own when its flow changes, and a run-to-run comparison says whether a change made things worse. Saves are checked against dependents, so a flow cannot quietly break the endpoints and tables that rely on it.
- Contract Suites
- Scorer Flows With a Noise Floor
- Rehearse Any Change
- Dependents Protect Themselves
- Checkpoints and Regression Alerts