Hi HN! I kept running into a problem where business rules (pricing, access, flags) were scattered across application code, hard to review in PRs, and even harder to verify.
I built logicrepo as a small experiment to address that. The idea is simple:
Define business rules as YAML
Define tests for those rules as YAML
Run npx logicrepo check in CI — if a rule change breaks expectations, the PR fails
Hi HN! I kept running into a problem where business rules (pricing, access, flags) were scattered across application code, hard to review in PRs, and even harder to verify.
I built logicrepo as a small experiment to address that. The idea is simple:
Define business rules as YAML
Define tests for those rules as YAML
Run npx logicrepo check in CI — if a rule change breaks expectations, the PR fails
Example rule:
- id: enterprise_discount when: customer_tier: enterprise then: discount_percent: 20
Why YAML instead of code?
Non-engineers can read and review changes
PR diffs show intent clearly (“discount went from 20% → 25%”)
Rules are deterministic and stateless by design
No runtime dependency — this only runs in CI
Use cases I’m targeting: pricing/discounts, access control, feature flags, order validation.
This is intentionally minimal: first-match-wins semantics, no runtime execution, and no DSL beyond basic operators (eq, gt, lt, all, any).
I’m mostly curious:
Does this feel like a reasonable tradeoff vs just writing code?
Where would this break down in real systems?
Full docs include examples for pricing tiers, RBAC, and percentage rollouts.
Moves toward the idea of "compile the company."