We were tired of manual team check-ins. So we built Trackly to automate it. Thoughts? 🚀
Hey Indie Hackers! 👋
A lot of team productivity tools focus on what tasks are being done, but we realized that teams waste a massive amount of time just doing manual check-ins and updating statuses every single day.
As a team, we wanted to solve this specific bottleneck, so we built Trackly!
Trackly is designed to completely eliminate manual reporting by seamlessly tracking team progress, streamlining standups, and giving project managers a clear bird's-eye view of everything without bugging anyone. No more "Hey, what are you working on today?" pings.
We’ve just shipped the core product, and now that we are Building in Public, we want to validate our core feature set with real builders.
We would love to get your honest feedback on this:
Is manual team status tracking a genuine pain point in your current setup?
What is the number one feature you feel is missing from standard team monitoring tools?
Would you or your team use something like Trackly to cut down on meeting times?
Check out what we've built, and please be as brutally honest as possible with your feedback. We want to iterate fast and build what teams actually need!
Let us know your thoughts in the comments! 👇
That's a fair reframe, the tool doesn't create the culture, it just makes whatever culture already exists more visible. A good manager using this probably gets more trust from their team, a bad manager using the same tool probably just gets a new way to nitpick. Do you think there's anything the product itself could do to nudge managers toward the better use of it, or is that entirely outside what software can influence?
Manual status pings are the real pain, "tracking" itself isn't. Lean hard into "no more pings" over generic PM features, that's your strongest angle. Test with 5-10 team leads who actively complain about standups, not broad productivity buyers. We run a similar signal-to-validation flow at painbase.space if it's useful for ranking segments.
Brutally honest since you asked: yes, manual status-tracking is a real pain, but "automate standups / async status" is one of the most crowded categories in team tooling. Geekbot, Standuply, DailyBot, Status Hero, and Slack's own workflows all own this exact pitch ("no more what-are-you-working-on pings"). The pain is real, but "we automate check-ins" isn't a wedge, it's the category everyone's already in.
The harder question your post doesn't answer: how does Trackly know what someone's working on without asking them? "Track progress without bugging anyone" is the magic claim, and it's where every tool here struggles. If it's still async prompts (bot asks, human types), you're Geekbot. If it pulls status automatically from where work happens (GitHub, Jira, Linear, commits), that's a real differentiator and should be the entire headline. The "no manual input at all" version is the only one that isn't saturated.
To your "what's missing" question: standard tools surface activity, not blockers. Managers don't need to know everyone's busy, they need to know who's stuck. A tool that flags "this person's been on the same task 4 days, likely blocked" beats another status feed. Detect the exception, not the routine.
Who's the buyer, the manager who wants visibility or the team that hates status meetings? Those want opposite things (surveillance vs relief from it), and the positioning splits hard depending on which you build for. That's your whole go-to-market.
Spot on, and brutally useful. You hit the nail on the head regarding the 'vitamin vs. painkiller' dilemma.
To answer your question: No, we definitely don't want to be 'Geekbot with a new coat' where humans still have to manually type everything.
Our core focus is actually moving toward your exact 'killer feature' suggestion—exception and blocker detection rather than just logging daily activity. Currently, we are working on deep integrations with GitHub, Jira, and Linear so Trackly can automatically surface where a developer is actually stuck or spinning wheels for days, without making them feel micro-managed.
Regarding the buyer, we are leaning towards the team/relief model (flat-tier), but your breakdown gave us a lot to think about regarding positioning.
Really appreciate you taking the time for this teardown. This is exactly the kind of feedback we needed.
Manual status updates are a real pain but the risk is a team treating this as one more thing to check instead of something that actually saves them time. What's the moment it reports back, a daily digest, or a real-time ping when something looks off? That distinction usually decides whether managers actually stop pinging people directly.
Great point, Faseeh. That’s the ultimate product-adoption trap we want to avoid.
We are actually planning to solve this by giving managers a customizable digest, but trigger real-time pings only when an anomaly/blocker is detected (e.g., a dev spinning wheels on the same branch for too long). The goal is to make it an 'asynchronous dashboard' they can trust, rather than another feed they have to micro-manage.
That's a much better default than constant pings, only interrupting someone when there's an actual anomaly respects the manager's attention instead of assuming every update deserves a notification. The hard part will probably be tuning what counts as an anomaly without it either crying wolf too often or missing the real ones, how are you thinking about getting that threshold right early on?
That’s the million-dollar question, Faseeh! Early on, we want to avoid over-engineering with complex AI that guesses wrong.
Our approach is to start with user-defined thresholds (e.g., a manager can set 'ping me if a Jira ticket stays in 'In Progress' for more than 3 days'). Over time, as we collect more data on team velocity, we can transition into smarter, automated baselines. Starting simple and giving control to the manager seems like the safest bet to avoid the 'crying wolf' problem.
User-defined thresholds as the starting point makes sense, it's honest about what you can't predict yet instead of pretending an AI model already knows. The interesting failure mode to watch for is managers setting thresholds too aggressively out of habit (3 days becomes 1 day) and recreating the noise problem themselves. Might be worth defaulting to a slightly generous threshold and letting people tighten it, rather than the other way around. Once you're collecting velocity data, what's the first automated baseline you'd trust enough to suggest as a replacement for a manual threshold?
Brother, creating ease is indeed a good thing, but you can't just expect a tool to do it on its own. Instead, this should be addressed to the managers who create difficulties. No matter what tool you give them to make things easier, they will still end up making things difficult.
Fair point, no tool fixes a management problem by itself, if a manager wants to make things hard they'll find a way regardless of what's in front of them. Maybe the honest framing is the tool doesn't fix bad managers, it just removes the excuse that manual tracking was ever necessary in the first place. Do you think a tool like this can shift behavior at all, or is that entirely down to who's actually running the team?
We can say that this software actually creates a lot of ease and fairness. Some managers tend to judge or treat employees poorly based purely on tracking their active status or physical presence. Instead, our dashboard focuses entirely on actual work and output, not their screen time or movements. This is why a hardworking employee actually appreciates a tool like this it ensures their real contributions are clearly visible and recognized fairly.
Framing it as protecting hardworking employees from being judged on presence instead of output is a genuinely different angle than most monitoring tools take, most lean into oversight, this leans into fairness for the person being tracked. Curious if that framing actually changes how employees react to it being rolled out, does it feel less like surveillance to them once they understand that's the intent?
I want to explain that the team might feel this is for their benefit, but making them feel that way isn't in the tool's hands it's in the manager's hands. If they maintain a good attitude, the staff feels great about it. I am giving my own example: we use this app in our own company, and the team doesn't find it scary at all because our manager doesn't make it feel that way. That's why an app is meant to create ease, but people themselves create difficulties for others.