DEV Community: Anton Rost

I spend more time rejecting X posts than writing replies

Anton Rost — Fri, 09 Oct 2026 19:35:22 +0000

A pricing conversation, my X analytics and how I decide which posts to answer.

AI-generated editorial illustration. Selecting a conversation comes before writing a reply.

On 5 October, Vincenzo Nudo asked a question on X that most software customers could answer: would you rather pay monthly, yearly or once? I had a preference, but it wasn’t quite a vote for one of the three. I’ll pay monthly while I’m finding out whether I use an app enough to keep it. A year starts to make sense once I’m relying on it.

I’m building Sendezeit, a publishing app, so I also read questions like his as someone trying to find customers. X gives me a place to talk about my work and meet other builders, which makes a conversation about software pricing relevant to me. It doesn’t make that conversation a request to hear about my app.

That distinction matters when I sit down to reply. I want people to discover what I’m building, yet the person whose post I’ve opened usually has something else in mind. Before I can decide what to write, I need to understand what they’re asking and whether I have an answer they might actually want to read. Vincenzo’s question gave me a way in because I could explain my choice as a customer.

The answer left room for a conversation

My reply was short enough that there was no need to dress it up:

“monthly while im figuring out if i actually use it. id only go yearly once its part of my routine”

Vincenzo’s pricing question and my reply on 5 October 2026. Screenshot captured on 9 October.

Vincenzo called monthly a paid trial and yearly the prize for tools that survived. His response picked up on the hesitation behind my choice: I can like an app before I know whether I’ll still be using it in a few months. We had moved from choosing a payment option to talking about what would make a longer commitment reasonable, without either of us needing to prescribe a pricing strategy.

A link to Sendezeit wouldn’t have helped explain that hesitation. He hadn’t asked for a publishing tool, and adding one would have given him a different conversation to deal with. I could still be visible as a founder by answering his question. Anyone curious about me could choose to open my profile.

That is something I want from replying on X, although my analytics can only tell me so much about whether it happens. On 9 October, the four-week view showed 93.8K impressions and 573 profile visits, with 933 followers on the account. Those are account-wide figures covering my posts and replies together. They don’t identify which conversation brought a visit, and 933 is the follower total at capture, not the number gained during those four weeks.

My four-week X Analytics, 12 September–9 October 2026. The account had 933 followers when I captured this screen.

The report gives me a reason to pay attention to what I’m doing on the account, but it can’t turn that pricing exchange into a growth case study. For that, I’d need evidence connecting the reply to what happened afterwards. What the exchange does show is a question I could answer honestly and a response that continued the thought. I can look for those qualities again without promising myself another profile visit.

Finding the next question takes more reading

To find another conversation like it, I start with my timeline, saved lists and notifications. They put posts in front of me, but they also show fragments of discussions already underway. If someone in a list has replied to an older post, I need to open that parent before I can tell what their sentence means. Otherwise I’m answering a line that has been separated from the question that produced it.

Reading the parent can change what I was about to say. A suggestion may already have been tried, a quoted post may explain the disagreement, or another reply may have covered my point. I also check whether I’ve answered the person myself. When our exchange has reached “yeah, fair enough”, seeing it again in the feed isn’t a reason to restart it.

Since this reading can easily fill a session, I narrow the scan to recent conversations: up to 24 minutes old on my regular timeline and often an hour in my saved lists. Those are working limits for my routine, not timings I’ve proved produce better growth. I use exact timestamps rather than rounded labels, and measure a reply’s age separately from its parent. A new answer to yesterday’s post can still be a current conversation.

Within that smaller set, I’m looking for a connection I can explain. In Vincenzo’s post, it was the difference between trying an app and depending on it. In a discussion about a product change, I might have a question about how customers responded, provided the thread hasn’t already answered it. That gives the reply something specific to do instead of merely announcing that I agree.

I read the draft beside the source before sending, because a pleasant sentence can still be irrelevant. If I could paste it under ten unrelated posts, I need to go back to what this person said. Sometimes that produces a better answer, and sometimes it confirms that I don’t have one. Leaving those posts alone keeps me from inventing an experience or manufacturing a question just to take up space.

What I brought into Sendezeit

By then, I’ve spent time finding and reading a conversation before writing anything. I wanted Sendezeit to help with that search while leaving the decision to join it with me. Reply Finder lets you request a scan around topics, selected accounts or your connected account’s chronological Following timeline. It returns recent original posts with their age, ranking and a reason they matched, so you have a smaller set to read.

If you want help with wording, you can request an AI draft and edit it before returning to X to review and send. A scan runs when you ask for it. The feature doesn’t keep polling in the background or send replies automatically. It also finds original posts only, whereas my manual list scans sometimes lead me to people’s replies inside threads. I wouldn’t describe those as the same workflow or use my account analytics as a performance test of the feature.

That’s the help I want from an AI social media tool: fewer posts to sift through, with enough context to decide which ones deserve a closer look. You can do this manually, too, by starting with a subject you know and reading the exchange before drafting. Reply Finder in Sendezeit offers the on-demand scan, and the X Reply Timing Checker can help check the age of a single post.

Neither changes what made Vincenzo’s question worth answering. I had a preference and could explain when it would change. My product didn’t need to come with me into that conversation, even though finding people who might care about it was one reason I’d opened X.

Thanks for reading.

Social media API approval: OAuth, review, and publishing

Anton Rost — Sun, 04 Oct 2026 12:22:58 +0000

A practical guide to separating account access, provider review, media processing, and the result your user actually receives.

Google OAuth verification and Meta app review were in different states on 27 September 2026. Neither screen establishes YouTube API audit approval or a successful public post. Screenshots by Anton Rost.

A connected account is the beginning of a publishing job, not evidence that the job can be completed. The callback may succeed while the application still lacks provider approval, the selected destination lacks a capability, or an uploaded video remains private.

While building Sendezeit, I realised that “ready” could mean three different things: an account was connected, the app had provider approval, or a post was actually live. I needed to stop treating those as the same milestone. A more useful approach was to follow the work from authorization to the result the user actually receives, checking what each stage proves before moving to the next.

The phrase social media approval workflow sometimes describes teammates signing off on content. Here it means the provider-side authorization and review needed to deliver that content; it is not a description of a team-approval feature in Sendezeit.

The checks below follow the publishing job in order. They start with the connection, then move through the destination, submission, unfinished provider work, and the evidence needed to describe a result honestly.

1. A reliable publishing path starts with the connection

Before checking a post, make the authorization path unambiguous. The public application URL is where the user works, the OAuth redirect URI receives the browser after consent, and a webhook endpoint receives later provider events without that browser session. These addresses serve different purposes.

Register the production redirect accurately rather than assuming that a development callback, alternate hostname, or different path will be accepted. The OAuth security best-current-practice document calls for exact redirect matching, with a specific exception for localhost ports in native applications. It also addresses PKCE and protection against authorization-code attacks. RFC 9700.

Tie the authorization flow to an expiring server-side record containing the provider, initiating user, and allowed return path. Validate the callback against that record and prevent reuse. Apply the provider's documented PKCE requirements rather than copying one adapter's parameters into every other adapter.

For example, X's OAuth 2.0 authorization-code flow uses PKCE, and its offline.access scope enables refresh-token access. A connection that works now does not by itself establish that the application can keep working after the access token expires. X authorization documentation.

Keep token exchange and confidential client credentials on the server, protect stored tokens, and keep them out of logs. Test expiry, revocation, and disconnection alongside the successful path. Once access is established, the next check is where that access can actually be used.

2. Access must lead to a specific destination and capability

The person granting consent may manage several Pages or channels. Discover the destinations permitted by the grant and make the selected destination visible before submission. Otherwise, a successful connection can hide uncertainty about where the post will go.

Record the stable provider identifier, relevant granted permissions, and capability restrictions for that destination. Test the account type and login route you intend to support: one working professional account is not evidence of support for every account type.

A connection screen should therefore answer both “Which account is this?” and “What can the application do with it?” Leaving the second question unanswered pushes the discovery of restrictions into the publishing flow, after the user has already prepared their content.

With a destination and usable capability identified, the application can record a publishing attempt without confusing that attempt with its eventual result.

3. Submission records the attempt, not necessarily publication

Create the local attempt before making the external write. Link it to the reviewed content version, destination, media, and requested visibility, then retain the provider's response and identifiers when they arrive. This gives later status checks a specific job to reconcile.

In the Sendezeit code checked for this article, a submission returns accepted or published. Subsequent provider checks use processing, published, needs_action, or failed. The content lifecycle is a separate layer, with states such as scheduled and publishing.

Those names are implementation labels, not interchangeable proofs. An identifier may establish that a provider knows about the job without establishing that an ordinary viewer can see the content. The YouTube adapter's processing-complete result, in particular, is not an independent public-visibility check.

Keep requested visibility, reported provider status, and verified audience access as separate observations. Public, unlisted, and private are not one successful-upload category: an unlisted video can be accessible by link without being publicly discoverable. The next step is to determine what remains unfinished for the particular provider.

4. The remaining work depends on the provider and mode

TikTok's Upload Content flow makes this visible through SEND_TO_USER_INBOX. That status leaves the creator with a native step to complete; PUBLISH_COMPLETE is a later outcome. Publicly available post identifiers also depend on the documented public-viewership and moderation conditions. TikTok status reference.

An inbox handoff should not silently replace direct publishing because the two modes leave the user with different work. Provider approval matters here too: unaudited TikTok Direct Post clients are restricted to private viewing. Implementing the adapter does not remove that restriction. TikTok Direct Post setup.

The capture below establishes an earlier stage, not either completed outcome. It shows an unconnected preview and a disabled draft button. Its caption needs to respect that boundary just as the product's status message does.

This 27 September capture shows an unconnected preview with a disabled draft button, not a delivered draft. Screenshots by Anton Rost.

YouTube has a different sequence. The upload response may arrive before video processing finishes, so processing status must be checked separately. YouTube video implementation guide.

Google OAuth verification also differs from the YouTube API compliance audit. YouTube documents private-viewing restrictions for uploads from unverified API projects created after 28 July 2020, with an audit required to lift them. The verified consent-screen capture at the start of this article is not evidence that this audit passed. YouTube upload reference.

These intermediate stages make a missing response especially important to handle carefully. The absence of a result in the application is not always evidence that the provider did nothing.

5. An uncertain outcome needs reconciliation before a retry

A timeout can leave the provider's write completed while the application lacks its response. Repeating every failed-looking request risks creating duplicate posts, so preserve the uncertain attempt instead of immediately treating it as a failed publication.

Use a stable local attempt identity, without assuming that every provider honours a client-supplied idempotency key. Reconcile through the documented status endpoint, returned identifiers, or destination checks before deciding whether another write is safe.

Webhooks and polling can provide overlapping evidence about the same attempt. Follow the provider's signature, event, and replay rules rather than applying a universal signature recipe. Processing the same evidence twice should not create another publication or count another success.

If reconciliation is impossible, explain the uncertainty and offer a controlled next step. “Needs checking” is more useful than a confident success badge attached to a possible duplicate. Once individual attempts can be tracked this way, the release decision still needs a broader check: whether the path is available to the customers who will use it.

6. A founder's successful test is not the release decision

A provider may allow a founder or administrator to do something an ordinary external account cannot. Working code and a successful test therefore need to sit alongside production configuration, provider approval, and account-specific evidence.

The September captures show different dashboard states, not a completed availability audit. I use these five questions to keep that distinction visible:

Question	Evidence to retain
Is the adapter implemented?	The supported path in code and its tests.
Is production configured?	The correct app identity, redirect, scopes, and mode.
Is required access approved?	The provider's approval or audit record for that capability.
Can an ordinary external account use it?	A dated test outside the founder/admin role.
Did the intended result happen?	Provider status, actual visibility, destination, and result identifier or URL.

This is a checklist, not a claim that every Sendezeit destination passes all five checks. Name the account type, requested mode, observed result, and date in the release record. That prevents an old administrator test from becoming a broad promise about current customer access.

Prepare the reviewer journey from the real product: a stable entry point, reproducible credentials where requested, reasons for each permission, and a recording of the supported path. Privacy, retention, disconnection, and deletion information should match the application.

A release record built around these checks gives the interface a sounder basis for its final message. It can describe the stage reached without borrowing certainty from an earlier milestone.

7. Tell the user which part of the job actually finished

Before showing success, check the destination and content version, processing status, actual visibility, and any remaining native step. Retain the result identifier or URL where available, together with the verification time. A URL alone is not a visibility test.

If authorization is all that completed, say connected. If the provider accepted an upload, say accepted or processing. If the creator must finish in the native app, make that step explicit. Reserve a public-access claim for evidence of public access.

Following the job in this order prevents the earliest green checkmark from standing in for the last. A social publishing platform should save the user from decoding several provider dashboards without hiding the differences between them.

I am building Sendezeit around that separation. This guide describes the implementation and review approach, not a guarantee that every provider is approved for every account or publishing mode.

Implementation checked and linked documentation reviewed on 3 October 2026. Screenshots record 27 September 2026; provider requirements and account access can change.

I Had Plenty of Content Ideas and Almost Nothing Published

Anton Rost — Tue, 29 Sep 2026 08:51:18 +0000

I made separate Instagram and YouTube upload documents for the same Pocket Orbit videos.

They were supposed to stay in sync, which sounds perfectly reasonable until two files have had a few months to develop independent lives.

When I opened them again, the lists no longer matched. The Instagram document contained entries the YouTube one did not, and one of its rows still carried a YouTube tracking link. The calendar held yet another version of the week, although a row could mean planned, drafted, scheduled, attempted, or actually public depending on when I last remembered to update it.

One source library. Two upload documents. Several answers to what existed.

The same source library ended up with two separate upload playbooks.

Screenshots: Anton Rost. Source: original Pocket Orbit upload playbooks opened in Obsidian, 20 September 2026.

I blamed the documents first. Then I followed one post through the rest of the workflow and found the same drift in the calendar, the exports, and the upload state.

I could decide what to make. Getting the right version all the way to a public URL still depended on my memory.

I kept fixing the research because it was easier

The research system was genuinely useful. It started with phrases people were already searching around iPad notes, Apple Pencil workflows, lecture notes, handwriting, organisation, summaries, exports, and study methods.

I kept a knowledge base behind those phrases because I did not want a search term to turn straight into a confident answer I could not support. A query could be popular and still need better evidence, fall outside Pocket Orbit, or require review from somebody who actually spoke the language.

By then, the registry had grown into hundreds of search queries. A much smaller set had enough evidence to move into production.

Ready still only meant I could start making the thing.

So I kept returning to the registry. Cleaning another row felt manageable. Finishing, adapting, and publishing the work attached to it did not.

Then I counted the finished work

There were three completed carousels.

Each one had five slides: a hook based on the search query, three useful answer slides, and one action at the end. Pocket Orbit could appear once when it genuinely helped with the answer.

Those fifteen finished slides still required visual research, copy, real product screens, claim checks, layout, exports, and upload preparation.

Clearing the research check only put a topic at the start of production. It still needed a script, visuals, exports, and a version for each platform.

The registry kept growing. The smaller grid on the right is what actually made it live.

Screenshots: Anton Rost. Sources: Pocket Orbit query production registry in Obsidian and @antonships.app on TikTok, 20 September 2026.

Every file remembered a different version

One recording could become a TikTok edit, an Instagram caption, a YouTube title and description, sometimes a Facebook version, and a few notes about what I wanted to change later.

Updating one version did not update the others. Moving a date in the calendar did not prove the file was ready. A successful upload did not necessarily mean somebody else could see the post.

Planned, scheduled, attempted, and public were quietly becoming the same state.

The calendar looked organised because Tuesday had a row. It still could not tell me what had actually happened.

I was reusing the wrong thing

I had treated the final caption as the reusable unit. It should have been the real source underneath it.

That source might be a Pocket Orbit feature, a TikTok result, a paywall failure, or something I noticed while building after work. The event and its evidence should remain stable while the presentation changes for each destination.

On X, I can explain the reasoning. On TikTok, the useful visual has to arrive almost immediately. Instagram may use similar footage but still needs its own framing. YouTube needs another title, description, thumbnail, and link setup.

Copying one finished caption into every box was quick, but it flattened the idea into a version that fit nowhere particularly well.

The workflow I needed was simple enough to explain:

One real source
Versions for each platform
Review
Schedule
Check what really went live

I was still the only thing keeping those pieces connected.

That became Sendezeit

Sendezeit starts with something that actually happened, then keeps the destination versions, edits, approvals, calendar entries, and provider results attached to that source.

It does not fix the Pocket Orbit paywall or explain why somebody watched a TikTok and did not subscribe. Those questions still belong in the product, RevenueCat, and the analytics.

Sendezeit cuts out that weekly scavenger hunt. One source sits beside its X, TikTok, and YouTube versions. Each one keeps its own copy, media, review, schedule, and final publication result. I no longer have to remember which draft was final, reopen every platform to check it, or compare a calendar with a folder full of exports.

The replacement: one source, separate destination drafts, and the publishing state kept together.

Screenshot: Anton Rost. Source: live Sendezeit workspace, 20 September 2026.

You can run the same method in a spreadsheet: keep one source, write each platform version separately, review it, and record the public result beside the plan. I built Sendezeit because I was tired of maintaining those joins myself.

I had spent most of my time improving research because it was easy to organise. Meanwhile, I kept losing time at the other end, working out which version went where and whether it really went live. That gave me one clear requirement for the product: keep a reliable record of what I published.

Sendezeit is live now. X and YouTube have passed real-connection and provider-confirmed publishing checks. TikTok uses Direct Post when the account is eligible or an explicit draft handoff when it is not. Instagram and Facebook stay labelled coming soon while Meta review finishes.