About Curitics

Curitics builds healthcare software and runs delivery through structured tickets, tight feedback loops, and daily coordination across product, QA, and engineering.
Before Plane, work was split across Jira and Monday. Jira stayed in place for legacy work and enterprise clients. Newer product work moved to Monday. That setup held for a while, then reliability and workflow issues started blocking execution.

The challenge

Monday could not keep up at scale
As the team crossed 2,000 work items, Monday became unreliable during peak working hours. On a weekly basis, the team hit periods where tickets would not load, pages would not open, and status updates would not save. That had actual operational impact,

• standups stalled because the system would not open
• sprint reviews slowed down because updates could not be made live
• the team spent time waiting for the tool, not shipping work

The view problem slowed everyone down
In Monday, the team shared a common view. If one person changed how they filtered or arranged tickets, it changed for everyone. That created friction during QA reviews, screen shares, and role-specific workflows.

Why Plane was the best fit

Curitics chose Plane because it solved the operational failures that were getting in the way of delivery.

Reliable performance under real backlog volume
The team wanted a system that stays responsive even when the ticket volume grows. Plane became the day-to-day workspace because creating, updating, and querying work stayed fast and predictable.

Views, filtering, and sorting that work for each role
Plane let every team member create their own views without affecting anyone else. That changed how reviews and daily execution worked.

• QA can review through a view that matches their workflow
• developers can focus on what is assigned to them and what is in progress
• product can filter by release, cycle, or state without breaking someone else’s setup

“Other tools have filtering and sorting, but it breaks down. In Plane we can distribute the work and see it the way we want.”
The Curitics team

Clear state segregation and cycle reporting
They leaned heavily on ticket states, cycle planning, and end-of-cycle reporting to keep delivery measurable and consistent across teams.

Guardrails that forced better planning
One guardrail was controversial internally: cycles cannot be edited once completed. Some team members wanted backdated edits, but Curitics kept the workflow intact and adjusted by adding schedule leeway where needed.

Implementation and rollout

The transition was straightforward because Plane matched familiar project management abstractions and did not introduce a new learning model.

• active tickets were recreated manually in Plane to restart execution cleanly
• Monday was retained only for historical lookup
• the team rebuilt labels and structure using Plane docs when needed
• adoption was smooth because basic operations were fast and intuitive

Curitics now runs team execution inside Plane, with discussions and decision trails living directly on the work item.

Since adopting Plane

Speed and execution quality improved because the tool stopped being a constraint.

• Faster delivery through faster operations,
  When the tool is responsive, standups, reviews, and ticket updates stop wasting time. The team reported higher output simply because they were no longer fighting the system during peak hours.
• Role-based visibility without conflicts
  Individual views removed the shared-view bottleneck. QA, engineering, and product can each work from the lens they need without disrupting anyone else.
• Stronger workflow discipline through GitHub enforcement
  Curitics integrated Plane with GitHub and added workflow enforcement at the pull request layer.
• PRs must include a Plane ticket reference
• if the ticket reference is missing, the PR fails automatically
• PRs link back to the correct work item so status stays connected to delivery
  This reduced drift between code and tracking and made reviews cleaner.
• Release notes driven by completed work
  Cycle outputs and completed tickets are summarized and used to compile release notes, with a light polish step before publishing.