asad ullah open to work

Manifestly Checklists

role
Full-stack engineer
client
Manifestly
stack
Ruby on Rails, PostgreSQL, Slack API
when
A few weeks
outcome
Built the conditional-logic engine that lets a checklist step branch on a prior answer, as a scoped feature contract
demo
live
Screenshot of the Manifestly Checklists homepage
Manifestly's public site — the conditional-logic engine ships inside the product shown here

The product

Manifestly is a checklist and workflow app for teams: reusable templates for recurring processes, role-based assignments, dynamic due dates, conditional logic, and a searchable run history for compliance. It integrates with Slack, Microsoft Teams, Salesforce and webhooks, and ships iOS and Android apps. Customers lean toward audit-heavy, regulated work — banking, financial services, managed service providers — alongside onboarding and IT runbooks.

The problem

Checklist steps were linear: every run showed every step, whether it applied or not. Teams with real branching processes (different steps depending on an earlier answer) were working around it with duplicate checklists per branch.

What I built

A conditional-logic engine: a step’s visibility and required fields can depend on the answer given earlier in the same run. Runs still keep a complete, searchable history for compliance regardless of which branch they took.

Decisions and tradeoffs

  • Evaluated conditions server-side against the run’s stored answers rather than in the client, so the same logic governs the web app, the mobile apps and the webhook payloads without three separate implementations.
  • Kept the rule model to simple field comparisons (equals, contains, one of) rather than a general expression language, since every real request from their support queue fit that shape and a full rules DSL wasn’t needed.

Outcome

Shipped and merged into the product as a scoped feature contract — fixed price, defined scope, no ongoing retainer.