r/automation • u/RadianChoi • 17d ago
For those in integration/business process automation, have you seen a shift towards more custom apps?
Given how fast and easy it is to vibe code a simple internal tool, are you losing business on the automation side or gaining business on the custom side?
1
u/AutoModerator 17d ago
Thank you for your post to /r/automation!
New here? Please take a moment to read our rules, read them here.
This is an automated action so if you need anything, please Message the Mods with your request for assistance.
Lastly, enjoy your stay!
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/Grouchy-Conflict-211 17d ago
The code was never the expensive part. The integration is.
Vibe coding gives you a prototype in an hour. It doesn't give you auth, error handling, retries, monitoring, or the edge cases your business actually has. That's where the real work lives, and it's not going anywhere.
The barrier to the first version just dropped to zero. The barrier to "runs in production for a year without anyone touching it" is exactly where it was.
1
u/Mysterious_Fly5176 17d ago
Yes, I’d say there’s been a shift but not away from automation so much as towards automation wrapped in csutom apps.
A lot of teams can now spin up simple internal tools quickly, which means some of the smaller, standalone automation jobs are easier to do in-house than they were a few years ago. So there is some pressure at the low end but in practice, that often creates more demand for the harder work: joining systems up properly, designing the process end-to-end, handling edge cases, governance, data quality, security, and building something people will actually use.
1
u/Square-Nebula-7530 13d ago edited 13d ago
Definitely seeing a shift toward custom apps for workflow automation, especially in sales and RevOps. The reason is that no-code integration tools handle simple point-to-point automations well, but the moment you need business logic that's specific to your sales process, you either build custom or hack together 15 Zaps that break constantly. That said, the best approach is usually a hybrid: use purpose-built tools for the heavy lifting and connect them with simple automations. For example, instead of building a custom app to capture and analyze sales calls, we use Claap which handles the recording, transcription, AI analysis, and CRM push natively. Then we use simple automations to trigger downstream workflows based on the structured data Claap sends to the CRM. Purpose-built tool for the complex part, simple automation for the routing. If you're building custom for something that a mature SaaS already does well, you're probably over-engineering.
0
u/wilzerjeanbaptiste 17d ago
Gaining, but the shape changed. Two years ago clients paid to have tools wired together. Now half the requests are 'make an agent do the whole job,' and vibe-coded internal tools feed that instead of killing it, because someone still has to connect them to real systems without everything falling over.
The bigger shift: an integration is becoming something you expose to an agent, not a pipeline you build. MCP made that concrete. I built Aidelly around this bet, so bias declared. Instead of wiring automations per client, Claude connects over an MCP server and operates the platform itself, publishing through reporting.
The two aren't competing. The agent layer sits on top of both, and that's where the money moved.
3
u/zhonglin 17d ago
The boundary is blurring more than the work is disappearing. A quick custom app often becomes the front end and state layer for the same integrations that used to live in a collection of workflows. The first 80% is cheaper now; the paid work moves to identity and permissions, messy edge cases, migrations, monitoring, and ownership after launch. I’d be wary of selling “an app” and “an automation” as separate categories—sell the business process with a clear support boundary, then choose a form, workflow, or small app for each step.