Founder Story: Why We Created Tickr

It was a Wednesday standup. Nine people on a call. The first fifteen minutes were spent figuring out what everyone had actually done since Monday.

Not because people weren't working. They were. They'd shipped features, closed bugs, unblocked each other in Slack threads that moved at a hundred messages an hour. The work was happening. The board just didn't know about it.

Our JIRA board said "Sprint 47." The last meaningful update was twelve days old. Three tickets were marked "In Progress" by people who'd finished them a week ago. One was assigned to someone who'd left the company.

And there we were. Nine people. Thirty minutes. Trying to reconstruct reality from a tool that had stopped reflecting it.

That was the morning we decided to build Tickr.

---

The pattern we couldn't unsee

Once you notice it, you see it everywhere. Every team we've been on, every company we've worked at, the same thing happens.

Week one: the board is pristine. Tickets created. Sprint planned. Everyone committed.

Week two: three people update. Two forget. The PM sends a gentle reminder in Slack.

Week three: the PM sends a less gentle reminder. Somebody batch-updates five tickets at once with "done" and no context.

Week four: the board is fiction. The real status lives in Slack DMs the PM can't see. The standup exists to manually reconstruct what the tool was supposed to track automatically.

We've watched this cycle repeat at four different companies across six years. The tool changes — JIRA, Asana, Linear, Notion — but the outcome doesn't. The board goes stale. The status meeting fills the gap. And everyone accepts this as normal.

We stopped accepting it.

The question that changed everything

The obvious reaction is "we need a better board." A faster one. A prettier one. One with fewer fields and better shortcuts.

That's what Linear did, and Linear is genuinely great. But we kept coming back to a different question:

Why does the board live somewhere else?

Your team makes decisions in Slack. Context lives in Slack. Blockers surface in Slack. Status updates happen in Slack — informally, in DMs and threads, a dozen times a day.

But the task board? That lives in a separate app, in a separate tab, behind a separate login. So you end up in a loop:

1. Update JIRA
2. Tell people in Slack you updated JIRA
3. Wait for them to check JIRA
4. They don't
5. Ask again in Slack
6. Give up and just tell them the status in Slack

The tool that was supposed to eliminate status chasing had become another thing to chase people about.

The insight wasn't "build a better board." It was: the board should come to you.

What the best PM we ever worked with taught us

Before we wrote a single line of code, we thought about the best project manager we'd ever worked with. Not the best tool. The best person.

She didn't need a dashboard. She walked the floor. She asked the right question at the right time — not in a standup, but in the moment, when context was fresh. She remembered what you said last Thursday about being blocked on the API and followed up Monday morning. She didn't let "working on it" slide as a status update. She'd push back: "Working on what? What's the next milestone? When should I check in again?"

She was persistent without being annoying. She had a sense for when to nudge and when to give space. She knew that when work was stuck, the person to ping wasn't the assignee who was waiting — it was the person causing the block.

She was, in every sense, present where the work happened.

We wanted to build that person. Not as a human you have to hire and hope they don't burn out. As an AI that lives in the tool your team already has open eight hours a day.

What we almost got wrong

The first prototype was too aggressive. It pinged people every two hours regardless of priority. It felt like a nagging parent, not a thoughtful colleague. Three people on our own team muted the bot within 48 hours.

That failure taught us the most important design principle in Tickr: persistent, not annoying.

There's a line between helpful and irritating, and most notification systems don't even try to find it. We spent weeks tuning the nudge cadence:

• Critical tasks get checked 4x more often than low-priority ones
• Grace periods after updates — if you just posted a status, Tickr backs off
• Snooze is a first-class feature, not an afterthought
• Escalation matches urgency — a low-priority documentation task doesn't deserve the same energy as a production blocker

The second thing we almost got wrong was accountability direction. Early versions nudged the assignee when a task was stuck. Standard behavior for every PM tool on the market.

But think about it: if Maya's deploy task is blocked because Jatin hasn't reviewed the infra PR, why are we pinging Maya? She already knows. She's frustrated. She's been waiting.

Tickr pings Jatin. "Hey, you're flagged as a blocker on Deploy to Prod. Maya's waiting on your PR review."

Blame the bottleneck, not the blocked. Accountability should be accurate, not just automated.

Building in Slack, not on top of it

A lot of Slack bots feel like a remote control for a different app. You click a button in Slack and it opens a browser window. Or you fill out a modal that looks nothing like Slack. The bot is a wrapper, not a native experience.

We wanted Tickr to feel like it belongs in Slack. Like it's a teammate, not a plugin.

That meant natural language from day one. Not slash commands with mandatory fields and rigid syntax. You say:

@Tickr create a task for @maya to set up staging, high priority, due Friday

And Tickr understands context, resolves dates, assigns the right person, and creates an interactive card with Update, Complete, and Blocker buttons — right in the channel where the conversation is happening.

It meant building the live board as a Slack Canvas that updates automatically. No external dashboard. No "click here to see the board." The board is in your channel, updating in real time as tasks move.

It meant making /tickr highlights and /tickr lowlights generate AI summaries of what shipped and what stalled — with names attached, ready for your standup or retro — without anyone having to compile a report.

Every feature we built, we asked: can someone use this without leaving Slack? If the answer was no, we redesigned it until the answer was yes.

What we believe

Four principles guide every decision we make on Tickr:

Where we are now

Tickr is live. Teams are using it to manage real work in real Slack channels. Every day we're learning what works, what doesn't, and what "just tell Tickr" can handle that we haven't thought of yet.

We're not trying to replace JIRA for 10,000-person enterprises with compliance requirements and custom field hierarchies. We're building for the team of 8 that needs to ship fast, the agency juggling five client channels, the ops team whose "board" was always just a Slack channel anyway.

We built Tickr because we were tired of managing the tool that was supposed to manage our work. The project tracker should do the tracking — and the follow-up — so you can focus on the work that matters.

If that sounds like your team, we'd love to hear from you.