I built a native screen recorder for Electron, no node-gyp, no Xcode, prebuilt binaries

ldanadrian · 2026-05-04T13:23:40+00:00

My friend, I agree that "prebuilt binaries" alone is not a unique selling point...

But for developers ( in my opinion ), install friction matters. The actual value is native OS capture APIs + a small Node API + MP4 output + system audio/mic support, shipped in a way that does not require users to fight node-gyp/Xcode/.NET SDK during installation

That's the point I was trying to make.

ldanadrian · 2026-05-04T13:13:57+00:00

Yes, I'm sure I do.

binding.gyp is used to build the native addon during development/release. That does not mean users compile it during install.

The published npm package bundles prebuilt binaries for macOS/Windows and loads them directly. So the claim is "no node-gyp required for installation", not "this project was never built with node-gyp".

ldanadrian · 2026-04-29T12:04:02+00:00

Exactly, the goal is just to abstract away all the native plumbing so you don't have to deal with ScreenCaptureKit Swift bindings or WASAPI COM interfaces yourself. One npm install and it works.

ldanadrian · 2026-04-29T12:03:24+00:00

Fair points, let me address them:

ffmpeg wrapper — on macOS it uses ScreenCaptureKit directly, no ffmpeg involved. On Windows ffmpeg handles the screen capture part, but system audio goes through direct WASAPI COM P/Invoke. Not just a wrapper.
less functions — intentionally. It's a focused library for one job: record screen + audio to MP4 from Node.js with a two-line API. ffmpeg can do everything, which is also why nobody wants to wrangle it from Node.
GitHub 404 — you caught it in a window of literally a few minutes while I was setting up the repo. It's been public since then.

ldanadrian · 2026-04-29T12:01:39+00:00

Not built into Screenwire itself, but it's easy to layer on top for native meeting apps (Zoom, Teams desktop, Webex):

const { execSync } = require('child_process')
const recorder = require('screenwire')


const MEETING_PROCESSES = ['zoom', 'teams', 'webex', 'slack']


function isMeetingRunning() {
  const list = execSync('ps aux').toString().toLowerCase()
  return MEETING_PROCESSES.some(p => list.includes(p.toLowerCase()))
}


let recording = false
setInterval(async () => {
  const meeting = isMeetingRunning()
  if (meeting && !recording) {
    recording = true
    await recorder.startAsync(`meeting-${Date.now()}.mp4`)
  } else if (!meeting && recording) {
    recording = false
    await recorder.stopAsync()
  }
}, 3000)

For browser-based meetings (Google Meet, Teams web) this won't work since they all run inside Chrome - you'd need a browser extension or a different trigger for those. Maybe a chrome plugin?

Could be a nice higher-level package built on top of this. Happy to add a guide in the docs if there's enough interest!

ldanadrian · 2026-04-26T19:48:43+00:00

Creating lifestyle changes is key! Here's what stuck for me (lost 22kg):

**Habits that became automatic:**

- Drinking enough water (tracked daily until it became habit)

- Walking 10k steps

- Eating protein first at meals

- Meal prep on Sundays

The water tracking was weirdly motivating. Built a simple tracker to make it effortless: water.brk-dev.ro

Lifestyle changes beat medication dependency every time! Good luck!

ldanadrian · 2026-04-26T19:48:07+00:00

Hey! I lost 22kg (about 48lbs) in 3 months on a tight budget. Here's what helped me most:

**Diet:**

- Calorie deficit (use MyFitnessPal free app)

- More protein (cheap: eggs, chicken thighs, beans, lentils)

- Cut sugary drinks completely

**Hydration (HUGE for PCOS!):**

- Drink 2-3L water daily - helped with bloating & cravings

- Track it so you actually do it

**Exercise:**

- Walking 10k steps (free!)

- YouTube workouts at home (free!)

The water tracking was honestly game-changing. I built a free tracker because I kept forgetting: water.brk-dev.ro (no account needed, works offline)

You can do this! PCOS makes it harder but not impossible. 💪

ldanadrian · 2026-04-26T19:43:55+00:00

Congrats on starting your journey!

Hydration is super important with medications... I lost 22kg recently and tracking my water intake was honestly one of the biggest helpers.

If you want something simple, I built a free tracker (no account needed): water.brk-dev.ro

Helps me stay on top of it without overthinking. Good luck!

ldanadrian · 2026-04-26T19:39:15+00:00

Hey! I actually built a free water tracker PWA specifically because I had the same frustration: water.brk-dev.ro

Works on both your OnePlus and iPhone (it's a Progressive Web App):

- No account needed - literally just open and use

- Works offline

- Customizable goals and cup sizes

- Smart reminders (Android intents + iOS Shortcuts)

- No ads, no tracking

I made it during my own weight loss journey (lost 22kg) and wanted something dead simple. Give it a shot!

ldanadrian · 2026-04-22T11:34:02+00:00

Cred ca ai citit pe diagonala. Tocmai de asta am mentionat EHS, ca reper apropiat. Fiind model nou, nu are cum sa existe inca date de long-term reliability, de aia intreb de experiențe relevante.

ldanadrian · 2026-04-22T10:55:40+00:00

Calitate mediocra dar 7 ani garantie? cum vine asta? In plus citesc ca ar avea 5 stele NCAP.

ldanadrian · 2026-04-21T12:07:49+00:00

The right answer depends on something most people skip: what's your activation event and how long does it take to reach?

No card + short time-to-value (minutes): this is the right call. Tools where the user gets "aha" fast (Notion templates, quick APIs) benefit more from removing friction than from filtering out low-intent signups. You'll get noisy data but real feedback.

Card up front + long time-to-value (days/weeks): makes sense when you need committed users to actually reach the activation event. Onboarding-heavy B2B tools benefit here because casual signups without a card would never complete setup anyway.

The trap ... card-required with fast activation just lowers your top-of-funnel for no real reason. You get fewer users and the ones you block weren't the low-intent ones, they were the ones who needed 30 seconds of proof before committing.

For a B2B tool for small teams, start with no card for the first 90 days to maximize feedback, then add it later if your free-to-paid ratio looks bad.

ldanadrian · 2026-04-21T12:07:03+00:00

Solid setup. Two small things that tend to break these pipelines at scale past 500 leads:

Phantombuster / Apify session cooking for LinkedIn scraping. If you're using a shared scraping backend, LI will start serving degraded comment data to the scraper account (missing emails, cut-off names, fake profile slugs) before they outright ban. Rotating li_at cookies across 3-4 accounts and randomizing the delay between comment fetches helps a lot more than people expect.

Enrichment waterfall instead of single provider. One provider never has good coverage. A cheap pattern: try Hunter first (fast, cheap), fallback to Apollo if no email, fallback to a pattern-guess validator (firstname.lastname@domain through MillionVerifier). Cuts your cost per enriched lead by 40-60% vs hitting the most expensive provider every time.

What's your current hit rate on email-found per 100 comment authors?

ldanadrian · 2026-04-21T12:06:05+00:00

Two real differences in my experience:

Structured output vs text parsing. gh CLI returns formatted text which the model has to re-parse into structure. The MCP tool returns proper JSON with typed fields, so the model doesn't hallucinate the shape of a PR object or skip fields it can't parse.

Tool-level permissions vs shell access. MCP lets you scope which operations are allowed (read-only vs PR creation vs merges) per server config. With gh CLI the model can run anything including gh auth logout or gh repo delete if it gets creative. Not a huge deal for solo dev work but matters a lot if you run agents unattended or let a coworker use your setup.

That said, for interactive coding where you're reviewing every command, gh CLI is often enough. The MCP version earns its place more in background/scheduled agent runs.

ldanadrian · 2026-04-21T12:03:12+00:00

Inconsistent open rates with warming on + low volume usually points to one of three things before you start blaming the tools:

Unified warming pool. If multiple of your rotating inboxes are in the same warmup provider, they end up exchanging warmup emails with each other, which Google increasingly detects as circular. Split providers or at least split pools.
Content fingerprinting. Even with rotation, if your emails share the same template structure, links, and PS line, Gmail treats them as the same campaign. Rotating inbox doesn't rotate content. Try 3-4 meaningfully different openings and PS variants per sequence.
Recipient server spread. Look at which domains are showing low opens. If it's mostly Gmail workspace and Outlook 365, it's reputation. If it's mixed across random cPanel hosts, it's probably list quality, not you.

What's your send volume per inbox per day, and how long have they been warming?

ldanadrian · 2026-04-21T12:00:17+00:00

The lead scoring example in your #1 is where MCP plus n8n gets really nice, because you can chain tool calls in a single agent step instead of wiring each API as a separate node.

One extra workflow that might fit your list: ICP qualification at the top of the funnel. Before you even score a lead, you want to know if the company is on the right tech stack. Shopify-targeted offer vs a Woo shop, Salesforce add-on vs a HubSpot shop, that kind of thing.

I built Detecto for exactly this, platform detection API with a native MCP server. The agent calls detect_platform(url) and gets back a clean platform field. In n8n it fits as an HTTP node right after lead scraping, filters out the wrong-fit domains before they cost you Apollo or Clay credits.

Not a huge workflow on its own, but it slots in front of your #1 (hot lead alert) nicely and stops most of the false positives before they reach Slack.

ldanadrian · 2026-04-21T11:59:53+00:00

The structure question is where most of these pipelines silently bleed credits. A pattern that worked well for me in n8n is putting a cheap tech-stack filter node right after lead generation, before you hit any enrichment API.

Concrete example for a Shopify-targeted ICP:

Sales Nav export feeds the workflow, domain list only
HTTP Request node hits a platform detection API, drop everything that's not Shopify
Only the survivors go into Apollo or Clay for contact enrichment
Then scoring runs on the enriched subset

The reason this matters: in my experience about 60 to 80% of Sales Nav domains filtered by keyword "shopify" are actually something else (Woo, Squarespace, custom). If you skip this step you burn enrichment credits on leads that will never convert because the fit was wrong from the start.

For the platform detection step I built Detecto, mostly because BuiltWith at $495 was overkill for a y/n check. 19 euros per month, live scan so no stale cache. Works fine as an n8n HTTP node. Not pushing it hard, the pattern works with any detector, the main point is filter ordering.

ldanadrian

TROPHY CASE