Rubinyun
Instagram and Facebook scheduler for n8n, Make, and code
I automate content for my own brands, and publishing was the step that kept breaking.
Two things you find out the hard way:
The Instagram Graph API has no scheduling. There is no "post this at 6pm on Thursday". Something has to be awake at 6pm and make the call itself.
The Instagram node in n8n is a trigger. It listens for events, it does not publish.
So the workflows I built all ended at a machine I had to leave running, which is most of the reason I was automating in the first place.
Rubinyun does that last part. It takes the post, works out the hour from the engagement of your own recent posts instead of a generic best-time chart, and publishes it from a server. There is a free plan with the API included.
The pricing decision I would make again: it counts published posts, not connected profiles. Almost everyone bills per connected profile, so ten client accounts posting twice a month cost ten times one account posting daily. I had exactly those accounts, and the maths never worked.
If you are wiring up the Graph API yourself, the container flow and the way stories behave differently from everything else are where I lost the most time.
13 Comments
The pricing angle is probably the most interesting part here.
What would convince you that "pay per published post" is the differentiator customers care about, rather than just a nicer pricing structure for a workflow they already have?
Nothing so far. It went on sale on 11 July and I don't have the data to claim it.
What would convince me is a specific kind of customer: someone with eight or ten accounts that each post a few times a month. On per-channel pricing they pay for ten connections and barely use them, so the metric would be the whole reason they moved. If instead the people signing up are single-account users posting every day, then you're right: it's a pricing structure, and what brought them in was something else.
Those two groups are easy to tell apart, so I'll know either way within a few months.
I appreciate you taking the time to explain your thinking.
I'd be interested in continuing the conversation by email if you're open to it. What's the best email to reach you on?
Sure, it's in the footer of my site. For product questions the public thread is worth more though: it stays there for whoever is looking for the same thing.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
“Nice niche with n8n/Make users. Curious — is this solving scheduling alone, or becoming part of a bigger automation stack?”
For now that's what it does. You call it from n8n, or straight from the API from anything that can make an HTTP request, or you use it from the panel on the site with no automation around it at all.
I'm not ruling anything out for the future: other social platforms, hooking it to other products that need a scheduler, or making it callable straight from a chatbot, as a tool you ask to publish something.
What I add usually starts from something I need for my own work, so I'm the first one actually using it. And then from what the people using it ask for: if someone brings me a case I hadn't thought of, that one goes to the front of the queue.
Building from your own workflow is usually how the best tools start.
The interesting inflection point will be when it shifts from ‘a tool you use’ to ‘a system others rely on’ — those tend to have very different feature priorities.
Have you had any external users push you in a direction you wouldn’t have taken yourself yet?
Honestly, not yet: sales started a few weeks ago, so the direction so far has come from my own use. But the shift you describe has already left its mark on the design. API errors come back in English with a stable code, so someone else's workflow can branch on the code instead of parsing text. And API keys are per channel, so an agency can hand each client its own key without exposing the whole account.
Those choices were made for the people who will build on it, before anyone asked for them.
The interesting shift I’ve seen at this stage is that the first external users don’t just validate what you built — they expose which parts of it are actually “mission-critical” vs just well-designed.
Especially with agencies, the moment something touches client work, reliability and predictability tend to matter more than flexibility.
Curious — are your early users mostly integrating this into existing workflows, or using it more as a standalone tool for now?
Happy to take a look at how you’re positioning this to those first users if useful — this feels like one of those products where the right framing early can pull in much higher-value customers.
Too early to tell from the numbers: as I said above, the direction so far has come from my own use. What I can say is which way the project leans: the workflow route is where most of the work went (the API, the stable error codes, the n8n template), while the panel on the site exists because publishing has to work even with no automation around it. Which of the two real customers use more is something real customers will tell me.
If you want to see it with your own eyes, there's a free plan with the API included: you can try it without a card and without talking to anyone.
Agreed on early. And that split is the one thing I can read without asking anyone: an API key that gets created and then actually used leaves a different trail from a post queued in the console. What I'm not doing yet is calling the winner in advance, because with these numbers that would be a guess wearing the clothes of a decision.