Why Building Your Own Social Media Tool Is a Trap

Does Building Your Own Social Media Tool Make Sense Beyond a Solo Company?

Nathan: All right. As always, here with the co-founder of Ordinal, Jeffrey. I'm actually excited about today's conversation specifically, because it's something I think a lot of teams are talking about, which is build versus buy with social media tools.

And it's 2026, so a technical founder can vibe code a working app in a weekend. It's never been easier to do that, but it's also never been more rocky if you don't really know what you're doing. So walk me through really quickly. Somebody has a Tuesday afternoon thought and they think, "Why am I paying for a social media tool? Claude could just build me a scheduler." Does that instinct hold weight beyond a one-person solo company? And if not, for larger teams, where does that idea start to fall apart?

Jeffrey: Yeah, I feel like your question, Nathan, just structurally encapsulates the difference, I think, for us, which is that I think it is actually a viable solution nowadays for a one-person team, or you're just doing content for yourself. Sure, it's probably possible. The difference, though, is for teams I would probably not recommend it quite yet.

Again, we're all for vibe coding, to be clear. We think that a lot of solutions that exist today will maybe look obsolete in a few years. But I do think that there is a fair amount of structural complexity in building a team social product than it looks like beyond the surface. I'm happy to go into the details. One is, the unique thing about socials is it's not an isolated sandbox, right?

So you have to get API approval from all of the networks that you wanna post to. Those approval processes take months. It takes a lot of legal and compliance work. It's not necessarily a standalone software SaaS app, right, where it's completely self-contained and you're not blocked by anyone else.

There are third parties like LinkedIn and Twitter and Instagram, et cetera, that need to approve your access. And especially as of late, that's become a little bit more difficult. I think the second and probably larger point that I would make is, for teams specifically, there's actually a lot of depth to a product that works well versus something that's vibe coded.

And this is how we've kind of approached things internally as well: if there's a simple agent that I can make that does something that just lives standalone, then great. That's kind of something that we would focus on vibe coding. But the things that we don't try to touch are more infrastructural.

And what I mean by that is, take a few things about Ordinal, for example. One is just everything that looks as simple as collaborative editing and version history and inline comments that are necessary for teams, right? It takes quite a lot of technical depth to have actually an editor that can do all of these things. Or, for example, the actual scheduling of cron jobs.

So if you wanna deal with scheduling and figuring out, making sure that everything is reliable, that the random errors you get back from a network go through the correct retry logic and try again. You want an actual robust scheduler that works 99-plus percent of the time. There's actually quite a lot of logic that goes into there beyond just hit the post endpoint and just hope for the best every time that it returns a success.

'Cause oftentimes it doesn't, and the reason it doesn't can be very random, right? I don't think these networks are very consistent. And there's a lot of inconsistency that you have to deal with in edge cases there. And yeah, even just integrating into the rest of workflow and things like that. Where we do really encourage people to vibe code stuff, for example, is building a social content agent for yourself that ingests uniquely your company context and more background about your business.

Maybe the way I would say it is, at the end of the day, yes, you could vibe code any software. You could vibe code Salesforce, you could vibe code Ordinal, you could vibe code this and that. But the point is that vibe coding has a cost, and maintaining vibe coded software has a cost as well.

And so maybe the question is, where do you wanna focus your time and energy with your vibe coding efforts? And for us, we think the more valuable place to do so is to build agents rather than build infrastructure. And at least at Ordinal, that's why we believe we are the orchestration layer.

We will be compatible with whatever agents you build. But we think for most teams, it's not a good idea to send your social manager on a mission to basically vibe code a bunch of scheduling and cron jobs and editor software, which is probably not the best use of their time, nor will necessarily net the best results.

How Hard Is It to Keep Up With Every Platform's Changes?

Nathan: Well, let's talk about the maintenance tax a little bit of building it. So not just building the thing, but keeping it working across six platforms that each change their rules. How aggressively does Ordinal have to keep up with all of the changes across every platform, to the point where it becomes a full-time job in its own, just maintaining?

Jeffrey: I mean, it's very constant, right? API releases happen monthly for these platforms. I think that maybe what I would say is, vibe coding follows this unique arc, right, where I think we've all experienced it. I've experienced it myself all the time, where the first two hours into a vibe coding session, you are just so pumped.

You're like, "I'm building the greatest thing ever. This is the most incredible tool of all time." Then you start to hit a few bugs, edge cases, things that the AI can't really solve easily. And then you deal with things that happen down the line. We have a sales agent, for example, that I vibe coded.

It gives us company information, writes us a brief about every sales call, all of that stuff. The other week it just died, and I was like, "I have no idea why it died." It had run out of credits? Something with one of the APIs changed? Did one of our logins expire? And if I'm honest, it hasn't been revived yet.

And I think the reason why is I just don't wanna spend the extra hour now to go into Claude and debug it and fix it and tell it to fix itself. Of course, one could argue you could set up more complex monitoring, you could have it auto loop. Of course, there's always solutions.

But maybe my point is these solutions all take time, and I think my time is best spent building specific types of things when it comes to vibe coding at the moment, versus it replacing... I'm not gonna vibe code Google Docs, is maybe the thing I would say. It works, it's stable. There's actually a lot of complexity that goes into it. I'm not gonna vibe code Slack. But I will vibe code a very, very simple utility software, or something that has a very simple use case that doesn't require much maintenance.

Nathan: Yeah. Well, and it felt like you were speaking directly to me at one point, because last week I was doing something and I got that terrible message from Claude Code that was like, "Oh, that was my mistake." And I was like: You can make mistakes? No, you can't make mistakes. I need you to do this. But it happens more often than you would think when you start getting into the intricate levels.

What Does Compliance Look Like When You Post for Ten Executives?

Nathan: And that's one thing I wanted to talk about, where you've said that sharing passwords in the past, if someone were trying to build their own software, it violates some platforms' terms of service. And what's a compliance layer look like when you're posting on behalf of 10 different executives? And what happens to a homegrown script when LinkedIn changes that API?

Jeffrey: Oh, that's a great question. So with the API, you would get an official authorization token, so it's fine if the user changes their password or any of these things happen. But the point with the API is you have to get approved as a developer on LinkedIn's platform, and so that process takes time, right?

Maybe the way I would put it is, your agent can go set up a lot of stuff for you with no blockers. It can go set up an email service, it can set up text notifications, it can set up a lot of cron jobs that run. But because scheduling is dependent on a third-party platform as well, like LinkedIn, you do have to get approval from them to actually be able to interact with their endpoints.

It's not just open. You can't just use your LinkedIn account and then suddenly start hitting the post endpoint today. That's true for all the other platforms as well. So this is true for all social platforms. And maybe the reason why I think this is important is, yes, you're right, actually, Nathan.

The workaround we see a lot of people build is, then they just build something that inputs the passwords for people. And so I would be very scared at any team of size about a lot of security concerns there. I mean, everything from: is the person vibe coding it actually storing passwords in the database in a secure way? Are they encrypted? Did they tell their agent to take all the best security practices when you're dealing with sensitive information like the password for your CEO's LinkedIn account?

All the way down to the difficult... There's a ton of maintenance that's gonna come if you have a password-first solution, because everything from somebody turns on 2FA randomly and they forgot to tell you, somebody changed their password, somebody did this.

I mean, at scale, as you start posting for multiple execs, and I can't even imagine running an employee advocacy program doing this, right? Can you imagine asking five hundred employees to share you their passwords on an Excel sheet? It's just not gonna happen. And so I just think that you run into a ton of barriers very quickly.

But again, yes, if it's just your own account, maybe it's okay, right? And we'll clarify that it does violate the terms of service of all these platforms, and maybe you can get away with it for a little bit, but it's probably not something we'd recommend for any team.

Why Is a Realistic LinkedIn Preview Hard to Build?

Nathan: Well, and I can also see how the idea of vibe coding sounds appealing, but, and this is something that I'll throw myself under the bus, when it just comes to even a realistic preview of, let's say, LinkedIn, which is an Ordinal feature where you can see what it's actually gonna look like on the platform.

It sounds like a one-prompt build, but it's not. Why are things like that actually hard? And then what goes wrong for teams, or people like me, who skip it and assume, "Oh, it knows how to make the preview. It's fine."

Jeffrey: Yeah, I think it's just the devil's in the details, right? How upset will you be if you have a really important post and you're relying on this vibe coded preview, and you find out that it's off by a few pixels, and actually half your sentence got wrapped into a new line and hidden by the "see more," and now people who skim it don't even know what the announcement's about?

Maybe that's an extreme example, but I think over time these cases will keep coming up, right? You can do it, is maybe what I would say. But my point is, with every edge case of how does a PDF render versus an image versus a video. Guess what? LinkedIn renders images differently when there's one versus two versus three, and then there's a whole case for four plus, where it changes into a whole different UI.

Also, different versions of feeds for different people. PDFs have interactions, so you have titles that can show up dynamically over the asset. You have to be careful where that cuts things off. Videos have different rate limits, sizing dimensions, the way they render on other channels. Every channel's different. And so if you imagine this matrix, you're dealing with hundreds of different edge cases to be able to actually have a realistic preview.

Of course, you can have your agent do it. You can check it and make sure it's correct. You can even have your agent check it itself and make sure it's correct. But there's a lot of time to document all the preview cases for an agent to be able to build and solve. And so I think it's just more like, it's not even that you can't solve this preview problem. We're talking about these isolated examples, but to just build this whole app, right?

This preview is like two percent of what we think a truly good scheduling app, social management app is. And so if you do it all, it takes a lot of time, basically. And at a certain point, I would say the cost-benefit analysis isn't worth it for most teams. It's not universally true. I really do think that a lot of individual creators maybe can vibe code their own solution, and it makes sense for them.

But interestingly, maybe the last point I'll put up here is, I think we don't deny that vibe coding is a thing, and that's actually the reason why Ordinal is a very open and composable ecosystem. We do this very differently than other competitors. If you don't like our analytics dashboard, it's no problem. Every single analytics data point is exposed through the API, through the MCP. We have webhooks for every event. You can get anything in and out of Ordinal.

And the reason why that's important is... Think of Ordinal as having done all the grunt infrastructure work for you, and you pay a small premium for that to not have to deal with maintenance or vibe coding. And if you wanna build the craziest analytics report and a dynamic HTML website, I actually think that's a great use case. We make that super easy, right?

We deal with all the robustness of getting the data accurate in front of you for every profile, syncing every X hours for each post. And then you can just take all that data, and you can build, to your heart's desire, the type of reporting you want, the type of customizations. We still believe that the majority of users are served fine. The use cases have enough in common that most people are served fine.

But if you are in that twenty percent or ten percent that feels like you want some extra things, and you don't wanna be blocked by us shipping it, we make everything super open and composable. So if you are inclined to vibe code, you should, and you should build really great things. And a lot of our best customers do.

One that comes to mind is Ryan from Zapier. The whole Zapier team has used Ordinal's infrastructure and built so many cool utilities and tools and automations internally, and we really think that's the best way to do it. It's not worth their time to build API permissions and scheduling and keep up with updates there, and concurrent threads for editors, and tagging and notifications and emails, and all the base stuff that has to come in, and constantly QA that.

They should spend their time building the cool automations on top of this infrastructure that exists, that help Zapier do socials the way they can. And that's really where we think things are, in this really interesting place right now: you can build stuff on top of software that's more open and compliant to almost supercharge the use case, but there's no need to maintain the core functionality, which is really where the cost is.

Nathan: This doesn't surprise me at all, hearing about Ryan at Zapier. Such a creative person with the right infrastructure can build really cool things. Whereas sometimes you get the feeling with vibe coding, you start with something, the infrastructure is weak, and then as those edge cases come up, you just start to put duct tape on top of duct tape to fix them, and then hope that it stands.

Should Teams Buy the Core and Build on Top?

Okay, so build versus buy, an age-old question. When it comes to social media tools, though, it sounds like the answer is saying more of a hybrid, where you should buy the compliant orchestration core and then build workflows on top of it, customized to your needs. Is that a fair summary?

Jeffrey: I'd say that's 100% fair. If you're into vibe coding, which you should be, then I would say that's what I would suggest in terms of getting started.

Nathan: All right. Build versus buy. The answer has been solved today. I'm marking the calendar. That's awesome. That's definitively done. This is good. All right. Well, that's all I have today. Thank you, Jeffrey, so much for taking the time to chat, as always.

Jeffrey: Appreciate the time as well.