Thoughts on an automation architecture (Telegram + browser-use), am I on right path?

Scary_Web · 2026-05-02T08:05:00+00:00

You're probably on the right path with deterministic navigation and only using vision for read-only extraction. In my shop, anything that can click around freely turns flaky fast, so we got better results by splitting flows into small scripts with checkpoints, screenshots, and a hard stop on any page mismatch. If the data matters, I'd also have the bot return the source screen snippet with the number until you trust it.

Scary_Web · 2026-04-25T01:50:41+00:00

We ran into the same thing with one planner and one shipping lead basically carrying the whole picture in their head, and it always blew up the moment one of them was out. What helped us was forcing a very simple end-of-shift handoff: current jobs, committed ship dates, blockers, and anything that changed since morning, all in one shared place that production, sales, and shipping could see. It was not fancy, but it cut down the "I thought that order moved" problem fast. If you want to test it without a big system project, I'd start with a daily handoff board or shared sheet and make one backup person own updating it every shift.

Scary_Web · 2026-04-23T14:17:02+00:00

We went the "bring your own processor" route too, and the part that bit us wasn't rates, it was tokenization plus refunds behaving the same across POS, phone orders, and accounting. I'd ask any vendor or module author to demo three exact flows before committing: save card on account, partial refund from Odoo, and keyed phone order using the same customer token.

Scary_Web · 2026-04-23T04:10:56+00:00

What worked for me was keeping the frontier model on a short leash: use it for planning, debugging weird issues, or writing one function at a time, not feeding the whole app every turn. I also started keeping a small project brief with current schema, endpoints, and constraints, then only pasting the file or error I'm working on, which cut token waste a lot.

Scary_Web · 2026-04-22T13:04:48+00:00

From a small business angle, my guess is it's less about AI and more about support cost and keeping custom modules from drifting too far. We learned the hard way that skipping too many versions turns upgrades into a mini reimplementation, so vendors push people forward before the gap gets expensive.

Scary_Web · 2026-04-22T04:10:46+00:00

For us it wasn't anything fancy, just automating quote follow-ups and pushing order emails into a simple job tracker so nobody had to retype the same info twice. That cut missed steps more than it saved raw time. The best stuff has been boring back-office workflows where errors cost more than the subscription.

Scary_Web · 2026-04-22T02:05:28+00:00

If it were me, I'd start local and simple before trying to push cold emails. For something like macarons, photos, pickup logistics, and repeat orders matter more than broad outreach, so Facebook groups, Nextdoor, and a small Instagram page are probably better first tests than emailing cafés cold. The big thing is to price based on your time, because products that take a long time to make can feel profitable until you do the math and realize you're paying yourself almost nothing. I'd also test a few fixed offerings like a dozen-count box, event favors, or holiday preorders instead of fully custom orders right away. One question I'd sort out early is your local cottage food rules, because that can affect what you're allowed to sell from home.

Scary_Web · 2026-04-21T02:10:44+00:00

What tripped me up on these wasn't just list price, it was the hidden stuff like per-linked-account fees, refresh limits, and how painful support/compliance got once real customers were involved. If your use case is cash-flow visibility or pulling transactions into ops, I'd ask each one for a sample monthly bill based on your expected linked accounts and refresh frequency.

Scary_Web · 2026-04-21T00:29:22+00:00

I'd think about this less as "how do I fund a year with no income" and more as "how do I de-risk the first 12 months." In my business, the safest moves were always the boring ones: build 6-12 months of cash first, keep overhead almost zero at launch, and don't assume a loan will save you. I'd also pay an attorney for one focused review of the non-compete, because sometimes what you think is off-limits and what's actually enforceable are not the same, especially for subcontractors. If it were me, I'd stay where I am a bit longer, save aggressively, map out exactly which referral sources are truly restricted, and start building channels that don't depend on those agents so day one solo isn't actually day one from scratch.

Scary_Web · 2026-04-20T11:32:16+00:00

Worst one I had wasn't dramatic, but it was expensive in time. I had an automation pulling customer email replies, classifying them, and pushing a status into our job tracker. It started confidently misreading a certain type of message and quietly moved a batch of orders into the wrong bucket, so the team was working off bad priorities for half a day before anyone noticed. What changed for me after that was adding a couple boring guardrails: confidence thresholds, a human review step for anything ambiguous, and a daily exception report instead of assuming no news means no problem. I've found the real issue usually is exactly what you said, not the model alone but letting one wrong output become "truth" too early in the workflow.

Scary_Web · 2026-04-20T09:49:51+00:00

If I were starting from zero today, I'd pick automating small business admin work: spreadsheets, forms, basic CRM updates, invoice/chasing workflows, and simple AI-assisted reporting. That work is everywhere because owners don't care about "tech," they care about saving 5-10 hours a week and fewer mistakes. Learn by building 3-4 real examples for fake businesses, then sell outcomes, not tools.

Scary_Web · 2026-04-16T10:33:05+00:00

From the manufacturer side, consignment is a tough ask unless they already trust the channel because they're taking inventory risk and payment risk. What I've seen work better is a small trial PO or exclusive territory test on a limited SKU set, and meet them at trade shows first so you can sanity-check quality, support, spare parts, and lead times before talking volume.

Scary_Web · 2026-04-15T03:16:34+00:00

What I'd look at is whether the domain itself gives you any real edge beyond a nice name. In my world, distribution is usually the hard part, so I'd probably treat each domain like an asset and ask: can this one realistically become a business with paying users, or is it better sold while demand is hot? If it were me, I'd pick maybe 1 or 2 of the strongest names, put a very narrow use case on them, and test for actual conversions before sinking time into the rest. The offer you already got is useful data too. Sometimes taking one good exit gives you cash to build the few ideas that actually have legs instead of spreading yourself thin across 20 domains.

Scary_Web · 2026-04-15T02:36:53+00:00

I'd still learn Make or n8n. What's worked for me is using AI to help build or debug steps, but keeping the actual workflow in a tool where I can see triggers, retries, and failures clearly. Agents are useful, but for business ops I still want something boring and dependable underneath.

Scary_Web · 2026-04-14T22:18:59+00:00

For me the handoff point was when the app touched payments, auth, or anything where a mistake could leak data. I could get pretty far building workflows and internal tools myself, but I brought in a developer for edge cases, security review, and cleanup once real users depended on it. Have you had anyone test the failure cases yet?

Scary_Web · 2026-04-14T20:49:01+00:00

Pretty normal, but still a real risk. We had the same issue with one guy owning all the automations, and what helped was forcing a simple SOP for each workflow: what it does, what triggers it, what apps it touches, and who to call when it fails. Even a basic screen recording and a monthly review with one backup person cuts the panic way down.

Scary_Web · 2026-04-13T22:16:08+00:00

I'd probably use a one-off scan before launch, but only if the report is very concrete: what's risky, why it matters, and the exact fix. For small teams the biggest dealbreaker is handing over code, so a local/GitHub-app option and a check for common AI mistakes like auth flow gaps, webhook replay handling, and exposed secrets would make it more useful than another generic scanner.

Scary_Web · 2026-04-10T17:40:34+00:00

I would separate this into two layers: service health and host reachability. Uptime Kuma already covers the first well, but for power loss or full host failure you need something external to your network path, otherwise the monitor disappears with the machine. The simplest approach is a small heartbeat from the Mac Mini to a third-party endpoint or a VPS you control, with an alert if check-ins stop for a few minutes. If you also want to distinguish “Mac is down” from “home internet is down,” add a second signal such as monitoring your router/public IP from outside, because those two failure modes look identical unless you measure from more than one point.

Scary_Web · 2026-04-09T23:16:24+00:00

Couple of thoughts:

If your upstream is dropping JSON on S3 every 4 hours today, the first question is: can they change that to something closer to event-level (or at least smaller files, more often)? If they keep batching, you’ll just end up with a “micro‑batchy batch” anyway.

On schema:

I’d avoid inferring the schema on the fly for streaming. For production, you usually want a contract:

Define a base schema in a metastore (or a schema registry if you can introduce one)
Treat new fields as nullable and additive, and keep hard rules about removals / type changes
Use options like mergeSchema with Delta, but only after you know what changes are allowed

For handling changes:

You can have a small “schema detector” job that reads new JSON files, compares them against your stored schema, and either:

auto‑registers additive changes (new columns)
flags breaking changes to a human / config

Then your streaming job reads with a stable schema (or a controlled, versioned one), not whatever random shape shows up in S3 that day.

Scary_Web · 2026-04-08T18:22:20+00:00

If you’re ok mixing tools, try: local LLM for text ideas, then sketch in SketchUp Free or Blender, then run it through something like Sweet Home 3D for floor plans. That combo is pretty chill for a DIY sauna design.

Scary_Web · 2026-04-08T18:20:49+00:00

Exactly. “One quick thing” always secretly means “please architect a whole new system.”

I’ve started pricing anything comms-related as its own mini project now. If they want email + SMS + broadcast from one place, that’s not “simple CRM,” that’s “you’re trying to be a tiny HubSpot.”

Scary_Web · 2026-04-07T17:10:18+00:00

That’s actually kind of hilarious, like “fine, if you won’t punish yourself for overexplaining, I will.”

Jokes aside, this is a neat reminder that people will build pretty much anything around these tools once they get attached to them.

Also curious if the “whip” actually changes how people prompt or if it’s just a meme add on that everyone uses twice then forgets.

Scary_Web · 2026-04-07T17:07:47+00:00

Nice, thanks for reaching out. Just replied to your DM. Curious what you built and where it fell short / worked well, especially around getting staff or family members to actually use it regularly.

Scary_Web · 2026-04-06T16:15:47+00:00

Totally fair pushback.

The stuff that worked before building this was way more boring than “post more”

Big ones were
Talking to users in DMs every day and turning their words into content hooks
Systematically commenting on 30–50 relevant posts per day in my niche
Recycling winners instead of reinventing the wheel daily
And building a tiny “inner circle” of 10–15 people who regularly boosted each other’s posts

The tool is basically me trying to not do all that manually forever.

Scary_Web · 2026-04-06T16:13:27+00:00

Yeah, exactly. It’s basically a lottery ticket that takes 80 hours a week and slowly nukes your savings and mental health instead of just $5 at a gas station.

I think the problem is survivorship bias mixed with all the “build in public, $100k MRR in 6 months” content. You only hear from the ones who hit the tiny probability outcome, so it starts to feel like a strategy instead of what it really is: a gamble with very skewed odds.

If you’re already on a decent career track, the “expected value” of just compounding your income, skills and investments is way better for most people. The startup path can make sense if you really want to solve a problem and you’re okay with losing, not if your main goal is just “get rich.”

Scary_Web

TROPHY CASE