The honest answer
A two-step automation engine is buildable for integrations you control. A broad IFTTT replacement depends on maintaining many external connectors, OAuth flows, polling/webhooks, quotas, retries, secrets, and support for constantly changing APIs.
The hard parts
What actually makes this difficult
- Connector maintenance
- Secret security
- At-least-once event semantics
What you lose
The parts that make the paid product hard to replace
- Hundreds of services
- Complex visual workflow builder
- Enterprise automation governance
People still pay for IFTTT because connector catalogue; long-term maintenance; consumer-friendly setup.
Prior art
Start from an open source route
Useful projects to run, learn from, fork, or use as a faster starting point. They are not endorsements or drop in equivalents.
What your first version needs
Useful capabilities, not a clone checklist
ConnectionsAuthorise external services safely.
- OAuth
- Secret storage
- Connection health
- Revocation
RecipesDescribe trigger-to-action logic.
- Trigger selection
- Action selection
- Field mapping
- Enable/disable
ExecutionRun automations reliably.
- Webhook intake
- Polling
- Retries
- Run history
Before you start
IFTTT build questions
Can I vibe code IFTTT?
You can build an automation tool around a small integration set. The sustainable product decision is which connectors you are willing to maintain.
How should retries work?
Use idempotency keys, bounded exponential backoff, dead-letter states, and a visible run log. Never retry unknown side effects blindly.
Where should OAuth tokens live?
Encrypt tokens at rest, limit access to workers that need them, rotate encryption responsibly, and support explicit revocation.
Sources
Reviewed 2026-08-10. This is a scoped independent build, not a claim about the proprietary implementation behind IFTTT.
