DEV Community: Jonas Nguyen

An AI that drafts your posts, and code that checks its facts

Jonas Nguyen — Thu, 12 Nov 2026 15:10:29 +0000

The most common complaint about social media for a small business is not "I don't know how to post". It is "I never have anything to post". Autopilot is Clienzo's answer: it drafts the coming week of posts, and the owner approves them.

Every post starts from a source

An AI asked to "write five posts for a nail salon" produces five posts that could belong to any nail salon. So every Autopilot draft has to come from something concrete, and the source is shown next to the draft:

trends from trade press, news and research sites, each with its link — never a competitor's blog;
competitors' best recent posts, used to learn the format that works; their words are never copied;
the business's own profile: offers and prices, hours, promotions with end dates, policies, voice, and a list of things it never says.

The fact check is code

The risk with AI-written posts for a business is not a clumsy sentence. It is a wrong price, an expired promotion, the wrong opening hours. Asking the model to "double-check" does not make that go away.

So after a draft is written, plain code extracts every price, percentage, time, date and "N-day" term from it and checks that each one appears in the business profile. Phrases from the never-say list are blocked too. A draft that fails cannot be approved until it is fixed.

Testing it against real output, the check caught a price that did not exist and an invented "free trial". It also produced false positives — the word "businesses" matched a plan called "Business" — which needed fixing so the check does not cry wolf.

One approval, every network

Approving a draft schedules it to every connected network where it fits, with an image. Nothing goes out without that approval.

What it is not, yet

There is no weekly autopilot running on its own; you start each run. Automatic scheduling would only make sense after weeks of drafts that needed almost no edits — and that trust has to be earned, not assumed.

Autopilot is on the paid plans. Next part: the quieter problems — tokens that expire, and an email outage I did not notice for four days.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

Shipping an MCP server for a small SaaS

Jonas Nguyen — Tue, 10 Nov 2026 15:10:21 +0000

The Model Context Protocol lets an AI assistant call tools in another service. For Clienzo, it means an assistant can look at your connected accounts, create a post, schedule it, check how it did and retry it where it failed — inside the same conversation where you wrote it.

Why bother

People already draft posts with an assistant. The last step — getting that text onto five networks — is exactly the boring part Clienzo exists to remove. An MCP server puts Clienzo where the writing happens.

Few, boring tools

The server has eight tools: list the available networks, list your connected accounts, create a post, list posts, get one post, delete a post, read analytics, and retry a post on the accounts where it failed.

They map closely onto the public API from part 11, with the same permissions behind them. Small tools with plain names are easier for a model to pick correctly than a few clever ones.

Stateless on purpose

Each request is one complete exchange. No sessions, no long-lived connection. Clienzo runs on a platform where the server instance that answered the first call may be gone by the second, so anything kept in memory between calls would be a bug waiting to happen.

When a tool fails — a caption too long for a network, an account that needs reconnecting — the failure comes back as a tool result the model can read and act on, not as a protocol error.

API key first, OAuth second

The first version took an API key in a header. That works for Claude Code, Cursor and anything else where you can set a header — but not for the one-click connectors in hosted assistants. Those need OAuth.

Adding OAuth taught me a few things the spec does not make obvious:

Clients may register in two ways: by pointing at a published metadata document, or by registering dynamically. The first is now preferred; a client only picks it if the server advertises it correctly, and otherwise silently falls back to the second.
Desktop tools redirect back to localhost on a random port, so redirect matching has to ignore the port.
There is no machine-to-machine flow: every connection needs a person to approve it. That is why API keys stay. Nothing approves a consent screen at 3 a.m. for a script.

MCP is available on every plan and does not use up an API key slot.

Next: Autopilot, the first feature that writes posts for you — and checks its own facts.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

Opening a public API for a social scheduler

Jonas Nguyen — Sun, 08 Nov 2026 15:10:19 +0000

The public API was the core of the bet from part 1: anything that can make an HTTP request should be able to schedule a post. Before opening it, I wrote down the ways that could go wrong.

What can go wrong

When people post through the app, a human looks at every post. Through an API, a script does, and scripts fail in specific ways:

a request times out, the script retries, and the post goes out twice;
a bug in a loop schedules the same post hundreds of times;
a test run against production publishes a test post to real followers.

The guardrails

Each of those got its own answer before launch:

API keys with scopes. A key can be limited to what it needs — reading posts, writing posts, reading or replying to comments. Agencies can give each client business its own key.
A rate limit per key, so one runaway script cannot starve everyone else.
Idempotency keys. Send the same key with a retried request, and Clienzo returns the original result instead of creating a second post.
A daily post cap per account, so a loop has a ceiling.
dry_run. Check a post against every selected network's rules — caption length, image count, formats — and get the same validation errors, without publishing anything.

Stronger before wider

Opening an API means more traffic you do not control. So before launch I also moved publishing to its own service, raised the number of posts that can publish at the same moment, and made media streaming the default (all of part 3).

What it covers today

Posts (create, schedule, list, read, delete, retry the failed accounts), media uploads, and the comment inbox — listing, reading, replying and marking comments done. Per-post numbers come back with each post. The documentation lives on clienzo.co.

Old keys do not silently gain new powers: when comment access was added, existing keys did not get the new scopes. You create a new key to use them.

Next: the MCP server, which is the same API, one step closer to where people write.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

One inbox for the comments that come back

Jonas Nguyen — Fri, 06 Nov 2026 15:10:18 +0000

A post is the start of a conversation, and the conversation happens in seven different apps. Clienzo's inbox brings the comments back to one place: Facebook, Instagram, Threads, Bluesky, Mastodon, DEV and Tumblr.

From there you can reply, hide a comment, or mark it done.

Pulled, not pushed

The textbook way to get comments is webhooks: the network calls you when something new arrives. Clienzo pulls instead. It looks at the posts it published in the last 30 days and asks each network for new comments, a limited number of posts at a time, and no more than once a minute per account owner.

Pulling is less instant. But webhooks need each network's app to be live with an extra endpoint and, on some platforms, extra review. Pulling worked with what Clienzo already had, on every network, from day one. Webhooks can come later for direct messages, where speed matters more.

Permissions, again

Reading and replying to comments needs its own permissions on Meta's side — the second review round from part 6. And every reply, hide or status change checks twice that both the comment and the connected account belong to the person asking.

AI suggestions that missed the point

The inbox can suggest replies. The first version was not good. On a real thread, the suggestions were off-topic, and looking into it I found the model was set up to fail:

it saw only the first 280 characters of the original post,
earlier messages from the person replying were labelled "Someone", so the model lost track of who said what,
it kept offering to "send a DM" even when the business had already offered that,
and it knew nothing about the business it was speaking for.

The fix was not a different model. It was better context: the full post, clear roles ("Them", "You"), @mentions stripped, guidance per network, and a short profile the owner writes once — what the business does, its voice, facts it can rely on, and things it should never say. If that profile is empty, Clienzo falls back to the bios of the connected accounts.

Suggestions are suggestions. Nothing is sent until you press Reply.

Next: the public API, and the guardrails I added before opening it.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

Chat apps are channels too

Jonas Nguyen — Wed, 04 Nov 2026 15:10:18 +0000

When I looked at where small products actually talk to their users, a lot of it was not on the classic social networks. It was in a Discord server, a Telegram channel, a Slack community.

So Clienzo treats those as channels, with the same composer, schedule and per-channel result as Facebook or LinkedIn.

How each one connects

Each chat app has a different idea of what "connecting an app" means:

Discord: you paste a webhook URL from the channel's Integrations settings. No login, no review. Up to 2,000 characters and 10 files per message.
Telegram: you add the Clienzo bot to your channel or group, then post the short code Clienzo shows you. That proves you control the channel before anything gets linked to your account.
Slack: a normal sign-in, then you pick the channel.
Viber: you paste the token from the channel's developer tools.

None of them needed a platform review, which is a large part of why they shipped quickly.

Alerts in the same place

In Discord, Telegram or Slack, Clienzo can also tell you things: a post published, partly published or failed, or an account that needs reconnecting. You pick which events. For a small team that already lives in Discord or Slack, that beats another email.

Why not Microsoft Teams

Teams was on the first list and came off it. It is built around enterprise tenants and admin approval, which is the opposite of the people Clienzo is for: founders and small teams who decide for themselves.

What I cannot measure here

The trade-off: chat apps do not report views or reactions to an app for each message. Those channels show a blank in analytics, as described in part 5. You find out how a post did by being in the conversation — which, for these channels, is the point.

Next: one inbox for the comments coming back.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

Small networks, big quirks

Jonas Nguyen — Mon, 02 Nov 2026 15:10:06 +0000

The big platforms have big review processes. The smaller ones have smaller surprises — the kind you only find with a real account and a real post.

Pinterest: pins nobody else could see

Pinterest gives a new app trial access first. With it, everything works: you connect, you create a pin, the API says success. But the pin is a sandbox object only its author can see.

Clienzo marked Pinterest "in review" until Standard access was approved in October. On the same day I found that Pinterest tokens last 30 days and nothing was refreshing them, so older connections had quietly died. That got fixed alongside, together with per-pin analytics.

Dribbble: uploaded, and invisible

Dribbble's API took the upload without complaint, and the shot did not appear anywhere. The reason was on the account: Dribbble hides the shots of a regular account until it is approved as a Designer account.

Clienzo now explains this before you connect, warns on the post's result, and labels such connections "Not public".

Two more Dribbble details. The docs say the API accepts 400×300 or 800×600 images; a test showed it takes 1600×1200 too, which is what most shots use, so Clienzo sends that first. And the title — taken from the first line of the caption — cannot be longer than 64 characters, which I found through a real rejected post.

Tumblr: one limit for everyone

A new Tumblr app gets 1,000 API calls an hour and 5,000 a day — shared across every customer of the app, not per user. Most of those calls go to reading comments for the inbox, not to posting.

Clienzo treats a rate-limit error from Tumblr as its own limit, not the customer's, and alerts me when the remaining quota runs low. Getting the limit raised is a conversation with Tumblr that is still going.

Viber: rules about files

Viber channels accept pictures only as JPEGs under 1 MB, one per message. So Clienzo re-encodes each picture and stores a copy that meets those rules before sending it.

The pattern

None of these were in a "getting started" guide. Each one showed up the first time a real post went to a real account. That is now a rule for me: a network is not "live" on the website until a real post has gone through it.

Next: chat apps, and why Discord and Telegram are channels in Clienzo.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

YouTube: passing OAuth verification is not the end

Jonas Nguyen — Sat, 31 Oct 2026 15:10:23 +0000

YouTube was the network where I learned the difference between "approved" and "done".

Check one: OAuth verification

To let other people connect their YouTube channel, Clienzo asks for two scopes: one to upload videos and one to read basic channel and video data. Both are classed as sensitive, which means Google verifies the app before strangers can use it.

That review wanted:

a demo video showing exactly how each scope is used,
a test account the reviewers could sign in with, working without a paid plan,
a privacy policy that matches what the app actually does.

The last one is easy to get wrong. My first policy did not mention that Clienzo reads video statistics, even though the analytics do exactly that. A mismatch between the policy and the API calls is a common reason for rejection, so I rewrote that section before submitting.

There was a round of follow-up questions, and the verification completed.

Check two: the API audit

Here is the part most people miss. Passing OAuth verification does not let you publish public videos.

Any API project created after July 2020 has every upload locked to private, whatever privacy setting the app sends, until it passes a separate YouTube API compliance audit. The form for it is titled "Audit and Quota Extension", which makes it sound optional. It is not.

Because of this, Clienzo's YouTube publisher reads back the privacy status YouTube actually applied after each upload. If the video was forced to private, the post's result says so — instead of reporting "published" for a video nobody can see.

Where it stands

The audit was approved in September and the OAuth review completed in October. Nothing is pending on the Google side now.

The lesson

Read the platform's docs for the word "audit" before you plan a launch date. With most platforms, being allowed to connect and being allowed to publish publicly are separate approvals.

Next: the smaller networks, where the quirks were stranger.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

The Meta App Review trap: every permission approved, login still broken

Jonas Nguyen — Thu, 29 Oct 2026 15:10:22 +0000

To post to Facebook Pages, Instagram and Threads on someone else's behalf, an app needs Meta to approve each permission through App Review: you describe the use, record a screencast of it, and wait.

Clienzo went through that and passed. Then it did not work.

The symptom

Accounts with a role on the app — me — could connect Facebook fine. Everyone else saw Meta's login dialog say that Facebook Login was "currently unavailable for this app, since we are updating additional details for this app."

That message points you towards business verification, data protection forms, app settings. I checked all of them. None of it was the problem.

The cause

The login dialog itself needs Advanced Access to public_profile. Without it, Meta does not degrade gracefully — it blocks the whole dialog for anyone who is not on the app's team.

The part that cost the most time: asking Meta's API for the app's permissions reported public_profile as live the entire time. That field does not tell Standard Access and Advanced Access apart. The only reliable place to check is the Advanced Access column in the App Review section of the dashboard.

After requesting Advanced Access, Facebook, Instagram and Threads worked for every customer.

Two apps, two reviews

Threads is its own app on Meta's side, so it has its own review. And when Clienzo later added a comment inbox and post insights, those permissions needed a second round of review — again split across the two apps.

One more trap from that round: for a Business Login app, some permissions are declared in the Meta dashboard's login configuration, not in code. Changing the code does nothing for those. Others — Threads, and Instagram's own login — are the opposite. I wrote down which is which, because I will not remember next time.

What I would tell myself

If login fails only for people without a role, check Advanced Access for public_profile first.
Do not trust status: live as proof of Advanced Access.
Record the screencast as you build the feature, not the night before you submit.

Both review rounds are approved now. Next: Google, where passing verification turned out not to be the end either.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

Analytics that leave a blank instead of guessing

Jonas Nguyen — Tue, 27 Oct 2026 15:10:09 +0000

The fastest way to lose someone's trust in an analytics page is to show them a number that is not real. So Clienzo's analytics follow one rule: if a network does not report it, the cell is blank, and Clienzo says why.

Not every network reports

Of the sixteen networks Clienzo posts to, a good number simply do not give an app per-post numbers:

Discord webhooks, Slack, Telegram channels and Viber channels do not report views or reactions per message.
Dribbble's API does not report views or likes on a shot.
Dailymotion retired per-video view counts from its API this year.
LinkedIn reports them only through a separate API that needs its own approval.

The networks that do report — Facebook, Instagram, Threads, YouTube, Pinterest, Bluesky, Mastodon, DEV and Tumblr — each report a different mix of views, likes, comments and shares. The table on Clienzo's site lists exactly which.

What I decided not to show

Two popular numbers are missing on purpose: engagement rate and reach. Both need a denominator — followers, impressions — that most networks do not hand to an app for each post. Computing them anyway would mean inventing the denominator.

The bug that ate two thirds of the data

Clienzo measures each post three times: an hour after publishing, after a day, and after a week. For a while the job overwrote the result each time. The one-hour and one-day numbers were measured, saved, and then replaced by the next pass — gone for good, because no network will tell you what a post's numbers were yesterday.

Now every pass is kept separately. That made a new number possible: how much of a post's engagement arrived in its first hour. It only shows once a post has been measured past that first hour; before that, the first hour is the total and the share would always read 100%.

What came after

With history kept, the page could grow up: comparison with the previous period, results per account instead of only per network, a day-and-hour view of when posts do best, and cuts by content type — image, video, text, caption length, with or without a link. The heatmap needs a fair number of measured posts before it means anything; with three posts it is noise.

Next: the review process that decided when Facebook, Instagram and Threads could launch.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

When a post goes out on five networks and fails on the sixth

Jonas Nguyen — Sun, 25 Oct 2026 15:10:13 +0000

When you post to six networks at once, "it worked" and "it failed" are the rare cases. The common one is: it worked on five, and one network said no.

Maybe a token expired. Maybe the caption was too long for that one network. Maybe the network was having a bad minute.

The problem: it looked like success

In early versions of Clienzo, such a post was marked Published, because most of it was. The one failure sat inside it, visible only if you opened that post. People did not open it. Why would they? It said Published.

Making partial failure visible

So a post that did not go out everywhere now gets flagged as needing attention:

it appears in the Failed tab, even though part of it was published,
the Posts menu shows a badge until you deal with it,
you get an email (at most one every 15 minutes, so a bad hour does not flood your inbox),
and the banner says it plainly: this post did not go out everywhere.

Once you have looked at it, Mark as handled clears it.

Retry only what failed

The obvious fix — "post it again" — is wrong, because it would post again on the five networks that already worked.

Clienzo offers two options instead:

Retry failed sends the same post again to only the failed accounts. It works because publishing already skips networks with a successful result.
Edit & post failed makes a new draft containing only the failed accounts, for when the content itself was the problem — say, a caption too long for one network.

One trap I nearly shipped: after a retry, the publish step re-created the analytics record for every account, which would have reset the numbers already measured for the five that went out first. Now it only creates records that do not exist yet.

Why there is no automatic retry

It is tempting to retry automatically. I decided not to. If a network times out but actually accepted the post, an automatic retry posts it twice — on your account, in public. A human pressing Retry after looking is slower, and much safer.

The one exception is a specific error from Threads that turned out to be temporary; that one is retried three times, a few seconds apart.

Next: analytics, and why Clienzo shows blanks instead of estimates.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

Publishing at the right minute, with nothing running in between

Jonas Nguyen — Fri, 23 Oct 2026 15:10:22 +0000

A scheduler can get a lot of things slightly wrong and survive. Publishing late is not one of them.

The first version: a cron job

The simplest design is a job that wakes up every minute, finds posts that are due, and publishes them. It works, and Clienzo started there.

Its weaknesses show up with scale. Every minute it asks "is anything due?", mostly to hear "no". When many posts are due at once — 9:00 on a Monday is popular — one run has to work through all of them, and the last one goes out late.

One task per post

Today, when you schedule a post, Clienzo creates a queued task for that one post, set to fire at that exact time. The queue (Google Cloud Tasks) wakes the server only when there is something to do, and posts due at the same minute run side by side instead of in a line.

Publishing runs on its own service, separate from the API the app talks to, so a burst of publishing never slows down the app.

Why the cron job is still there

I kept the cron job, now as a safety net. It covers what a queue cannot:

posts scheduled further ahead than the queue accepts,
posts written straight into the database by scripts,
a task that failed to be created,
a publish that crashed halfway and needs to be picked up again.

Two mechanisms for one job sounds wasteful. In practice it means a missed task costs minutes, not a missed post.

Never post twice

The dangerous failure for a scheduler is not missing a post. It is posting it twice. So publishing is written to be safe to repeat: before sending a post to a network, the job checks whether that network already has a successful result, and skips it if so.

Stream, don't buffer

Videos were the other problem. The first publishers loaded each file into memory before uploading it, which is fine for a photo and not fine for a long video on a small server.

The publishers now stream media from storage to the network as it is read. In a test with a 600 MB file, memory stayed flat at roughly 80 MB above normal. That test also caught a subtle bug — a download being cancelled because nothing held a reference to it any more — which is exactly why it was worth writing.

Next: what happens when a post goes out on five networks and fails on the sixth.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.

One composer, sixteen networks: every network has its own rules

Jonas Nguyen — Wed, 21 Oct 2026 19:54:49 +0000

The pitch of every scheduler is "write once, post everywhere". Building one, I learned it really means "write once, then satisfy sixteen different rulebooks".

What the rulebooks look like

A few real examples from Clienzo's networks:

Telegram cuts a photo caption at 1,024 characters, while a plain text message can run to 4,096.
Discord messages stop at 2,000 characters, with up to 10 files.
Bluesky and Mastodon take up to four photos, or one video.
Dribbble takes exactly one image per shot, at a 4:3 size, and the title — which Clienzo takes from the first line of your caption — has a 64-character limit. I found that limit the honest way: a real post came back with an error.
Viber channels want each picture as a JPEG under 1 MB, one picture per message.
YouTube and Dailymotion take a video, and need a title too.

None of this is unusual. It is just different everywhere, and it changes.

Rules live in one place

The first decision was to keep all of those limits in one shared set of post rules, used by the composer in the app, by the public API and by the publishing job. If the composer lets you schedule a post, the API would have accepted it too, and the publisher will not be surprised by it at 3 a.m.

When a network's rule changes, it changes in one file.

Fix it for the network, not for the user

Some rules can be satisfied without asking you. Clienzo resizes an image to fit Dribbble's 4:3 frame, re-encodes a picture as a JPEG for Viber, and turns hashtags into tags where a network has tags instead.

Others cannot be guessed: a caption that is too long for one network needs a human to shorten it. Those show up as a clear warning on that network only, before you schedule.

The preview matters more than anything clever

The feature I would keep if I had to drop everything else is the preview per network. It shows the post the way each network will get it: where the caption gets cut, how many images make it, and a note where links in captions are not clickable, as on Instagram and YouTube.

It is not glamorous. It is the thing that stops a post from going out wrong.

Next: what happens after you press Schedule, and how a post gets published at the right minute.

Originally published on jonasnguyen.com, where I write about building Clienzo and the next startups.