.png)
For two years we built client systems on n8n, Zapier, and Make. Visual workflows, pre-built connectors, fast deployment. It worked until it didn't.Now we build directly with APIs - writing orchestration logic in code we control instead of dragging boxes in a visual editor.This isn't developer purism. It's a pragmatic decision based on hitting the ceiling of automation platforms in production.Here's why we made the switch, what it actually means in practice, and when platforms still make sense.
Why we started with automation platforms
The appeal was obvious. We could build working systems in days instead of weeks. Pre-built connectors to every major platform - Google Calendar, HubSpot, Slack, Stripe, hundreds more. Visual workflows that non-technical clients could understand. Error handling and retries built in. No infrastructure to manage.For early client projects, platforms were perfect. Connect a form to a CRM. Trigger emails based on database changes. Sync data between systems. Classic integration work that platforms handle well.The turning point came with AI projects. Building RAG systems, agentic workflows, and custom AI applications on automation platforms exposed fundamental limitations we couldn't work around.
Where automation platforms hit their ceiling
Opaque debugging and error handling
When a workflow fails, platforms give you a generic error message and maybe a snapshot of the failed node. Good luck figuring out why the third-party API returned a 429 error on exactly this record but not others.Example problem: Client's HubSpot sync would randomly fail on specific contacts. The platform error: "API request failed." No request body logged. No response headers. No way to inspect what was actually sent.With direct API calls: We log request and response bodies, headers, timing. When something fails we see exactly what went wrong. We can reproduce it locally and fix the root cause.Platform limitation: You're debugging through the platform's abstraction layer. You can't see the actual HTTP requests being made.
Third-party data handling we can't control
Automation platforms process your data on their infrastructure. For some clients - especially in legal, finance, and healthcare - this is a compliance problem.Example problem: Law firm client couldn't use cloud automation platforms because client data legally cannot leave Australian servers. Their workflow required routing through the platform's US or EU infrastructure.With direct API calls: Data flows directly from source to destination. We control the infrastructure. Australian data stays on Australian servers. Client owns the entire pipeline.Platform limitation: Your data transits through vendor infrastructure in unknown jurisdictions.
AI capabilities bolted on as an afterthought
Platforms added AI nodes in 2023-2024, but they feel retrofitted. Limited context window management. No streaming responses. Awkward prompt construction. Difficult to implement multi-step agent reasoning.Example problem: Building a RAG system requires: chunking documents (custom logic), generating embeddings (batch API calls), storing vectors (database-specific format), querying by similarity (complex SQL), constructing prompts (dynamic based on results), streaming responses (real-time to user).Automation platforms handle maybe 60% of this. The rest requires code nodes with awkward workarounds.With direct API calls: We control the entire flow. Custom chunking algorithms. Efficient batch embedding generation. Optimized vector queries. Complex prompt assembly. Streaming to client with progress indicators.Platform limitation: AI workflows need custom logic at every step. Platforms constrain you to their node library.
Pricing that scales badly
Platforms charge per execution or per operation. For high-volume AI workflows this gets expensive fast.Example cost comparison:n8n Cloud: $20/month plus overages for high execution countsSelf-hosted n8n: $50/month infrastructure but requires maintenanceZapier: $140/month minimum for 50K tasks, costs spike with AI-heavy workflowsMake: Better pricing but still per-operation modelOur API-first approach: $50/month infrastructure (Railway/Render), pays for unlimited executions. OpenAI API costs are the same regardless of orchestration method.Platform limitation: You pay for orchestration infrastructure you could host yourself for less.
Vendor lock-in and platform risk
Platforms change pricing, deprecate features, impose new limits. Your workflows are locked into their ecosystem.Example problem: Zapier changed their AI pricing model mid-year. Client workflows that cost $200/month suddenly cost $600/month. No migration path without rebuilding everything.With direct API calls: We control the infrastructure and code. If Railway raises prices, we move to Render. If OpenAI raises prices, we can switch to Anthropic. Our orchestration logic is portable.Platform limitation: Your business logic is trapped in proprietary workflow formats.
What API-first actually means
We're not writing everything from scratch. API-first means using services via their native SDKs and APIs, with orchestration logic in code we control.
The technical stack
Runtime: Node.js or Python depending on project requirementsOrchestration: Custom code using async/await patterns, not visual workflowsAPIs: Direct SDK usage (OpenAI SDK, Anthropic SDK, Google APIs client libraries)Database: Direct PostgreSQL or MongoDB connections, not abstracted through platform nodesHosting: Railway, Render, or Vercel for compute. Supabase for database.Scheduling: Cron jobs or event-driven triggers via webhooksMonitoring: Custom logging to database, alerts via Sentry or similar
Example: Document processing workflow
Platform approach (n8n):Schedule trigger node. Google Drive list files node. For each file loop. HTTP request to OpenAI embeddings. Parse response code node. Supabase insert node. Error handling nodes between each step.Total: 8-12 nodes per workflow. Debugging requires clicking through each node's execution log.API-first approach:Single scheduled function. Loops through Google Drive files using Drive SDK. Batches embedding requests to OpenAI SDK. Inserts to Supabase using Postgres client. Comprehensive error logging throughout.Total: One codebase, 150 lines, fully testable locally.
The development workflow
Platform approach: Build in web UI, test by running workflows, debug by inspecting node logs, deploy by saving workflow.API-first approach: Write code in IDE with AI assistance (Cursor/Copilot), test locally with actual API credentials, debug with standard tools (logs, breakpoints), deploy via git push to hosting platform.The second approach is familiar to developers. No learning curve for workflow-specific concepts.
The honest trade-offs
API-first isn't universally better. There are costs.
More upfront development time
Writing code takes longer than connecting visual nodes initially. A simple CRM-to-spreadsheet sync that takes 20 minutes in Zapier might take 2-3 hours in code.When this matters: Simple integrations where time to market beats long-term maintainability. Prototypes that might not go to production. One-off data migrations.When it doesn't matter: Production systems that will run for years. Complex workflows that need custom logic. High-volume processing where platform costs add up.
Requires actual programming knowledge
Platforms democratize automation. Non-developers can build useful workflows. API-first requires coding ability.Implication for clients: If your team can't code, platforms might be your only option. If you have technical staff or work with technical agencies, API-first is viable.
You own the infrastructure management
Platforms handle deployment, scaling, monitoring, security updates. API-first means you (or your agency) manage this.What this looks like: Deploying to Railway or Render handles most infrastructure automatically. You're not configuring servers. But you're responsible for monitoring, handling errors, keeping dependencies updated.Trade-off: More control and ownership versus more responsibility.
When platforms still make sense
We haven't abandoned platforms entirely. They're the right tool in specific situations.
Use platforms when:
You need to ship fast for validation. If you're testing an idea and might throw it away, platforms are faster.Your team can't code. Non-technical operations teams can maintain Zapier workflows. They can't maintain Node.js codebases.The workflow is genuinely simple. "When Stripe payment succeeds, create invoice in Xero" - platforms handle this perfectly. Don't overcomplicate.Volume is low. If you process 100 items per month, platform costs are negligible and not worth optimizing.Integration coverage matters more than control. Platforms maintain connectors to hundreds of services. Building each API integration yourself takes time.
We still recommend platforms for:
Internal operational workflows at small companies. Marketing automation for non-technical teams. Quick prototypes and proofs of concept. Businesses with simple integration needs and low volume.
What this means for production AI systems
The platform limitations show up most acutely in AI applications.
Why AI workflows need API-first:
Custom chunking logic: Every RAG system needs document chunking. Platforms offer basic text splitting. Production systems need semantic chunking, sentence boundary detection, overlap management, metadata preservation. This requires code.Efficient embedding generation: Batch 100 text chunks into one API call versus 100 sequential calls. Platforms don't optimize this well. Code does.Vector database operations: pgvector queries need custom similarity thresholds, metadata filtering, result ranking. Platforms abstract this away poorly.Streaming responses: Users expect real-time streaming from GPT-4. Platforms buffer responses or don't support streaming at all.Complex agent logic: Multi-step reasoning, tool use, context management - these need custom orchestration that visual workflows can't express elegantly.Cost optimization: Caching embeddings, reusing context, batching operations - all require custom logic.
The business case for API-first
For agencies and development teams, the decision comes down to economics and long-term viability.
Cost comparison at scale
Client scenario: 5,000 document chunks processed daily for RAG system.Platform cost (Make): 150K operations/month at $1 per 10K ops after free tier equals $15/month for orchestration alone plus OpenAI API costs.API-first cost: $50/month hosting (handles unlimited orchestration) plus the same OpenAI API costs.Savings: $15/month isn't significant until you have 10 clients. Then it's $150/month saved. At 50 clients it's $750/month.
Technical debt and maintenance
Platform approach: Locked into vendor roadmap. Breaking changes force workflow rebuilds. Can't refactor easily. Knowledge is platform-specific.API-first approach: Standard code that any developer can maintain. Portable across hosting providers. Refactorable. Industry-standard debugging and testing.Over multi-year timelines, API-first reduces technical debt significantly.
Client ownership and portability
Clients asking "what if we want to move this in-house?" is common.Platform answer: "You'll need to learn our workflow format, get your own platform account, export and reimport workflows, manage credentials."API-first answer: "Here's the GitHub repo. Here's how to deploy it. Your developers can take over anytime."The second answer builds trust and reduces lock-in concerns.
How we made the transition
We didn't flip a switch. The migration happened over 6 months.
Phase 1: Hybrid approach
New AI projects built API-first. Simple integrations stayed on platforms. Rebuilt high-value platform workflows in code when they needed iteration.
Phase 2: Standardized stack
Established Node.js as primary runtime. Built reusable patterns (API retry logic, error handling, logging, scheduling). Created templates for common workflows.
Phase 3: Full migration
Platform-only projects were edge cases. Default approach became API-first. Platforms for prototyping only.
What we learned:
The first few API-first projects took 2x longer than platform equivalents. By project 5, we were faster than platform development. Code reusability compounds. Patterns you develop transfer across projects. Platforms require rebuilding similar workflows repeatedly.
What this means if you're hiring an agency
When evaluating agencies for automation or AI work, ask about their approach.
Red flag answers:
"We build everything on [platform]." Means they're constrained by platform limitations."Platforms are always faster and cheaper." Shows they haven't built at scale or dealt with complex requirements.
Good answers:
"We use platforms for simple integrations and API-first for complex systems." Shows pragmatism and understanding of trade-offs."We can build either way - here's how we decide." Indicates they've thought through the options and choose based on requirements."We build API-first for AI and production systems." Suggests they've hit platform limitations and evolved past them.
Questions to ask:
"What happens if we want to migrate away from your solution?""How do you handle debugging when workflows fail in production?""What's your approach to data residency and compliance?""How do costs scale as volume increases?"Agencies building API-first will have better answers to all of these.
The future of automation
The industry is moving toward code-first approaches even as platforms improve.Evidence: GitHub Copilot, Cursor, and other AI coding assistants make writing orchestration code faster than ever. The gap between platform speed and code speed is shrinking. New platforms like Inngest and Temporal are code-first automation frameworks, not visual builders. Infrastructure platforms (Railway, Vercel, Render) make deployment trivial.Prediction: In 2-3 years, visual automation platforms become prototyping tools. Production systems run on code with AI-assisted development. The complexity ceiling of platforms becomes more obvious as AI workflows become standard.
Our recommendation
If you're a business: Use platforms for simple internal automation. Hire developers or agencies for complex systems and AI applications. Ask about long-term ownership and portability upfront.If you're a developer: Learn platforms for speed, but don't rely on them exclusively. Build API-first for production systems. Understand both approaches and choose based on requirements.If you're an agency: Develop capability in both. Use platforms where appropriate. Build API-first for client systems that need to scale, evolve, or integrate AI deeply.The future belongs to those who control their orchestration logic, not those locked into platform abstractions.
Building production automation or AI systems? We can help you evaluate the right approach for your specific requirements and build systems that scale.
[Talk to us about automation architecture]
About ThinkSwift
We're a creative software agency in Melbourne building AI-powered business systems. We transitioned from platform-based automation to API-first development after hitting platform limitations on client projects. We still use platforms where appropriate but default to code for production systems, especially those involving AI. This gives clients better performance, lower long-term costs, and full ownership of their systems.
.png)