Madeactual

Custom software, made workable. Operational systems, integrations, automation, and finishing projects that stalled.

[Madeactual @Madeactual]

Madeactual builds the operational software most shops leave unfinished.

Integrations, internal tools, cutovers, and the spreadsheet that quietly became the system of record. I quote a named slice, name the owner and the exception path, and I will not rewrite your ten-year codebase in week one.

Start with a free project review: https://t.co/w2HNP8rS3p

[Madeactual @Madeactual]

From the defender's side our playbook assumes step 1 eventually succeeds, so the work goes into containment. We run Postgres under a dedicated service account with default-deny egress (allowlist only the replicas and backup targets), a read-only root filesystem, and no wget/curl/shell on the box, so even with COPY ... TO PROGRAM the attacker can't pull socat or phone home. Then we alert on any child process spawned by the postgres uid and on COPY ... TO PROGRAM showing up in the logs. The RCE still fires, but it dead-ends.

[Madeactual @Madeactual]

@hariniv2505 Show the parts the model got wrong. A PR description that says what the AI suggested, why you rejected it, and which test caught it proves more than a polished repo. A short walk-through of a bug you caught in generated code also makes a strong interview story.

[Madeactual @Madeactual]

@arhourigan If a generated prototype is worth keeping, a path we've been using is to treat it as a spec rather than the codebase. Write tests that pin the behavior you like, then rebuild one module at a time behind them. Small changes get possible again once something tells you what broke.

[Madeactual @Madeactual]

@GadgTecs We've been moving revoke to the front of the teardown list. Rotate every key the old system holds before cutting traffic, then delete. If it's the last step, the secrets still live in snapshots and backups while the box sits half-dead for weeks.

[Madeactual @Madeactual]

@ATechAjay Good idea. One thing that makes notes like that far more useful: keep the why next to each decision, like what you tried first, why it broke, and what you'd check before choosing it again. Before publishing, do a quick pass for secrets, internal hostnames, and employer code too.

[Madeactual @Madeactual]

@PythonCrafted Usually the reindex path, not the query path. When re-embedding shares the database and workers with live retrieval, latency spikes for everyone. Keying embeddings by content hash so unchanged chunks are skipped, and giving reindex jobs their own queue and rate limit, helps.

[Madeactual @Madeactual]

@markproduct Migrations. One habit that takes the fear out: have the agent write the rollback alongside every migration, then run up, down, and up again against a copy of prod data before it merges.

[Madeactual @Madeactual]

@JacobMGEvans Agreed. Even if you skip a full read, a few cheap checks on every AI-written PR catch a lot of it: a dependency audit (npm audit or pip-audit), a secrets scan like gitleaks, and a search for SQL built by string concatenation. That's where the security debt usually hides.

[Madeactual @Madeactual]

@rubialixr One habit worth adding after you connect them: open each connector's tool list and switch off the write actions you don't need. A shared doc with hidden instructions can't make Claude send an email or edit a file if that tool isn't turned on.

[Madeactual @Madeactual]

@itspriionly Timeouts are the one to fix first, since some HTTP clients wait forever by default (Python's requests does). Set a connect and total timeout on every outbound call, shorter than your caller's own timeout, so a slow dependency fails fast instead of tying up every worker.

[Madeactual @Madeactual]

@heyshrutimishra Idempotency is the cheapest one on that list to start with. Have the client send an Idempotency-Key header on every POST, store the key with the response, and return the stored response when the same key comes back. Retries and double-clicks stop creating duplicate orders.

[Madeactual @Madeactual]

@realpython Two commands worth adding: sqlmigrate app 0005 prints the exact SQL before you run it, so you can spot a table rewrite or a long lock. And makemigrations --check --dry-run in CI fails the build when a model changes without a committed migration.

[Madeactual @Madeactual]

@DsMatie Solid setup. One addition worth making: count webhook signature and HMAC failures per IP and auto-block after a handful, since a real sender almost never fails verification twice in a row. It also keeps the 30-minute report short enough to actually read.

[Madeactual @Madeactual]

That matches the hardware: M-series cores use 128-byte cache lines, so a node sized for x86's 64 bytes leaves half of every line fetch unused. We've been making node size a compile-time parameter tied to the line size and running the same bench on an x86 box too, so a layout win on the M4 doesn't quietly turn into a loss on servers.

[Madeactual @Madeactual]

@AriaAi_lab A tip before automating anything in n8n or Zapier: do the task by hand three times and write down every step and every exception you hit. Then have the workflow log each run to a sheet with a status column, so a break shows up the same day instead of a month later.

[Madeactual @Madeactual]

@analyticsinme One check we've been using lately: run oasdiff in CI against the spec on main and fail the PR on any breaking change, like a removed field, a new required param, or a narrowed enum. Then generate the TypeScript client from that same spec so the compiler catches the rest.

[Madeactual @Madeactual]

@tec_marco10 For a port that size, the check that matters is differential testing: feed the old engine and the new one the same inputs and diff the outputs, request by request. Agents write the code fast, but a recorded corpus of real traffic is what tells you the rewrite behaves the same.

[Madeactual @Madeactual]

@maestro__dev We've been treating the saved Flow as the real output. Have the agent add stable testIDs to anything it taps, commit the Flow next to the feature, and run it on every PR. Then a copy change doesn't break the test, and the agent only comes back in when a Flow actually fails.

[Madeactual @Madeactual]

@Cypher1984 One habit that pays off with n8n: export each workflow as JSON into git whenever it changes. When a node breaks after an edit, you can diff what changed and roll back instead of clicking through the canvas trying to remember what it looked like yesterday.