My 3 Years of Dealing with Social Media APIs (And Why I Am Losing My Hair)

Marcel Czuryszkiewicz — Fri, 21 Aug 2026 08:49:14 +0000

Well, three years into building and maintaining social media integrations, and I still haven't gotten used to the sheer paranoia of hitting "deploy." I've been doing this for a long time now, and at this point, you'd think my body would've accepted that undocumented API changes are just part of the job.

aaaand It has not.

Writing new features isn't the worst now, but maintaining them is hell, because sometimes (a lot of the time) platforms decide to throw in undocumented errors or, worse, a change (Im looking in the direction of LinkedIn). Before we started this, I was doing a lot of backend work and AI development, so I had a pretty good grasp on error handling

But no. I got dropped into a world where platforms communicate in riddles, HTTP status codes are mere suggestions, and treating every failure the same way means your customers' followers get spammed with the exact same post five times in a row, but this is still not the worst part.

I don't know if you know this guy here:

but he is running a channel called Xiaomanyc, basically a polyglot channel (guy speaks a lot of languages). Social Media platforms are the same, 5 out of 15 integrations that we have return errors in diffrent languages, so we have a translation map to deliver unified error messages in plain English. The languages we have right now are Korean, Japanese, Russian, Deutsch, French, and Spanish

A lot of my work over the last three years has revolved around one single question: Retry, or give up?

There aren't many moments where you can just go, "hmm, let's just retry aggressively and see what happens." The system exists, people depend on it, and the mistakes are not symmetrical.

If you retry a terminal error, it’s annoying. You burn through your rate limits, the eventual failure notification gets delayed, and you waste time. But it's recoverable.
If you retry a non-idempotent success—meaning the platform did accept the post but the network dropped before they could tell you—congratulations. You just published it twice. Your customer is now dealing with refund conversations, angry followers, and an outright spam flag on their account. Or my favourite one, post is made, the platform returns a 500 code so the client tries again and then magically the old post is processed and published, but the new one is still incoming, messing the whole thing up.

The three buckets of doom

When an API fails, the error goes into one of three buckets: Retryable, Terminal, or Unknown. And that third bucket is exactly why I'm 26 but have the hairline of a stressed-out 40-year-old. I'm using minoxidil daily...

Im a crisp 3.

I might get a random string back from an endpoint. There's a manual we try to build internally telling us which fields to check. But then there's this little voice in my head going, "Okay... but what does this error actually MEAN man?"

Why did they return a 200 OK with a fail message inside the JSON?

And more times than most the answer is:
I DON'T KNOWWWWW.

We (rather I) actually ended up writing a deep dive on Social Media API Error Handling with the exact error code matrices we use in production if you want to see how deep this rabbit hole goes. Non-fluff version with platform split is here

I don't know what the final lesson is yet, and maybe that's the most honest way I can end this. I'm still in the middle of it. I'm still maintaining that cursed error classification table and still wondering when my hair will stop falling out.

Maybe the lesson is just that your job doesn't always give you the exact technical experience you thought you were going to get. Sometimes it gives you a masterclass in defensive programming and sheer survival instead.

Keep your head up, Marcel

Your Software Architecture Is Quietly Copying Your Team

Marcel Czuryszkiewicz — Wed, 29 Jul 2026 21:19:43 +0000

If this is too long, tldr: Google Conway’s Law wath yt video and think

There is a popular rule in software development called Conway's Law. It says that organizations design systems that mirror the way people inside those organizations communicate. In simpler terms: Your architecture will eventually look like your team structure. Big company with separate frontend, backend, data, DevOps, and platform teams?

You will probably end up with separate services, separate processes, separate ownership, and a lot of API calls between people who sit in different Slack channels. But what happens when the entire company is just two people? That is where things get interesting.

At bundle.social, we are running a unified social media API that handles a lot of edge cases. And there are two of us. There is no dedicated platform team No analytics department No infrastructure group. No product manager translating customer feedback into Jira tickets. Just two people are trying to keep a fairly large system moving without turning it into a pile of slop services nobody fully understands. You would think Conway's Law does not really apply to such a small team. It absolutely does. It just shows up differently.

How Conway’s Law Works in a 2-Person Team

When you have 50 developers split across departments, Conway's Law creates microservices and cross-team dependency hell. When you have two developers, Conway's Law forces your system into one of two extremes: The "Two Halves of a Brain"

Split: Service A belongs entirely to Person A, and Service B belongs entirely to Person B.

Because human communication between two people has practically zero friction, it's extremely tempting to drift into the lazy version of Conway's Law: ignoring technical boundaries altogether because "we can just talk about it on Slack." Why write explicit API documentation when you sit next to the person who wrote the endpoint? Why enforce strict domain boundaries when you can just export a helper function across modules in 5 seconds?

That's the trap G.

When communication is effortless, your architecture turns into a mirror of two individual mental models mashed together. And if one person goes on vacation or takes a weekend off, the remaining half of the team is left staring at a black box they never touched.

The Trap of the "Hero Service"

We handle social media integrations dealing with changing platform schemas, rate limits, OAuth refreshes, and webhooks across multiple networks.

In the early days, if Person A (me) built the LinkedIn integration, it lived entirely in Person A's head. If Person B built the video processing pipeline, it was Person B's private territory.

Conway's Law meant our architecture wasn't mirroring an organizational chart it was mirroring our individual brain dump.

We realized very quickly that when on-call duty represents 50% of the entire company, you cannot afford "Hero Services." If a background job fails at 2 AM (it did), the architecture needs to be understandable by whoever happens to be holding the phone, without requiring a 30-minute explanation.

How We Design Architecture for Two People

Instead of fighting Conway's Law, we decided to leverage it intentionally. Here is how we design our system to fit our real-world team dynamic:

The "Pragmatic Monolith"

Over Microservices We don't need 10 microservices communicating over gRPC. That setup mirrors an enterprise with 10 separate team leads. Instead, we maintain a clean, modular monolith. Code is co-located, deployments are simple, and mental overhead is kept to a absolute minimum.

Code Boundaries Over Personal Preferences

Even though we can reach into any part of the codebase, we enforce strict domain boundaries and clear interfaces. We treat internal modules with the same care we'd treat an external API. If a new feature requires a massive, messy cross-domain hack, it's a sign that our architectural boundaries are getting as sloppy as our task lists. Our Rule of Thumb: If it takes more than 2 minutes to explain how a module handles errors to the other person, the module is over-engineered.

Asynchronous Code, Asynchronous Context

We write code assuming the other person will have to debug it with zero warning. That means:

Standardized error handling across all integrations
Self-healing background workers over manual intervention scripts
Clear log traces over "tribal knowledge."

Design for the Team You Have Today

The biggest mistake small startups make is building architecture for the 500-person company they hope to become in five years.

They end up paying an immense "architectural tax" managing Kubernetes clusters, distributed tracing, and complex microservice orchestration with a team of two.

Your architecture will always reflect your team structure. Don't fight it, and don't pretend to be Netflix.

Embrace the 2-person dynamic: keep it lean, keep it unified, and build a system simple enough that either of you can steer the ship alone without sinking it.

Takeaway is this

Your system will reflect how you divide problems, how you discuss them, and where information gets stuck. Don't mess that up.

Ps I actually wrote that for Medium but got zero traction, so maybe you will find it helpful

DEV Community: Marcel Czuryszkiewicz