Protect important product rules inside GitLab merge requests.
Mo checks GitLab merge requests against approved business rules before merge. Teams use it to catch pricing drift, permission changes, onboarding flow issues, and other risky logic changes before they ship.
Works with Slack and GitLab. No separate review workflow required.
#pricing-rules
Maya
@Mo approve this
Mo
Approved
"Trial period must stay at 7 days for new users."
!248Open
Update trial config
mo-botbot
Mo — Conflicts found
Approved: Trial = 7 days
MR sets: 14-day trial
mo-bot · business-rule-check
CONFLICT WITH APPROVED RULE
GitLab catches a lot. Mo catches a different kind of mistake.
GitLab can tell you if the pipeline passed.
Mo tells you if the merge request still follows an approved business rule.
That difference matters when the code is technically valid but the product behavior is wrong.
What GitLab teams use Mo for
| Rule area | What changes | What Mo flags |
|---|---|---|
| Pricing | Trial duration, discount logic, plan access | Merge requests that change approved pricing behavior |
| Permissions | Role access, exports, billing visibility | Merge requests that widen access beyond what was approved |
| Onboarding | Activation steps, confirmations, approval gates | Merge requests that skip required onboarding logic |
| Sensitive workflows | Verification, restrictions, approvals | Merge requests that remove or bypass important controls |
How it fits a GitLab workflow
Slack
Approve the rule where the conversation happens
→
GitLab MR
Developer opens the MR normally
→
Mo check
Mo reads the MR and compares it against approved rules
→
Before merge
If the rule is broken, the MR is flagged
Examples of business rules teams check in GitLab
- Trial period must stay at 7 days
- Only admins can export users
- Guest accounts cannot view billing
- Verification must complete before payout activation
- Restricted regions cannot access this feature
- Support users cannot delete customer accounts
- Approval is required before partner activation
- Premium features remain disabled until onboarding is complete
Why merge-request review is not enough
Merge-request review is good at catching implementation issues.
It is much worse at catching logic that quietly drifted away from what product, ops, or leadership approved.
Mo adds a merge-time check for exactly that.
Designed for teams that already live in GitLab
- Fast-moving teams
- AI-assisted teams
- Approval-heavy products
Slack-first input. GitLab-level enforcement.
Teams do not need to move rule definition into another system just to protect a few important behaviors. Slack stays the easiest place to approve rules. GitLab stays the place where merge decisions are enforced.
When needed, rules can also be added from uploaded documents.
FAQ
- Does Mo replace GitLab approvals? No. Mo adds a rule-based check for whether a merge request still follows approved business logic.
- Can teams start from Slack only? Yes. Slack is the primary way teams approve rules and decisions.
- Is this useful only for compliance teams? No. Teams use it for pricing, permissions, onboarding, and other business-critical logic.
- Does it work with GitHub too? Yes. Mo also supports GitHub pull requests.
Used internally at Advante across 12+ projects including:
Catch risky rule drift inside GitLab before merge.
Approve rules in Slack. Let Mo flag merge requests that break them.