For example, I’ve been using Zoho Desk for customer support and it’s excellent (even the free version is extremely feature-rich), but sometimes I wonder if I should build the functionality right into my app to create more of an integrated experience.
Anyway, although I’m sure the answer is “it depends”, I’m just curious what you tend to prefer in your apps - integrating or building yourself - and why?
I always build it myself if I can. I like making it fit my style. For example, I made my own forum. It does exactly what I want it to do. I built it in a day and was worth the time.
Also, things break less because I don’t rely on so many other APIs and plugins. My app breaks only when bubble breaks. 
Not when bubble, or this other API breaks, or when this plugin breaks or that plugin breaks.
I guess its just more reliable when I build it myself. Also, I normally can build it the way I want and make it better.
Oh, and normally it saves me a bit of money that way too.
I only integrate an API or Plugin when I can’t do something myself or if it’s faster than the one I make because of bubble limitation. Like making PDFs, no way would I be able to do that on my own yet.
Just my two cents.
i think we are VAR’s (Value added resellers) not no code developers or will be. Bubble provide the glossy veneer for other stuff… api … third party services and apps (love that). Yep DIY build it your self…but why fight…take stuff that good solid app if it integrates do it… justify your idea… if there is traction then go back and take your time making it core bubble.
To offer my slightly controversial take: if you are building an MVP, your goal should be to build as little as possible in Bubble. Then, use 3rd party tools to fill in the gaps. Specifically, if there is a free tier / ~$10 product / plugin that does the service well, then implement it.
Otherwise, replicating utilities like Intercom, Zoom, FullStory, Medium, etc. inside of a Bubble app means you’re not working on features that support proving your MVP’s viability and creating more “code” to maintain (or, worse yet, tinker with).
Then, as you develop a stronger foundation / prove your MVP, go back and re-evaluate tooling. (Heck, I’m still surprised by A-list startups that I see using Google Forms and 3rd party tooling).
I would go further 
Push as much as you can off to others, be they humans or machines.
In with @J805… I see many posts on here about things that used to work in plugins but now there was an upgrade and something got broken. For me, I want to rely on
i would say the plugins are duly updated from both free and commercial providers.
Yes that is true… and I think it all depends on who your app is targeted at and how critical it is to their business.
My app will run the entire administration and customer booking process for (hopefully!) hundreds of small businesses, so it has to be as reliable as possible… and when things go wrong, I need them to be as under my control as possible.
Hence the perspective I put forward.
But for many other people the situation their app will be used in is very different.
So of course, it depends!
This shouldn’t be controversial at all. Don’t waste time on stuff that isn’t core to your app. Web visitor chat is the perfect example. You just CAN’T build a decent one in Bubble. So why bother? But people expect you to have that (AND, BTW, they use it — it’s the #1 way I get new PAID users).
i think i can.
Are talking about this chat? If so, that’s not built in Bubble, they’re using Hubspot Chat on their Bubble site.
Stop! I think you’re missing the point of what Keith is saying here
its not hard to build. Bubbleboy, im not missing any point, im making one silly.
If it’s not a feature that you’re selling to a customer for their use, why spend the time? I think focusing on your core/actual product, and augmenting with external services for the support of your product is the quickest way to market. Your time is money too. If it only costs $4 per month for a plugin/service, but it would cost 40 hours to build * what I’m worth per hour to build a similar plugin/service in Bubble, then I’m going to go with the $4 per month option to begin with.
If you are already to market and your product is viable, only then would I think about building custom, internal support pieces.
Of course, there are always variations to this. For example, if you only need a simple feedback form that allows users to submit bugs/questions, then that may be something that is easy enough to build into the actual product.
i dont use bubble for business lol.
its a hobby, bubble is just a cute mvp tool.
Welp, @anon65040322, you can do the onsite part fine, of course. I’m talking about things like having an app and all sorts of other notifications. It’s much easier, for example, to install and configure FreshChat (the free level continues to be fine for me) than to spend any time building the whole thing out. Of course, I also have a big friendly “Questions? Ask us anything.” type button on all interior pages of the app. (That opens a popup that, when submitted, sends us an email – it could also send us a text, too if I chose.)
But FC, when properly integrated shows me everything I need to know about a user who is pinging (like are they logged in / a user, are they a paid subscriber, what page are they asking their question from, their direct contact info [if they are registered user]), and lets me respond from my mobile phone on-the-go, or from the desktop. All without cost. And it took < 1 hour total to get that all set up.
I see users using either method to contact me, but FC is the one that is available to new visitors / not logged in visitors. Most of the time, the questions folks ask are basically “there’s just one thing I want to know before I subscribe…” type questions. Being able to get instantly notified anywhere lets me close those deals.
(Had one last week where the user has 13 properties. He basically wanted to know where and how to pay. While still chatting with him, Stripe notification for 13 monthly subscriptions came across. Super powerful.)
Similarly: Stripe manages my subscriptions. Sure you could use Stripe for individual payments and manage the subs part yourself, but WHY eat up your app’s capacity for that? You won’t build a better subscription engine that Stripe’s. I won’t either. It’s not interesting to me.
Etc., etc.
Edit: BTW, folks use both methods to contact us. I immediately started to get questions/feedback messages when I set up the “ask us anything” email button which lives in the header of most interior pages. But the FC button (installed lower right where folks expect it) gets more use and the immediacy of that is very important.
yeah i understand. you dont have to justify to me that you get customers, im sure you do, its just the type of applications i would like to build dont scale well in bubble.
I’m definitely in this camp @NigelG @dan1 @keith @Kfawcett .
We should spend the bulk of our time developing the core value prop of the app – the central reason for the app to exist in the first place. Today’s successful companies know exactly what their own value prop is, and then build integrations that give customers options to interconnect all their point solutions.
I would add that even when you are past MVP don’t waste your time chasing shadows. I have another saas application built using Python and have “traditional” coders working on that for me and focus on the features customers want. We use Zendesk for all customer support because that is their main focus not ours!
Early on I started building everything in house ‘because I could’, such as a website builder, an email marketing add on, an internal customer CRM. It was fun and had a lot of the features I wanted, but I found I was spending way too much time customizing, tweaking and supporting those services that it took away development and sales time from the main app.
Now I have a white label website builder for clients and am phasing out my emailer to just allowing clients to integrate with big name email providers. In the end it’s providing better quality features for my customers and saving me a ton of time and worry.
