The latest articles on DEV Community by David Anyatonwu (@odogwu). https://dev.to/odogwu https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4044439%2F4f380b41-ac16-405e-9fc5-ef238ae1f377.png https://dev.to/odogwu en David Anyatonwu Mon, 27 Jul 2026 18:47:17 +0000 https://dev.to/odogwu/launching-beacon-durable-social-publishing-you-can-trust-2eh9 https://dev.to/odogwu/launching-beacon-durable-social-publishing-you-can-trust-2eh9 <p>Beacon is a social publishing workspace for individuals, teams, and agencies that need more than a simple “send post” button.</p> <p>Its purpose is straightforward:</p> <blockquote> <p>Plan a post one time, publish with confidence, and keep each accepted delivery visible.</p> </blockquote> <p>That promise matters because social publishing is not a clean, predictable operation. Providers can reject requests, delay responses, or accept a post without returning usable publication evidence. Credentials can expire. Connections can fail after a provider has already published. If software responds by retrying blindly, the same content may be published twice.</p> <p>Beacon is built around those realities.</p> <h2> Why Beacon is necessary </h2> <p>Most publishing tools optimize for the happy path:</p> <ol> <li>Write a post.</li> <li>Select a destination.</li> <li>Choose a publication time.</li> <li>Send it.</li> </ol> <p>The difficult part starts after that sequence. Every accepted post target must remain visible and recoverable when an external provider becomes slow, unavailable, or uncertain.</p> <p>Beacon does not assume it controls a provider’s availability. Instead, it records durable evidence for each post target and handles uncertainty conservatively.</p> <p>The publishing foundation follows several trust-preserving rules:</p> <ul> <li>PostgreSQL application tables are the source of truth.</li> <li> <code>pg-workflows</code> controls durable waits, recurrence, approvals, and outage recovery.</li> <li> <code>pg-boss</code> controls bounded provider activities, concurrency, repair, and reconciliation.</li> <li>Provider adapters normalize limits, errors, and publication evidence.</li> <li>Beacon does not automatically repeat an uncertain external create operation.</li> </ul> <p>That final rule is especially important. Suppose a provider receives a create request, publishes the post, and then the connection fails before Beacon receives a usable response. Automatically sending the request again might create a duplicate. Beacon preserves the uncertain result for reconciliation instead of pretending another attempt is always safe.</p> <h2> A durable record for every destination </h2> <p>A post sent to two social accounts is not one delivery operation. It is two independently observable targets, each with its own provider state and publication evidence.</p> <p>Beacon models that distinction directly. It keeps immutable post versions and tracks each accepted target until it reaches a visible terminal or recoverable state.</p> <p>This makes several operational questions answerable:</p> <ul> <li>Which version of the content was scheduled?</li> <li>Which account was selected?</li> <li>When was that destination supposed to publish?</li> <li>Did provider dispatch begin?</li> <li>Did the provider return usable evidence?</li> <li>Is the result confirmed, recoverable, delayed, or uncertain?</li> <li>Can the operation be repaired safely without creating a duplicate?</li> </ul> <p>The result is not merely a calendar entry. It is an auditable delivery record.</p> <h2> What Beacon includes today </h2> <p>Beacon already contains the foundation of a serious social publishing workspace:</p> <ul> <li>Workspace identity, brands, and connected channels.</li> <li>Encrypted provider credentials.</li> <li>Posts, immutable versions, and destination-specific targets.</li> <li>Media, approvals, audit data, webhooks, and entitlements.</li> <li>A publish-attempt ledger that records provider activity and evidence.</li> <li>Provider health, incidents, circuit breakers, and rate gates.</li> <li>A workflow outbox, repair jobs, and reconciliation paths.</li> <li>Conservative recovery for uncertain provider results.</li> <li>A mobile-first React application.</li> <li>Access, onboarding, channel management, composer, and Dayboard surfaces.</li> <li>Local and production Docker profiles.</li> <li>Repeatable interface fixtures with original post images and recovery states.</li> </ul> <p>Provider foundations include X publishing and OAuth, LinkedIn member publishing, WordPress Application Password publishing, and configurable support for additional providers such as Facebook, Instagram, Threads, DEV Community, and Medium.</p> <p>Provider availability is controlled by a deployment allowlist. Credentials can configure an enabled adapter, but they cannot activate a provider that the deployment has disabled.</p> <h2> Built for modern agent workflows </h2> <p>Beacon also provides a remote Streamable HTTP MCP endpoint. This allows supported AI clients to work with a Beacon workspace through scoped OAuth access.</p> <p>The user does not paste a Beacon secret into a conversation. Instead, the client opens Beacon in a browser, the user signs in, selects a workspace, and approves the requested scopes.</p> <p>Beacon’s MCP read tools can:</p> <ul> <li>List connected channels.</li> <li>Retrieve a post and its targets.</li> <li>Inspect scheduled and recent targets for a calendar range.</li> <li>Retrieve a provider’s composition and publication contract.</li> </ul> <p>Write tools can:</p> <ul> <li>Create drafts.</li> <li>Schedule posts through the durable publishing path.</li> <li>Generate shared or provider-tailored post options.</li> <li>Generate and store media when a compatible image model is configured.</li> </ul> <p>Provider contracts are important here. An agent can retrieve the selected provider’s required fields, character limits, supported formatting, media rules, and writing profiles before attempting to create a post. That keeps provider-specific requirements explicit instead of relying on guesses.</p> <h2> Immediate publishing requires real approval </h2> <p>An AI conversation cannot approve its own immediate publication request.</p> <p>For an immediate post, Beacon returns a short-lived approval URL. Beacon then displays the exact content, selected channels, provider settings, and media to the signed-in owner. Only the recorded approval permits the same request to continue.</p> <p>Drafts and scheduled posts follow their respective durable paths, while immediate publication receives this additional safety boundary.</p> <h2> AI-assisted composition without automatic publishing </h2> <p>Beacon uses the Vercel AI SDK and AI Gateway to produce editable post options when AI composition is configured.</p> <p>A user can choose shared copy or tailor content by destination. Provider contracts give the composer the correct character limits, native writing style, and media requirements. For example, a short-form provider can receive concise copy while a professional network can receive a more structured version.</p> <p>AI generation does not schedule or publish anything by itself. An applied option updates the editor state, where the user can review and revise it.</p> <p>Beacon can also generate a media plan containing:</p> <ul> <li>A visual concept.</li> <li>A recommended format.</li> <li>An aspect ratio.</li> <li>An image prompt.</li> <li>Alternative text.</li> </ul> <p>When a compatible image model and private storage adapter are configured, the generated image can be stored as a workspace-private Beacon media asset.</p> <h2> The technology behind Beacon </h2> <p>Beacon uses a focused modern stack:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Layer</th> <th>Technology</th> </tr> </thead> <tbody> <tr> <td>Application runtime</td> <td>Bun 1.3.14</td> </tr> <tr> <td>API</td> <td>Elysia</td> </tr> <tr> <td>Web</td> <td>React, Vite, TanStack Router, TanStack Query, and Tailwind CSS</td> </tr> <tr> <td>Database</td> <td>PostgreSQL 17 and Drizzle ORM</td> </tr> <tr> <td>Durable workflows</td> <td>pg-workflows 0.14.0</td> </tr> <tr> <td>Activity queues</td> <td>pg-boss 12.25.1</td> </tr> <tr> <td>Authentication</td> <td>Better Auth</td> </tr> <tr> <td>Local Node tooling</td> <td>Node.js 22.16.0 through NVM</td> </tr> </tbody> </table></div> <p>A production installation has two required services: the Beacon application and PostgreSQL.</p> <p>The separation between durable workflows and provider activities is deliberate. Workflow timing retries are not the same as activity crash retries, and neither should be confused with repeating an uncertain external create operation.</p> <h2> Engineering rules that protect user trust </h2> <p>Beacon’s engineering boundaries are shaped by the cost of getting publishing wrong:</p> <ul> <li>Do not derive organization scope from a convenient default.</li> <li>Do not put secrets or raw provider response bodies in queues, workflows, attempts, logs, or customer APIs.</li> <li>Do not repeat a provider create operation after dispatch may have started.</li> <li>Keep workflow timing retries separate from activity crash retries.</li> <li>Keep immutable post versions and provider-attempt evidence.</li> <li>Track every accepted post target until it has a visible terminal or recoverable state.</li> </ul> <p>These are not cosmetic architecture decisions. They make the system explainable when a provider behaves unexpectedly.</p> <h2> Why durable publishing matters </h2> <p>Publishing is a trust-sensitive workflow.</p> <p>A missed scheduled post matters. A duplicate post matters. A post marked as published without evidence matters. An unexplained provider failure matters. A recovery operation that creates a second public post matters.</p> <p>Users should be able to see what Beacon attempted, what the provider confirmed, and what remains uncertain. Operators should have enough durable evidence to repair failures without guessing.</p> <p>That is the problem Beacon is designed to solve.</p> <h2> Current status </h2> <p>Beacon is in active development and should not yet be used for a public production launch.</p> <p>Provider checks, security work, failure tests, load tests, and operations tests remain release requirements. The repository’s engineering handover records the implementation inventory, known gaps, verification evidence, and recommended work.</p> <p>The existing foundation is substantial: durable scheduling, provider health, post targets, approvals, media handling, channel management, AI composition, recovery states, and MCP access.</p> <h2> What comes next </h2> <p>The next phase focuses on hardening and verification:</p> <ul> <li>Expand provider checks.</li> <li>Complete security and failure testing.</li> <li>Run load and operations tests.</li> <li>Strengthen repair and reconciliation paths.</li> <li>Improve deployment and recovery evidence.</li> <li>Continue refining the composer, Dayboard, and failure-recovery experiences.</li> </ul> <p>Beacon’s goal is not merely to publish content. Its goal is to make publishing auditable, recoverable, and safe.</p> <p>If you have ever wondered whether a scheduled post actually went out, whether retry logic might duplicate it, or whether your publishing tool can explain what happened during a provider incident, Beacon is being built for that exact problem.</p> <p>Plan once. Publish with confidence. Keep every accepted delivery visible.</p> <p>That is Beacon.</p> product saas software startup David Anyatonwu Mon, 27 Jul 2026 12:43:12 +0000 https://dev.to/odogwu/a-befitting-title-381n https://dev.to/odogwu/a-befitting-title-381n <p>A befitting body for a post</p> David Anyatonwu Thu, 23 Jul 2026 20:20:44 +0000 https://dev.to/odogwu/a-befitting-title-127e https://dev.to/odogwu/a-befitting-title-127e <p>This is post will be made to both devto accounts. Hopefully. This is special to odogwus account</p>