Eloquend

Most people are too busy to write great, useful posts for LinkedIn, so they miss out on the networking and career opportunities. I built Eloquend to make it 10x faster to make and publish great posts.

Comment

Eloquend

Inspiration

Most people have useful things to share on LinkedIn. They just rarely have the time to turn a half-formed thought into a post they are proud to publish.

Writing the first draft is only part of the work. You also need ideas, editing, images or carousels, scheduling, and consistency. When work gets busy, posting is usually the first thing to disappear. That means people miss opportunities to build relationships, demonstrate what they know, find clients, or take the next step in their careers.

I built Eloquend to make that whole process feel 10× faster—without taking the person out of it.

The goal is not to fill LinkedIn with generic AI content. Eloquend learns about the user’s role, audience, goals, voice, language, and writing preferences. It then helps turn their own ideas into useful drafts that they can edit, save, schedule, and publish.

What Eloquend does

Eloquend brings the LinkedIn content workflow into one workspace:

  • Create posts based on an idea, thought, note, or a quick rambling voice note.
  • Generate both standard text posts, image posts, and swipeable carousel posts.
  • Generate supporting images.
  • Edit and organize drafts.
  • Schedule posts for automatic posting.
  • Publish through a connected LinkedIn account.
  • Adjust tone, length, themes, calls to action, and other writing preferences.

The user stays in control throughout the process. Nothing is published without their review and decision.

What I built during OpenAI Build Week

Eloquend existed before Build Week, so I want to be transparent about that. Before the event, the main creation workflow—ideas, standard posts, carousels, drafts, scheduling, and publishing—was already working.

During Build Week, I used Codex and GPT-5.6 to meaningfully extend the project and bring it much closer to something I would be comfortable putting in front of real users.

The main addition was moving standard-post and carousel generation to GPT-5.6 Sol through Vercel AI Gateway. GPT-5.6 is the primary model for these writing-heavy workflows, using low reasoning to balance output quality, latency, and cost. Claude Sonnet 5 provides an explicit fallback. Idea generation uses the reverse order because discovering possible directions is a different task from writing the finished post.

I also spent a large part of the week on work that is less visible in a short demo but important in a real product:

  • Self-service account-data exports.
  • A more complete account-deletion workflow.
  • Private storage and authenticated delivery for user avatars.
  • Content Security Policy and safer logging.
  • Reduced retention of voice-transcription metadata.
  • Better legal-acceptance evidence across email and OAuth signup.
  • Versioned Terms, Privacy, and subscription documents.
  • Subscription notices and consumer-withdrawal flows.
  • Accessibility fixes for menus, dialogs, focus behavior, and navigation.
  • Regression tests for product workflows and previously discovered bugs.
  • Better failure handling for AI generation and provider capacity.
  • Technical SEO, structured data, crawl controls, and real 404 behavior.
  • A considerable amount of visual and interaction polish.

The eligible work covers 72 commits across 256 files, including seven database migrations and changes across 47 test or specification files.

How I built it

Eloquend is built with Next.js, React, and TypeScript. Supabase provides authentication, Postgres, storage, and Row Level Security. Text generation runs through Vercel AI Gateway with GPT-5.6 Sol and Claude Sonnet 5. OpenAI is also used for voice transcription and image generation.

LinkedIn OAuth handles publishing, Stripe handles subscriptions, Resend handles transactional email, and Vercel hosts the application.

For the GPT-5.6 migration, I preserved the existing guarded provider architecture instead of replacing it with a simple model call. The application reserves provider capacity, records usage, attempts models explicitly, releases reservations after failures, and records which model actually served the request. This made the implementation more involved, but it also made it much more honest and dependable.

How I worked with Codex

I used Codex as an engineering partner across many focused tasks rather than asking it to generate the entire application in one pass.

A typical task started with Codex tracing a complete workflow before changing it. For example, a signup change could involve the UI, API route, OAuth callback, Supabase migration, evidence model, legal documents, and tests. Codex was particularly helpful at finding all of those connections quickly.

It then helped implement scoped changes and verify them with the appropriate combination of unit tests, database tests, TypeScript, linting, production builds, browser checks, and response inspection.

I still made the product and engineering decisions. I chose the scope, model roles, user experience, visual direction, and what I was willing to ship. I rejected or reverted several changes that worked technically but did not feel right for the product.

That became my preferred way of working with Codex: explore quickly, verify thoroughly, and then apply human judgment.

Challenges I faced

Making generated writing feel personal

Generating text is easy. Generating something a person would actually want attached to their name is much harder.

The biggest improvement came from giving the model better context: the user’s work, audience, goals, tone, preferred language, themes, post length, calls to action, and custom instructions. I also kept editing central to the workflow because even a strong first draft should remain a draft.

Migrating models without breaking the surrounding system

Moving to GPT-5.6 was not just changing a model string. The model policy is connected to fallback behavior, structured carousel output, provider routing, rate limits, usage accounting, privacy options, and tests.

At one point, I enabled request-level Zero Data Retention and discovered through real testing that it was unavailable on my current Vercel plan. I removed the unsupported option and corrected the documentation while retaining no-training controls and explicit provider routing.

That was a useful reminder that a privacy claim must match the deployed system, not just the intended architecture.

Making an existing project eligible and understandable

Because Eloquend existed before Build Week, I needed to clearly separate earlier work from the new extension. I documented the baseline commit, the eligible commit history, how Codex was used, and where GPT-5.6 contributes to the final product.

That transparency felt much better than trying to present months of work as something created in one week.

Knowing when to stop polishing

I iterated repeatedly on animations, carousels, imagery, navigation, and responsive behavior. Some changes looked impressive in isolation but made the overall product busier or less clear.

I reverted an early outcomes redesign and removed motion that did not earn its place. Codex made iteration very fast, but speed also made restraint more important.

What I learned

My biggest lesson was that the model call is only a small part of an AI product.

The surrounding system—context, editing, failure handling, privacy, accessibility, billing, testing, and user control—determines whether the model is genuinely useful.

I also learned that Codex becomes much more valuable when I give it narrow problems, real constraints, and permission to investigate before editing. It is extremely good at accelerating difficult implementation work, but I still need to decide what the product should become.

There is plenty left to improve, but Eloquend now feels much closer to the product I originally wanted to build. I hope it helps more people share the useful things they already know :)

Built With

  • ai-gateway
  • codex
  • gpt5.5
  • gpt5.6
  • linkedin-api
  • nextjs
  • openai
  • playwright
  • postgresql
  • posthog
  • radix-ui
  • react
  • resend
  • sentry
  • stripe
  • supabase
  • tailwind
  • typescript
  • vercel
  • vercel-ai-sdk
  • zod
Share this project:

Updates