u/Daniel_Janifar

been thinking about this a lot lately after a few projects where we over-engineered early. the standard advice is always "design for 200 records" and yeah that's right for triggers and batch, jobs, salesforce processes up to 200 records per transaction and governor limits don't care about your intentions. but i keep seeing teams apply that same thinking to a simple record-page button or, a quick action that will realistically fire one record at a time in normal use. worth being honest about the caveat though: "one record at a time forever" is a bit of a trap. buttons and quick actions can still kick off downstream automation that runs in bulk, or get reused in a context you didn't plan for. so i'm not saying ignore bulk patterns entirely for those cases, more like, be deliberate about where you're actually spending the complexity budget. my rough take now is that the service layer should always accept collections. that part's non-negotiable, keeps your apex reusable and bulk-safe regardless of what's calling it. but the UI controller or the flow invoking it doesn't need to be architected like it's, processing a data load when it clearly isn't, just don't bake single-record assumptions into shared logic. the cases where over-bulkifying genuinely hurt delivery for me have been when it pushed us from flow into apex earlier, than needed, or when we added staging objects to handle collision scenarios for a use case with maybe 5 users. sometimes the architecture is solving a problem that doesn't exist yet and probably won't. curious if others have a rule of thumb for when they let a scalar UI action stay scalar vs when they, force the bulk pattern from day one, especially across apex vs flow vs lwc since the tradeoffs are pretty different in each.

Work at a real estate law firm, 250-ish people, and from what I've seen very few, of them have touched an LLM (though that's just my own observation from where I sit). The rest copy-paste agreements between software all day, every day, and genuinely get offended if you suggest there's a faster way.

I've tried building small automations to handle the repetitive document routing, spent a chunk of my salary on tools including a subscription I won't name just to learn this stuff (personal expense, no receipts being shared here), and landed on a stack that actually works: note-taking AI for meetings, an, outreach tool, and workflow automation that takes plain English descriptions and builds the flow (tried Latenode for part of this, which is a no-code/low-code automation platform with app integrations, it helped with the app-to-app plumbing in my use case, though your mileage may vary depending on which integrations you need).

The automations work. That part I figured out. What I haven't figured out is the human layer.

Coworkers' actual argument is that learning AI means automating themselves out of a job. And I get it, sort of, but in my opinion their current job is heavily repetitive work that, feels increasingly at risk regardless, though I'll admit that's my read on the situation, not some objective fact. Constraints: I have no authority here, can't mandate anything, and my manager told me to just do my job when I brought it up.

For people who've been in a similar spot, how do you frame the conversation so it lands differently? Specifically wondering if there's a framing that doesn't immediately trigger the job-loss fear response, because, everything I've tried reads as a threat to them even when I'm trying to help.

Most of my clients just call everything an "AI automation" and expect me to figure out the rest. After a while I started splitting what I build into three rough buckets: trigger-based stuff that just moves data around, workflows that involve, an LLM making a judgment call somewhere in the middle, and full agent loops where the system is deciding its own next step.

Constraints are pretty real here: small ops teams, no dedicated dev, budgets usually under $500/month, and they want things running in days not weeks.

I've tried building everything in n8n and Make, but the moment a workflow needs actual conditional reasoning from a model the visual layer gets messy fast. Ended up routing some of the agent-loop stuff through Latenode for a recent project, and it handled the multi-step judgment layer without me writing a ton of glue code.

What I actually want to know is how other consultants or builders are mentally framing these categories, and whether the trigger vs. judgment vs. agent split even holds up once you're running 10+ workflows for the same client or if it just collapses into chaos.

I keep getting different answers on what's safe for LinkedIn outreach automation. Some people swear by tools sending 50+ connection requests/day with zero issues. Others say they got flagged at 20/day. The information is inconsistent everywhere I look.

Specific things I want to understand:

What's the actual connection request volume threshold where you start getting flags? Is it per account, per IP, or something else?

Does LinkedIn differentiate between API-based automation and browser-based automation in terms of enforcement? The conventional wisdom says browser-based is riskier but I've never seen real data on this.

If you've been restricted — what happened exactly? Was it temporary, permanent, somewhere in between? And what did you change afterward?

We've been thinking about building our own outreach orchestration (Latenode for scheduling and rate limiting, connecting to LinkedIn through compliant API tooling). Curious if anyone has gone that route vs. using a dedicated tool.

been thinking about this a lot lately because I keep seeing agencies over-automate and then wonder why clients feel like they're talking to a wall. the way I've landed on it: automate the repetitive, low-stakes stuff, intake acknowledgements, status updates, FAQ responses, proactive delivery notifications. that's fair game, and honestly a lot of clients in 2026 expect near-instant replies for that kind of thing. the bar for "fast enough" has only gone up. but the moment something needs actual judgment, a scope question, a complaint, anything where the relationship is a bit fragile, a generic automated reply can do real damage. had a client once who got an auto-response during what was basically a crisis on their end and they were not happy about it. no amount of "we've received your message and will respond shortly" fixes that. the hybrid model is pretty much the standard now, at least among the agencies I work with. automate the first touch so nothing falls through the cracks, use that layer for routing and, triage, then a real person picks it up if it needs more than a templated answer. the AI handles the volume, the human handles the judgment call. what I'd push back on is the idea that "fully automated" means hands-off, most setups that actually work, still have someone owning the escalation path and doing regular QA on what the automation is sending out. the tricky part is defining what counts as "complex enough" to escalate, and that threshold is genuinely different for every agency and every client relationship. curious how others are handling this, especially on smaller teams where you can't always have someone watching the inbox in real time.

been working with a few clients lately who are trying to make this shift and the pattern I keep seeing isn't really about the tools. it's the maintenance side that hits hardest. you spend weeks getting a test suite running, then the UI changes and suddenly half your locators are broken. one client described it as spending more time fixing tests than actually catching bugs, which kind of defeats the point. and honestly with AI-driven test generation picking up a lot of steam right now, that problem isn't going away, if anything it's getting more interesting because you're also dealing with flaky AI outputs on top of the usual brittleness. the other thing that comes up a lot is figuring out what's even worth automating in the first place. not everything that can be automated should be, and manual testers who are new to this often try to automate too much too fast. the teams I've seen handle it best usually started with a small, stable suite like, core regression flows and built from there rather than trying to replace everything at once. jumping straight into full coverage before your pipeline is solid is a recipe for a bloated suite nobody wants to touch. curious if others have hit the same wall or found a way through it that actually stuck, especially if you've, been experimenting with any of the newer codeless or AI-assisted tools and whether that changed the maintenance story at all.

My team works with a mix of technical and non-technical folks across maybe 8-10 SMB clients right now. We need workflows that ops people can read and edit visually, but that still let us drop into code when the no-code blocks hit their limits.

Constraints: tight budgets (most clients won't go past $50-100/month on tooling), small teams with maybe one part-time dev, at best, and we can't have something that requires a full re-build every time a client's stack changes.

We've tested Make and Zapier pretty extensively. Make gets painful when you need real conditional logic or custom transformations, and Zapier's code steps feel bolted on rather than native. Tried Latenode for one client where we needed JS escape hatches alongside the visual builder, and that part worked pretty well, but I'm not sure how it holds up at scale.

For us the decision comes down to: how clean is the handoff between visual nodes and code blocks, what happens when, a non-technical person needs to edit a workflow a dev originally built, and how readable are error traces when something breaks mid-run.

For folks running hybrid teams like this, what's actually held up over 6+ months without turning into a maintenance nightmare only the original builder can touch.

One of our lead designers quit Monday with zero warning.

I walked into an admin meeting Tuesday where they were already planning to replace her and automate our entire creative workflow using Claude's integration, tools, things like connectors for SketchUp, Adobe, Blender, and similar apps that can handle workflow automation, batch-processing, format translation, and bridging tools in creative pipelines. The stated goal was to cut down on revisions by uploading project assets and context so the CEO, and random admins could just prompt drafts and pass them down to me and my team for "refinement."

I've worked with automation a lot, helped clients build stuff in Latenode and n8n, and I actually like AI in workflows. But this isn't that. This is using AI as a cost-cutting excuse dressed up in efficiency language.

The part that gets me is nobody asked the design team anything. The people who actually know what the work requires weren't in that room. And "refinement" is doing a lot of heavy lifting in that plan, what they're describing is still just design work, just with worse starting points.

I'm probably going to quit too.

been thinking about this a lot lately because a few clients have come to me after bad hires, and the pattern is pretty consistent. the biggest one is someone who talks about "building RAG pipelines" like it's impressive but, can't explain how they handled query-doc mismatch, ingestion hierarchy, or what their eval setup looked like. chunk and embed is basically junior-level work at this point. if they can't walk you through how they measured whether retrieval was actually working, offline evals, online metrics, CI/CD integration, whatever, that's a problem. and with how much RAG experience has been inflated on resumes lately, I'd push hard on the specifics. hybrid search, reranking, query rewriting, if those haven't come up in their work, dig in. the other thing I watch for is zero production history. research experience is fine but it doesn't automatically translate. if they can't speak to deployment, monitoring, drift handling, or what happened when the model started failing in production, that's a real gap. same goes for infra. if cloud scaling or managing costs at scale has never come up in their, work, you're probably not getting someone who can own the full thing end to end. the one that doesn't get talked about enough is whether they can connect their work to actual business outcomes. not just "I improved retrieval accuracy", okay, what did that mean for the product, the cost structure, the customer? senior engineers should be thinking about cost tradeoffs, security, compliance, governance. not treating that stuff as someone else's problem. with comp for senior AI talent running well into the $400K+ range right now, a bad hire is genuinely expensive. worth slowing down the process. what red flags have you actually seen come up when interviewing for these roles?

been thinking about this a lot lately because I keep running into the same problem with clients. they want AI in their workflows but they already have templates and processes that work okay, so the question is always where do you actually plug it in without breaking what's already running. the pattern I've seen work best is starting with one repetitive handoff point, like, document generation or routing tasks between teams, and automating just that before touching anything else. the no-code tools are genuinely good enough now for most of this. Zapier and n8n handle the bulk of what SMB clients need, and if you're already on something like monday.com or, Power Automate there are AI blocks built in that connect to your existing Slack or CRM without a full rebuild. natural language workflow generation has also gotten good enough that business users can set up, integrations themselves without needing a dev involved, which changes the conversation a lot with mid-market clients. the trap I see people fall into is trying to orchestrate everything at once across their whole stack. you end up with a fragile mess that nobody trusts. starting with one template, validating it, then expanding has worked way better in my experience. worth noting that even now only about half of organizations have actually unified their workflows end to, end, so visibility and governance gaps are still super common and that's usually where things quietly break. the governance question is the one I don't think people talk about enough though. full autonomy sounds great until an AI agent makes a bad routing decision and a client deliverable goes sideways. keeping a human checkpoint on anything client-facing has saved me more than a few times. if you're in the EU there's also the GDPR angle to think through before you just plug a new AI tool into a workflow that touches customer data. curious whether others are running their AI automations with full autonomy or still keeping a review step in there for anything external.

Hoping the sub can help here because every search result on this topic is a vendor pitch.

Setup: small business, Odoo handles operations (inventory, sales, fulfillment), QuickBooks is what our accountant uses for the books. We've been doing monthly journal entry transfers manually and it's a known weakness.

We've looked at:

- Building it via the Odoo and QuickBooks APIs directly

- Various third-party connectors (mixed reviews)

- A workflow platform sitting between them

- Just keeping the manual process and accepting it

Specific things I want to handle automatically:

- Sales orders → invoices in QuickBooks

- Vendor bills → bills in QuickBooks

- Payments synced both directions

- Tax handling that doesn't make our accountant cry

- Multi-currency without rounding drift

Specific things that scare me:

- An automation creating duplicate entries that take hours to clean up

- Account mapping mistakes that compound over months before being caught

- The accountant losing trust in the books

For people who've actually solved this — what setup did you land on, and how long did it take before you trusted it enough to stop manually checking everything?

Slightly off-piste for this sub but bear with me.

I work in a small consulting practice (5 people). We don't have a real CRM. We have:

- Notion for client docs, project notes, meeting summaries

- Todoist for task management

- Email/calendar for actual communication

For a long time this worked. Now we're at the point where we need *some* CRM-like behavior — knowing what's open with each client, what tasks belong to which engagement, what the last touchpoint was — but installing HubSpot or Pipedrive feels like overkill for our scale and would create a third place to update.

What I'm thinking:

- Notion stays the source of truth (one page per client, sub-pages per engagement)

- Todoist gets tasks tagged by client (already does this)

- Some automation pulls Todoist task completions into the right Notion client page as activity

- Calendar events similarly logged into Notion

Has anyone else built a "lightweight CRM" out of tools they already use? Curious what worked, what didn't, and whether you eventually gave up and moved to a real CRM.

[ Removed by Reddit on account of violating the content policy. ]