vietnamese mud crabdifferent species of crabsoft-shell crab
4
12 Comments

Day 1 of building TeamAutomation in public — here's the problem I'm trying to solve

Hey everyone — starting a "build in public" thread for something I've been working on called TeamAutomation.
The problem I kept running into (and hearing from other ops/remote folks) is approvals just... disappearing into Slack. Someone needs a sign-off on a purchase, a contract, a piece of content — they post it in a channel, and then it's buried under 50 other messages within an hour. Nobody's ignoring it on purpose, it's just noise.
So the idea is simple: structured approval requests directly inside Slack — a clean card with Approve/Reject buttons, automatic nudges if it sits too long, and a full audit trail so nobody's digging through scroll history to find "who approved this and when."
I'm just getting started — no users yet, building everything in public as I go.
Curious how you all handle this on your teams right now — is it just Slack threads and hoping people see them? Some other tool? Or has anyone actually solved this well?

posted to Icon for group Building in Public
Building in Public
on June 12, 2026
  1. 1

    The "buried in Slack" pain is so real. On the teams I've worked with, the pattern I saw was: people who needed sign-off would DM the approver directly instead of using the channel — which meant the audit trail was gone and only one person knew the decision happened.
    Curious how you're thinking about that DM workaround behavior. If your tool makes the channel approval easier than a DM, you win. If the DM still feels faster, people will route around it.
    Day 1 solidarity. I shipped my own thing yesterday and I'm sitting with the same "no users yet" feeling today.

    1. 1

      Quick question — on the teams you worked with, what finally made them switch from DMs to a proper approval tool? Was it a compliance incident, a missed approval, or just someone pushing for process?

      Trying to understand what the "trigger event" is that makes people actually change behavior.

      1. 1

        Almost always something that already went wrong publicly. A campaign that went out without sign-off. A budget that got spent. Something embarrassing that made someone look bad in a meeting. Compliance risk is real but slow — people don't move on "this could happen." They move on "this just happened to me."

        1. 1

          Hey Kalai — your trigger event insight was spot on. Would you want to be one of the first to try it? Free during beta, 2 min install: teamautomation.app

    2. 1

      This is exactly the behavior I'm designing against. The bet is: if /approve is as fast as a DM (same Slack window, one command, instant buttons) but ALSO logs everything automatically, there's no reason to DM instead — you get speed AND audit trail for free. Going to test this directly with early users. Thanks for naming it so clearly.

  2. 1

    The pain is real but the wedge is crowded.

    Existing solutions for Slack-based approvals: Slack Workflow Builder (native, free, basic approval flows), Polly, Workast, Approval Donkey, Kissflow Slack app, Pipefy Slack integration, Process Street Slack, Fellow.app for meeting actions, Zapier with Slack approval steps. Bigger players: Tonkean, Workato workflows with approval gates.

    The "approvals get buried in Slack" pain isn't novel — it's well-known. Question is what makes TeamAutomation defensible against Slack's own Workflow Builder (which is free and adding more features quarterly).

    Two structural angles worth pressure-testing:

    What approval category specifically? Purchase approvals ($X+ spend), contract approvals (legal review), content approvals (marketing/publishing), expense approvals (finance), time-off approvals (HR). Each has different stakeholders, different urgency, different audit requirements. "All approvals" is generic and competes with everything. One specific approval type with vertical depth beats horizontal play.

    What buyer pain isn't currently solved? Slack Workflow Builder handles basic approval flows. The gap is usually: multi-stage approvals with conditional routing, audit trails that satisfy compliance (SOC 2, ISO 27001), integration with finance/contract systems, approval analytics (where do bottlenecks live), or escalation patterns. Without one of these as wedge, you're feature-competing with Slack itself.

    The "where do approvals stall" data is actually the more interesting product angle. Most companies don't know which approvals take longest, which approvers are bottlenecks, or which categories slip past SLAs. That's analytics no one builds well right now and Slack can't surface natively.

    Who's the buyer? Ops manager at 50-200 person company is the sweet spot. They feel the approval mess most acutely and have budget to fix it. Worth being explicit about ICP from day 1.

    1. 1

      One follow-up question — in your experience, does the ops manager have direct budget authority for a $50-150/mo tool, or does it typically need IT/finance sign-off at 50-200 person companies?

      Trying to figure out if I'm selling to the user or the buyer.

    2. 1

      Really appreciate this — this is the most useful pushback I've gotten so far. You're right that "all approvals" is too generic. I'm leaning toward starting with finance/expense approvals (clear $ threshold, clear audit need, SOC2-curious teams) as the wedge, then expanding. The "where approvals stall" analytics angle is also something I hadn't framed that sharply — going to think on that. Thanks for taking the time to write this out.

      1. 1

        At 50-200 person companies, $50-150/mo is usually under the procurement threshold (discretionary spend is often $1-5K/year), so the ops manager can put it on a corporate card without formal sign-off. You're selling to the user.

        But the wedge you picked changes that. Finance/expense approvals touch finance's territory specifically — so even if ops manager pays, finance becomes a stakeholder because it's their process you're systematizing. The audit trail you're building is for finance/compliance, not ops.

        So the honest answer: ops manager is the buyer (budget + initiating pain), finance is the approver/blocker (it's their workflow), and individual approvers are the users (they click the buttons). Three roles.

        Sell to the ops manager's pain ("approvals stall, you look disorganized, audit season is chaos"), but design the demo so finance nods along ("clean audit trail, SOC2-ready, no more screenshot hunting"). The deal dies if finance feels their process is being changed without them.

        Practical move: in early sales convos, ask "who owns expense approval policy today?" That person needs to be in the room or the ops manager can't actually close.

        1. 1

          Hire_Hivemind — this breakdown was incredibly useful. Would you want to try the beta? Free, 2 min install: teamautomation.app

  3. 1

    Interesting build.

    The thing I'd be careful with is that some workflow problems look like communication problems at first.

    Sometimes the more important decision sits somewhere else entirely.

    That's one of those things that can quietly shape everything that follows.

    1. 1

      Fair point — appreciate the nudge to zoom out. Will sit with that.

Trending on Indie Hackers
6 weeks solo, 2 rejections, finally live but nobody told me marketing would be this hard User Avatar 139 comments I spent more time setting up cold email than actually selling. Here is what fixed it. User Avatar 34 comments I just wanted to taste AI coding tools. A week passed. User Avatar 24 comments I built a PDF API because every team I know has a haunted corner of their codebase they never want to open User Avatar 17 comments Building LinkCover – Day 3: Payment is live. No more building, time to sell. User Avatar 16 comments I built an AI that ruthlessly roasts your competitors based on their 1-star reviews. User Avatar 11 comments