Most of my client work at SquadHub is integration between the tools a small business already uses: an ERP, a booking platform, an inbox and Monday.com as the place where the team works. Two of these systems show the pattern best.

1. ERP → Monday.com stock sync

Context. A company keeps products, stock, average cost and sale price in its ERP (OMIE). The commercial team works in a Monday.com board. They need current stock in the board, and they need a safe way to correct stock without opening the ERP.

Design.

• One source of truth. The ERP owns products, stock and prices. Monday is the visibility and approval layer. The direction of each field is written down, not implied.
• Scheduled batch, no public endpoint. GitHub Actions runs the ERP → Monday sync every hour. Nothing listens on the internet.
• Write-back only after a human approves. A stock adjustment typed in Monday goes to the ERP only after someone sets the approval column. That job runs twice a day, and the result and any error are written back to the same item, where the team will see it.
• Dry-run everywhere. Every command (sync, process-monday-actions, resolve-stock-duplicates) has a --dry-run. The duplicate resolver defaults to dry-run in CI, so a manual trigger cannot change data by accident.
• Audit before fixing. Duplicated and stale items are reported by one command and resolved by a different one.

I built it alone. The repository has 48 automated tests.

2. Booking confirmation → itinerary → documents

Context. A training company sends instructors to run programs for its clients and books their travel on a booking platform. For each trip, someone collected the confirmations, assembled an itinerary and e-mailed documents to the instructor and to every service provider.

Design. It is a serverless pipeline on Vercel that I built with one other developer.

1. A daily cron and a Monday webhook trigger the run. A Redis lock prevents two runs at the same time.
2. It reads only the final confirmation e-mails, the ones with the voucher PDF or ICS. The voucher key and the Gmail message ID together prevent importing the same booking twice.
3. The booking is linked to the instructor, the matching activities and a trip item in Monday. When the status is set to “Generate PDF”, required fields are validated and the itinerary PDF is attached to the item.
4. A person reviews the PDF and only then sets “Send documents”. “Waiting” never authorizes a send.
5. Each provider gets a separate e-mail with only their services. A lock per item and a durable record per recipient prevent duplicate sends.
6. An uncertain send never expires. The operator checks the mailbox and reconciles before anything is retried, and sends that are already confirmed are never repeated.

Every endpoint requires a bearer secret. Sending stays disabled until the client authorizes the sender mailbox.

The pattern

Both systems follow the same rules, and I use them on every integration:

• Say who owns each piece of data.
• Make every write idempotent, with a key you can explain.
• Put a human approval in front of anything that leaves the company: an ERP write or an e-mail.
• Offer a dry-run for every command.
• Show failures where the operations team already works, not only in a log.