1 pointby barefootsanders6 hours ago1 comment
  • jackfranklyn6 hours ago
    This resonates. Building in accounting automation and hit the exact same wall.

    Started with "configure your coding rules" - let users set up how transactions should be categorised. Made sense architecturally. Nobody used it. They'd stare at the config screen and give up.

    What actually worked: learn from their existing data. Pull their historical GL, reverse-engineer how they already code things, then just do it that way. No configuration, no "agent" concept. Upload bank statement, get coded transactions back.

    The insight that killed our complexity was realising bookkeepers don't think in rules. They think in outcomes. "This should be coded like the last time we saw a payment from Stripe" not "if merchant contains 'stripe' and amount > 100 then category = payment processing fees".

    Curious about your MCP orchestration layer - how do you handle cases where the described workflow is ambiguous? In accounting there's often multiple valid ways to code something.

    • barefootsanders3 hours ago
      "Outcomes not rules" is the whole game. On ambiguity: we don't try to solve it upfront. Get it 80% right, let them refine the rest in seconds. When something's wrong, they fix it in natural language, not by going back to eng to change logic or mess with config. The unlock is really iteration without a ticket.

      Would love to swap notes on the accounting side. Similar problems, different domain constraints.