|
Welcome back! In case you missed it, we/I am doing a weekly newsletter on all things integrations. On a personal note...I was waffling on how to open this week's newsletter. I wanted to highlight our three kids, their current personalities, and the fun conversations I like to have with older adults who have adult children-
Instead of giving psychological profiles of our kiddos to internet friends 😂 who definitely didn’t ask me for it, I’ll instead just go a different direction. For the umpteenth time I got a version of the question “what do you do?”, this time from my wife’s aunt, who said “Sean, I love your posts on LinkedIn recently, but I really still can’t understand what it is you’re doing. You’re clearly passionate about it though 😅” So, what is it exactly that you do? It’s been the long running joke when I’m anywhere with Nicole (my wife) and someone new asks us what we do. If they look at me first, we chuckle and hand it to Nicole. Until last September it was “I’m a 4th grade teacher” 👌 No notes, nods of appreciation, often sparks an education based conversation. Turns to me, “and we still don’t know how to explain what Sean does”. It's probably on me at this point to solve that. So here is me trying... tell me how I'm doing? My problem is that It’s so in the weeds of software development that it’s really dependent on who I’m talking to before I give any sort of summary. I’ll usually stick with versions of “I’m a cofounder of a software development and consulting agency”. If they have an inkling (or they’ve told us what they do themselves and it’s in tech) I can usually say “we build integrations”.
I think the best way to describe it has been coming out of the reflection I’ve been doing on our past 10 years of business. Here's a brief timeline for Left Hook pivoting into integration development. When I joined, I was told to be entrepreneurial and just sell whatever I could.
And so, a business model is born. Here, I even did a little diagram about it: We learned APIs and platforms and then wanted to reapply those learnings however we could. We learned so your team didn’t have to. In a dummed down sentence: People building software--and people using that software--need another group of people to help them bring all those different softwares together so that they play nice. We’re part of that “other group of people”. (We also happen to be the people in the first group and the second group. More on that later) I don’t know if that’s helpful here in this space. But it’s the ethos of everything we’ve been doing. We’ll take on the "bleh" work so you can stay focused on the "aha!" work.
As for the rest of what I do... it’s pretty much everything in the business you might think of. Thankfully we don’t have a physical office else I’d also likely be taking the trash out too. (Speaking of which… *runs outside to bring the bins to the curb*)
I think the intersection of “software development”, “integration/automation”, “strategic consulting”, and “entrepreneur” is what I want people to think about when they walk away from that “what do you do?” conversation. Anywho, onward to the second ever newsletter! What we’re seeingGrammarly Acquiring Superhuman It’s weird and fun seeing a previous client be acquired by another company. Coda was acquired by Grammarly last year (finalized this January) and they’re at it again acquiring Superhuman. We were helping Coda add some “packs” to their platform. To this day I still get GitHub notifications to their coda packs sdk repo, and let me tell you- they are still going strong 😂 Coda as a client provided our first go at playing around with code generation came pre-LLM/AI book, while we were building 5 packs with a mix of Open API spec (api documentation) and CLI tooling with templates. So when I saw that acquisition and this new one by Grammarly, I thought “okay… maybe?” In some cases acquisitions are for tech. In other it’s for people or business. Or distribution. Or a mix. I think this is a mix… the vision seems directionally like it makes sense, but it feels like a bet, and it’s an AI centric bet. Is Grammarly’s LLM + non LLM AI mix a strategic lever that now has 2 robust products as distribution? I'll let the professionals analyze the whole scope of the deal, but obviously my API colored glasses has me thinking: it comes down to how well they can integrate things. And in these cases I’m always interested in seeing how the acquisition changes or improves the attitude towards external developers and partners. Airtable Pivoting The other news that caught my attention was Airtable going all in on a platform “pivot” to “AI native”. Which at this point I believe means “we think you’d rather have a chat box interface to do most of your work here, and it will then manipulate air tables on your behalf”. I’ll dig in more, but again I wonder what this does for the tech partners? I’ve wondered the same thing for Zapier for years. They’ve built up this incredible cadre of partners (albeit, with a limiting technical factor that may be their technical Achilles heel, happy to unpack). And in that time they’ve added a half dozen new products or product features. Oh and I don’t know if you’ve heard, but they ALSO do AI and MCP (this was a joke, I know you’ve heard or could have guessed). Yet, to this day Zapier has yet to expose any other parts of their platform to external developers to build anything resembling what they did for their workflow engine. In part I get the product theory is that they are hooking everything on top of those workflows (all of the Zapier app building blocks). Missed opportunity. Both to entice partners to come back and grow their presence on the platform, and to make the rest of their product more sticky and interesting. Which leaves me with questions...
I believe the lines will hold. The AI fizz will simmer down and we’ll see that the water is higher and there are new things floating around, but the software jobs to be done are still being done and still need to talk to each other between the islands. How about you? What we’re hearingSome of you gave me some great feedback to my last email and one specific request was: what sort of problems were clients having post integration? Luckily, the number one came up again this week (and is a forever recurring theme- integration discovery post development). Unless you make the integrations front and center or part of the product experience, you’re just going to be disappointed with adoption. Time and time again I see this. And in this case “product experience” means “your customers experience interacting with your company as a whole”. So not only self-navigating in your software (if you have a UI), but also in their conversations with support, in your newsletter or feature release email, in your help docs, user onboarding flow, sales conversations, marketing material, LinkedIn and social media posts. All of it. Unless you’ve got those running strong, you’re going to get lukewarm results.
Thinking about internal automation for SaaS companies On the other side of the coin (meaning, helping SaaS end-users with their process automations), we’re hearing a few not uncommon themes (“our HubSpot data is a mess and needs cleanup then automation in place that works”)… but with a fun new (to us) wrinkle: Helping a SaaS company automate their internal systems that rely on a core system of record that is not represented by any API on any integration platform. Basically, reading from the core DB and syncing to HubSpot in this case. But you can imagine other cases. What do you do in this case? We have a few options in front of us:
In almost all cases though, I dig in to figure out what the team is already using or accustomed to. Not using any integration platform, but they ARE using HubSpot’s workflow builder? Okay, let’s use the familiar and just do the core data sync in some custom code, the rest of the manipulation can happen in HS. And so on. Getting it right in the age of low cost and fast development with AI The other thread to pull on from conversations this week- when AI dramatically decreases the time and cost to develop integrations, the concern is no longer choosing to do something that takes too much time. The concern falls squarely on getting it right. I’m currently helping three different clients figure out how to “get it right” for three different HubSpot apps and two Salesforce apps (and some data syncing apps with Square, Stripe, and Etsy). The cost is not the factor. Getting it right, is. What that looks like is a set of product and UI/UX design questions, centered on the users’ needs. And in each discussion, there was/is a theoretical user. So we’ve been scaffolding up prototypes to talk over with potential users to get their feedback. This part cannot be automated. What can be is the development work after the fact, and better tools to really capture the feedback. And better analytics to “listen” to the users post delivery so we know how they’re actually using the thing. I do think that over time we can aggregate enough "best practices" across industries, applications, platforms, user types, and more... but for now, that's scattered information that isn't really publicly available anywhere, which means the LLMs are going to be rough proxies at best. So it comes back to to the same fun thing as it always was- it's time to talk to your users and customers. What we're doingI'm switching this part up a bit and going to harken back to this diagram from last week: So, what we're doing for each one:
Reply to let me know your thoughts. What do you want to know more of? Smash that unsubscribe button below if you don't like it. Forward to a friend if you do! Until next time!Sean Matthews |