PostProxy is Supabase for social media publishing

What Supabase actually is

Supabase is not a database. Or rather, it is not just a database.

What Supabase built is a collection of backend primitives — database, auth, storage, edge functions, realtime — packaged so that developers can assemble them into a working backend without building any of it from scratch. It is opinionated enough to be useful immediately, but open enough to extend in any direction.

The insight was that most applications need the same backend building blocks. Auth is hard. Storage is tedious. Real-time sync is complex. And every team was rebuilding these from scratch, slightly differently each time. Supabase made those primitives available as a service so developers could focus on the parts of their application that actually differentiate it.

Social media publishing has the same problem.

The primitives every publishing application needs

If you are building any product that touches social media publishing — a CMS, a marketing tool, an AI content pipeline, an e-commerce platform, an agency dashboard — you need the same set of primitives:

OAuth and token management. Every platform has its own auth flow. Users connect accounts. Tokens expire. Refresh flows differ by platform. This alone is weeks of work if you build it yourself.

Media handling. Images and videos need to be uploaded, sometimes transcoded, formatted to platform specs, and passed to publishing endpoints in exactly the right way. Instagram has different requirements than TikTok. LinkedIn has different requirements than YouTube. Getting this wrong silently produces failed posts.

Multi-platform routing. The same piece of content needs to reach different platforms with different formatting, different media constraints, different character limits. Managing this in application code means a growing tangle of if-statements.

Scheduling and queuing. Posts need to go out at specific times. Queues need to be managed. Slot logic needs to be calculated. Jobs need to be retried if they fail.

Status tracking and webhooks. After a post is submitted, you need to know what happened. Did it succeed? Did it fail? Which platform rejected it and why?

These are not differentiating features. They are table stakes. Every application that publishes to social media needs them. Almost no team should build them from scratch.

PostProxy as a collection of primitives

PostProxy provides these primitives as an API.

Profiles are the connected social accounts. You call the profiles endpoint to see which accounts are available, what platforms they are on, and whether their tokens are healthy. You do not manage OAuth flows — PostProxy handles that.

Posts are the publishing primitive. You submit content with a target set of profiles and PostProxy routes it to the right platforms, formats it correctly, handles media uploads, and returns a post ID you can use to track status.

Queues are the scheduling primitive. You define a posting schedule — frequency, time slots, timezone — and drop content into the queue. PostProxy handles the rest, pulling content at the right times and sending it out.

Webhooks are the event primitive. When a post succeeds, fails, or changes state, PostProxy fires a webhook to your endpoint. You do not need to poll for status.

These primitives compose. A CMS can connect profiles, drop content into a queue on publish, and receive a webhook when each post goes out. An AI pipeline can check available profiles, submit generated content, and track status programmatically. An agency dashboard can manage multiple brands through a single API with profile groups.

You are not building the infrastructure — you are building the product

This is the Supabase insight applied to social media: developers should be building the product, not the plumbing.

Supabase did not tell developers what to build with auth and storage. It just made those primitives available so developers could focus on the features that differentiated their products. The infrastructure became invisible.

PostProxy works the same way. If you are building a social media scheduling tool, your differentiation is in the user experience, the AI features, the analytics, the team collaboration. It is not in your token refresh logic or your media upload retry code.

When you use PostProxy, you get the plumbing for free. The OAuth is handled. The media transcoding is handled. The platform-specific quirks are handled. You make an API call and the post goes out. Then you build the parts of your product that actually matter.

The open question: composability

What makes Supabase powerful is not just that the primitives exist — it is that they compose predictably. You can build on top of them without being surprised by what is underneath.

PostProxy is built with the same principle. The API behaves consistently across platforms. Errors are structured and actionable. Idempotency keys prevent duplicate posts when retries happen. Webhooks are reliable. Status is always queryable.

The goal is that you can build a publishing layer into your application and then stop thinking about it. The infrastructure does not surprise you. It does not need babysitting. It just works, every time, across every platform you care about.

That is what infrastructure-as-primitives should feel like. Boring, reliable, and completely out of your way.