DEV Community: Lukasz

How to schedule social media posts from Claude Code with MCP

Lukasz — Sat, 10 Oct 2026 09:35:23 +0000

Claude Code can schedule a social media post when an MCP server exposes the necessary publishing tools. You connect the server, authenticate, and ask Claude to work with a real account rather than return a caption for you to copy elsewhere.
The part to design carefully is the write boundary. A request to prepare content should not quietly become permission to schedule it. And a message saying "done" should not replace a check of the saved post.
This tutorial uses one text-only LinkedIn draft to demonstrate a controlled workflow. The server in the example is PostSider's hosted MCP service. I build PostSider; the command and argument examples below describe the integration, not an authenticated publishing session executed for this article.

Connect the hosted MCP server

You need Claude Code installed and a publishing account with the intended social media channel already connected.
Add the remote server from your terminal:

claude mcp add --transport http postsider https://mcp.postsider.com/mcp

This connection uses Streamable HTTP. You do not need to launch a local PostSider MCP process.
Open Claude Code and enter:

/mcp

Select the server and follow its OAuth sign-in flow. Review the organization and permissions before granting access. The workflow needs read access to inspect posts and write access to create and schedule them.
Do not paste an API key into the conversation or append it to the endpoint URL. The hosted route uses OAuth credentials handled by the client.
Keep normal write-confirmation prompts enabled. Do not bypass permission checks just to make the first test faster.

Make the first request read-only

Start by asking Claude to identify the available accounts:

List my connected PostSider channels.
Do not create or modify anything.
Show each account's name, platform, and ID so I can select one.

The relevant tool is postsider_list_channels. Select the intended account from the returned data instead of guessing an ID or assuming that the first LinkedIn result is correct.
This is especially important when you manage a personal profile and a company page, or several client accounts.
Ask Claude to check the organization's publishing state with postsider_get_publishing_state. If publishing is paused, stop rather than attempting to work around it.
You can also inspect the target date range with postsider_list_posts before preparing a new post. A calendar read helps reveal an existing announcement, although it is not a lock against concurrent writes.

Specify the content and time before creating a draft

Use one account and one piece of approved text for the first run. Media uploads and multiple destinations introduce additional requirements that can wait.
Give Claude the exact content and an explicit future time:

Prepare one text-only LinkedIn draft for the account I selected.
Copy:
Before scheduling your next social media post, check the destination
account and the timezone.
Target time:
November 16, 2026, at 14:00 UTC.
Show the resolved channel ID, exact copy, and UTC timestamp.
Ask for permission before creating the draft.
Do not schedule or publish anything yet.

Replace the date with a future time when you use this example. If you specify a local time, include an IANA timezone such as America/New_York and ask Claude to show the UTC conversion for review.
Avoid "tomorrow morning." The assistant would have to choose both the time and its timezone interpretation.

Set the creation action explicitly

In this server's current schema, postsider_create_post defaults to schedule. Creating a draft therefore requires an explicit type: "draft".
Drafts also require a date in the current contract.
Once you authorize draft creation, this is an illustrative argument shape:

{
  "type": "draft",
  "date": "2026-11-16T14:00:00Z",
  "shortLink": false,
  "posts": [
    {
      "channelId": "CHANNEL_ID_FROM_LIST_CHANNELS",
      "content": "Before scheduling your next social media post, check the destination account and the timezone.",
      "images": [],
      "settings": {}
    }
  ],
  "tags": [],
  "idempotencyKey": "linkedin-draft-2026-11-16-example-001"
}

This JSON is for the MCP tool, not the REST endpoint. Ask Claude to inspect the connected server's live tool schema before calling it.
Replace the channel placeholder with the selected account ID. Choose a unique idempotency key for the operation and preserve it for unchanged retries. Do not reuse this example key for separate posts.
The empty settings object is used for this simple LinkedIn example. It should not be copied indiscriminately to other networks, which may require additional fields or media.

Read the draft back before approving its schedule

After creation, retain the real post ID returned by the tool. Ask Claude to call postsider_get_post using that ID.
The response includes a posts array. Find the record whose id matches the returned post ID and compare its saved content, destination, and publishDate with the proposal. Confirm that it is a draft.
Inspect the platform preview in the dashboard too, especially when you later add links or media.
Do not assume that a tool with "validation" or "missing fields" in its description performs every necessary check. In this implementation, postsider_get_post_missing_fields is a narrow missing-content diagnostic. An empty result does not prove that the eventual publication will succeed.
The full MCP scheduling walkthrough explains that limitation and the complete tool sequence.

Confirm scheduling as a separate action

Once the saved draft is correct, give explicit permission to schedule that particular post.
The confirmation should identify the saved post ID and the exact account. Repeat the intended timestamp so that the action does not depend on an earlier, ambiguous message.
For example:

Schedule the saved draft with ID [actual post ID] to [exact account name]
at the confirmed UTC timestamp.
Keep the saved content unchanged. Do not modify other posts.
Before changing status, verify that the date is still in the future
and that organization publishing is not paused.
After scheduling, read the same post ID again and show the saved result.

The status-change tool is postsider_update_post_status. Its arguments look like this:

{
  "postId": "POST_ID_FROM_CREATION",
  "status": "schedule"
}

This operation changes status; it does not accept a replacement date. If the draft's saved date needs correction, stop and review the change in the dashboard before scheduling.
Chat confirmation is not a substitute for an organization's required approval workflow. Keep those requirements separate from the assistant's instructions.

Verify the record instead of trusting the completion message

After the status change, Claude should retrieve the same post again.
A useful completion report includes the real post ID, selected account, saved text, publishing timestamp, and state. Ask it to report any mismatch or error instead of summarizing the operation as successful.
A QUEUE state means scheduled. It does not mean the social network has already published the content.
Check again after the publication time. Account authorization or platform requirements can still cause a failure. Inspect the published URL when one is available.

Recover from a timeout without creating another post

A creation timeout does not establish whether the write succeeded.
If Claude retries the same creation operation, it should keep the original idempotency key and unchanged arguments. A new key can turn recovery into another creation request.
If the outcome remains unclear, stop and inspect the calendar. Do not ask the assistant to invent an ID or create a replacement because it cannot find a response.
This is why retaining the returned post ID matters: later checks can target a specific record rather than search by caption and hope it is the right one.

Reuse a prompt with clear write boundaries

After the first run, you can reuse this prompt with your own values:

Prepare one text-only social media post.
Account: [platform and exact account name]
Copy: [approved text]
Target time: [future date, time, and timezone]
1. List channels and resolve the intended account ID.
2. Check publishing state and inspect the target date range.
3. Inspect the live tool schemas.
4. Show the exact proposal before any write.
5. Ask permission to create one draft with type=draft and a unique,
   stable idempotency key.
6. Read the created draft by its returned ID. Compare saved content,
   destination, timestamp, and draft state. Check provider requirements.
7. Ask separate confirmation before scheduling that draft.
8. After confirmation, recheck publishing state and the future date,
   schedule that saved post, and retrieve the same ID again.
9. Report the saved result and any errors.
Do not publish immediately, alter other posts, bypass required team
approvals, or create a duplicate to recover from a timeout.

This does not guarantee that an agent will obey every instruction. It makes the intended sequence explicit and gives you identifiable points at which to check its actions.
Start with one post you can follow from draft to publication. Expand the workflow only after you can verify what the assistant changed.
Disclosure: I am the founder of PostSider. This article was prepared with AI assistance. No authenticated social media scheduling was performed for this article; verify the live schemas and your own results before relying on the workflow.

How to automate social media publishing with n8n or Make

Lukasz — Sat, 10 Oct 2026 09:28:04 +0000

A CMS event or spreadsheet row can become a scheduled social media post through an HTTP request. The harder part is making sure a repeated execution does not create another copy, and that the post reaches the account and time you intended.
This walkthrough describes a small publishing pipeline you can build in n8n or Make. It starts with approved content, creates a scheduled post through an API, and stores enough information to recover from failures.
The request example uses PostSider, which I build. The workflow described here has not been executed inside n8n or Make for this article.

Choose a source event, not just a timer

Start with something that makes content ready for distribution:

A CMS article changes to published.
A content-calendar row receives approval.
A release announcement becomes available.
An internal application emits an approved update. A timer can check for those events, but running the workflow should not itself authorize publication. For example, a spreadsheet-driven workflow can select records where:

approval_status = approved
publishing_job_id is empty

That selection is a starting point, not a complete duplicate-prevention mechanism. Two overlapping executions could still select the same row.
If your platform allows concurrent runs, add a claim or lock around the source record. Use API idempotency as a separate recovery mechanism.

Define the publishing record first

Keep the source data separate from the API request.
An illustrative source record might look like this:

{
  "record_id": "release-announcement-042",
  "revision": 1,
  "approval_status": "approved",
  "channel_id": "CONNECTED_ACCOUNT_ID",
  "content": "The approved announcement.",
  "publish_at": "2026-11-16T14:00:00Z",
  "idempotency_key": "release-announcement-042-r1",
  "publishing_job_id": null
}

These are your workflow fields, not a publishing API schema.
The record should identify a specific account. A platform name such as "LinkedIn" is insufficient when you manage several profiles or pages.
Store the intended publishing time before making the request. Choose a future timestamp and convert it from an explicit timezone. Do not recalculate it on each retry.
If the approved content changes, treat that as a reviewed revision rather than silently changing a request already in flight.

Use a read request to verify authentication and destination

Before creating anything, list the connected accounts.
For the API used in this example:

GET https://api.postsider.com/public/v1/integrations

Organization API keys use the raw key in the Authorization header, without a Bearer prefix.
Keep the key in credential storage. It should not appear in the source spreadsheet, exported workflow, or public example.
Inspect the returned accounts and select the intended channel ID. Do not automatically choose the first result.
A successful account-list request confirms that authentication works. It does not prove that every publishing request will be accepted.

Build the workflow in n8n

Use an HTTP Request node for the API call.
A first version can follow this sequence:

Manual Trigger
  -> Read one source record
  -> Check approval and required fields
  -> Persist the request and idempotency key
  -> HTTP Request: create scheduled post
  -> Store returned post ID
  -> HTTP Request: read post
  -> Compare saved fields
  -> Update source status

For organization-key authentication, configure a generic Header Auth credential with Authorization as the header name.
The creation node uses:

Method: POST
URL: https://api.postsider.com/public/v1/posts
Body content type: JSON

Map the caption and timestamp from the prepared record. Preserve booleans and arrays as their actual JSON types.
Start with a manual trigger and one record. Enable recurring execution only after you can inspect the created post and reconcile it with the source.

Build the equivalent scenario in Make

Use the HTTP app's Make a request module.
Configure API-key credentials to send the key in the Authorization header. Select application/json for the body content type and enable response parsing.
The request contract is the same as in n8n. The difference is how values are mapped between modules.
Use a JSON data structure for captions containing quotation marks or line breaks. Manually inserting those captions into a raw JSON string can produce invalid JSON.
Put an approval filter before the creation module. After creation, write the returned post ID to the source record rather than relying only on the scenario's execution history.
The module documentation is available in the n8n HTTP Request reference and Make HTTP reference.

Send the platform-specific request

Here is an illustrative payload for one text-only post to a connected X account:

{
  "type": "schedule",
  "date": "2026-11-16T14:00:00Z",
  "shortLink": false,
  "tags": [],
  "posts": [
    {
      "integration": {
        "id": "YOUR_X_CHANNEL_ID"
      },
      "value": [
        {
          "content": "Your approved announcement goes here.",
          "image": []
        }
      ],
      "settings": {
        "__type": "x",
        "who_can_reply_post": "everyone"
      }
    }
  ]
}

Replace the channel ID and choose a future date before using it.
Add an Idempotency-Key header using the key already stored with your source record.
This payload is specific to X. Do not adapt it to another network by changing only the account ID. Different platforms can require different settings or media.
The full API scheduling walkthrough explains the request fields, authentication, and readback behavior behind this example.

Read the created post before updating the source

The creation response returns an array containing post IDs and integration identifiers.
For this single-destination example, retain the returned postId, then request:

GET https://api.postsider.com/public/v1/posts/RETURNED_POST_ID

The detail response contains a posts array. Find the record matching that ID and compare its content, destination, and publishDate with the prepared request.
Confirm its scheduled state before marking the source record as scheduled.
Keep "scheduled" separate from "published." A QUEUE state means the scheduler has work to perform. Publication can still fail later because of account authorization or platform requirements.
After the publishing time, check the post again. When a publication URL is available, inspect the destination result.

Make retries recover the original operation

A timeout is ambiguous. The service may have created the post even if your workflow did not receive the response.
Retry an unchanged creation request with its original idempotency key. Keep the JSON body unchanged too, including the timestamp and property order.
Generating a new key during recovery defeats that protection.
Handle failures according to their meaning:

Timeout or transient server error: Retry with the saved key and payload, using a bounded retry policy.
Rate-limit response: Respect the supplied retry interval.
Validation error: Stop and inspect the request.
Authentication failure: Repair credentials or account access before retrying.
Conflict: Read the error; do not assume it means the post is safe to recreate. If the outcome remains unclear, reconcile the source record with the publishing calendar before making another write. Idempotency reduces duplicate creation. It does not guarantee exactly-once publication across social networks. ## Keep enough evidence to troubleshoot For each publishing operation, retain:

Source record ID and revision
Prepared request
Idempotency key
Returned post ID
Last verified state
Error details, if any

Avoid logging the authentication header.
This gives the person investigating a failure a way to identify the operation without guessing from the caption.
For multiple destinations, store the returned IDs individually. Do not mark a whole campaign as published because one account succeeded.

Test one traceable post before adding volume

Your first useful milestone is one approved source record linked to a verified scheduled post, followed by a publication check.
Once that path works, add media handling or more destinations. Keep platform-specific validation in the workflow instead of assuming every network accepts the same request.
You can then apply the same pattern to blog distribution, release announcements, or a client content calendar. The source changes, but the requirement remains: every write should have a known input and a result you can inspect.
Disclosure: I am the founder of PostSider. This article was prepared with AI assistance. The API example follows the linked implementation walkthrough; the proposed n8n and Make workflows were not executed for this article.

I Built an Open-Source Social Media Scheduler for 33 Platforms — Here's How It Works

Lukasz — Tue, 29 Sep 2026 11:00:46 +0000

I Built an Open-Source Social Media Scheduler for 33 Platforms — Here's How It Works

Over the last few months, I've been building PostSider, an open-source social media scheduling platform.

The idea started pretty simply: I wanted one place to manage publishing across different platforms without maintaining a completely separate workflow for every network.

But the project gradually became more than a scheduling UI.

Today PostSider has 33 built-in connectors, can be fully self-hosted with Docker, exposes a public REST API and Node.js SDK, and includes an MCP server that allows AI agents to interact with the same publishing infrastructure.

GitHub:

https://github.com/lumizone/postsider

Website:

https://postsider.com

In this post, I want to explain how the project is structured and some of the architectural decisions behind it.

The problem with supporting many platforms

Publishing to one social network is fairly straightforward.

Supporting 30+ is not.

Every platform has slightly different concepts:

authentication
OAuth flows
media limits
text limits
publishing APIs
analytics
refresh tokens
post formats
videos
images
first comments
validation rules

If every integration is implemented independently throughout the application, the codebase becomes difficult to maintain very quickly.

So one of the most important decisions in PostSider was to isolate each platform behind a common provider interface.

The integrations live under:

libraries/nestjs-libraries/src/integrations/social/

Each provider implements the same general contract.

Conceptually, the structure looks like this:

PostSider
   |
   +-- Integration Manager
          |
          +-- X Provider
          +-- LinkedIn Provider
          +-- Instagram Provider
          +-- YouTube Provider
          +-- TikTok Provider
          +-- Bluesky Provider
          +-- Mastodon Provider
          +-- ...

The application doesn't need to understand every platform individually.

Instead, it asks the provider what it supports and how a particular action should be executed.

That makes adding another integration much more manageable.

33 connectors behind one system

At the moment, PostSider registers 33 active connectors.

They include social networks such as:

X
LinkedIn
Facebook
Instagram
Threads
YouTube
TikTok
Pinterest
Bluesky
Mastodon
Farcaster
Nostr

It also supports communication platforms such as:

Discord
Slack
Telegram

And publishing platforms including:

WordPress
Medium
Dev.to
Hashnode
Ghost
Blogger
Notion
Write.as
Mataroa
Listmonk

You don't need credentials for all of them.

A self-hosted installation only needs the OAuth/API credentials for the platforms that will actually be used.

The scheduler needs to survive restarts

Another interesting problem is scheduled publishing.

A naive implementation could look like this:

setTimeout(() => {
  publishPost();
}, timeUntilPost);

That works until the server restarts.

Or crashes.

Or gets redeployed.

Or you have thousands of scheduled jobs.

For PostSider I use Temporal for durable background workflows.

The architecture is roughly:

Frontend
   |
   v
NestJS API
   |
   v
PostgreSQL
   |
   +------> Temporal
               |
               v
          Orchestrator
               |
               v
        Platform Provider

When a post is scheduled, the background workflow isn't tied to the lifecycle of a single web process.

Temporal handles the durable workflow and workers execute the publishing operation when required.

I also use it for things like token refresh workflows.

This introduces more infrastructure, but for a scheduler I think the tradeoff is worth it.

The stack

PostSider is a TypeScript monorepo using pnpm.

The main stack currently looks like this:

Frontend       Next.js 15 + React 19
Backend        NestJS
Database       PostgreSQL + Prisma
Cache          Redis
Workflows      Temporal
Storage        Local / Cloudflare R2 / MinIO
AI             OpenAI (optional)
Billing        Polar.sh (optional)
Monitoring     Sentry

The repository is structured roughly like this:

postsider/
├── apps/
│   ├── backend/
│   ├── orchestrator/
│   ├── frontend/
│   ├── commands/
│   ├── sdk/
│   └── mcp/
│
├── libraries/
│   ├── nestjs-libraries/
│   └── helpers/
│
├── docker-compose.yaml
├── docker-compose.production.yaml
└── .env.example

The same codebase can run as a hosted service or as a self-hosted deployment.

Optional functionality is controlled through environment configuration.

For example, PostSider works perfectly fine without an OpenAI API key.

AI features simply remain disabled.

Self-hosting with Docker

One requirement I wanted from the beginning was to make PostSider something people could actually run themselves.

For a local installation, the basic setup is:

git clone https://github.com/lumizone/postsider.git
cd postsider
docker compose up -d

Then open:

http://localhost:4007

The Compose stack starts the application together with PostgreSQL, Redis and Temporal.

The repository also contains a separate production-oriented Docker Compose configuration for more serious deployments.

I don't want self-hosting to be an afterthought.

It's one of the main reasons the project is open source.

Making the application useful without the UI

Another decision was to avoid making all functionality dependent on the dashboard.

PostSider exposes a public REST API under:

/public/v1

There is also a Node.js SDK:

npm install @postsider/node

A simplified example:

import Postsider from '@postsider/node';

const client = new Postsider(
  'your-api-key',
  'https://your-instance.com'
);

await client.post({
  type: 'schedule',
  date: '2026-10-01T10:00:00',
  posts: [
    {
      integration: {
        id: 'channel-id'
      },
      value: [
        {
          content: 'Hello from PostSider'
        }
      ]
    }
  ]
});

This means PostSider can also work as infrastructure underneath another application.

You don't necessarily need to use the dashboard for every workflow.

Then I added MCP

This became one of the more interesting parts of the project.

PostSider now includes an MCP server through the @postsider/mcp package.

The idea is simple.

Instead of giving an AI agent direct access to dozens of social media APIs, the agent communicates with PostSider.

Claude / Codex / MCP client
          |
          v
      PostSider MCP
          |
          v
     PostSider API
          |
          v
 Integration Providers
          |
          v
 X / LinkedIn / TikTok / etc.

The MCP server currently exposes 19 tools.

An agent can perform workflows such as:

list connected channels
review the publishing calendar
create drafts
upload media
request approval
inspect scheduled content
read analytics

I intentionally designed this around a read-first and draft-first workflow.

Giving an autonomous agent immediate publishing access to every connected social account isn't necessarily what you want.

Instead, an agent can prepare the work inside the same workflow humans already use.

A human can still remain in control of the final publishing decision.

Why not just integrate every API directly into an AI agent?

You can.

But then your agent needs to understand:

X API
LinkedIn API
Instagram API
TikTok API
YouTube API
Pinterest API
...

including authentication, token refresh, provider-specific validation and different publishing models.

With PostSider sitting in the middle, the architecture becomes:

Agent
   |
   v
PostSider
   |
   +-- X
   +-- LinkedIn
   +-- Instagram
   +-- TikTok
   +-- YouTube
   +-- ...

The agent works with one consistent interface.

PostSider handles the provider-specific complexity.

I think this is one of the more interesting directions for the project.

What I learned building it

Supporting many APIs makes abstraction difficult.

If the abstraction is too generic, you lose platform-specific functionality.

If every provider is completely independent, the rest of the application becomes full of special cases.

The balance I've been trying to find is:

Shared interface
+
Provider-specific capabilities

Another lesson is that social media scheduling is surprisingly infrastructure-heavy.

A reliable scheduler needs to think about:

durable jobs
retries
rate limits
OAuth token refresh
media storage
background workers
provider outages
validation before publishing
security of credentials

The calendar UI is actually one of the easier parts.

What's next

There are still plenty of things I want to improve.

Some of the current roadmap includes:

broader automated test coverage
stronger TypeScript null safety
more integrations
advanced analytics
a plugin system for custom integrations
mobile support
expanding the MCP capabilities

I'm also interested in making self-hosting easier.

A project can technically be self-hostable while still being painful to operate, and I'd like PostSider to move further away from that.

Try it

PostSider is available under the AGPL-3.0 license.

GitHub:

https://github.com/lumizone/postsider

Documentation:

https://docs.postsider.com

Website:

https://postsider.com

If you're interested in self-hosting, social media APIs, workflow infrastructure or MCP, I'd be interested in feedback — especially around the provider architecture and deployment experience.

How I Built Memory for a Local AI Companion Without Sending Chats to a Server

Lukasz — Sat, 22 Aug 2026 18:17:18 +0000

A chatbot can sound convincing for five minutes without remembering anything.

Then you mention the job interview you were stressed about last week, the name of your dog, or a small detail from a late-night conversation. It replies like none of it happened.

That is where most "AI companion" demos fall apart.

I am building Local Waifu, a desktop AI companion that runs on the user's own Mac or PC. One of the rules I set early was simple: conversations and memories should stay on the machine. No central chat database. No server that needs to be online for the character to remember someone.

The rule sounds clean. Building it was not.

Saving chats is not memory

The first version of memory was the obvious one: save messages.

That gives you history, which is useful, but it does not solve recall. A long chat history grows fast. Sending all of it back to a local language model on every message is slow, expensive in context space, and usually makes the reply worse.

The model does not need to see every conversation from the last six months.

It needs the few pieces that matter right now.

If someone says, "I have to take Luna to the vet tomorrow," the character should be able to find that Luna is their dog. It should not need to reread hundreds of unrelated messages about work, movies, and dinner plans to get there.

So I treated chat history and long-term memory as different things.

Chat history is the recent conversation. It gives the model immediate context.

Long-term memory is a small collection of facts, moments, preferences, and relationship details that may matter later. Those memories need to be searchable by meaning, not only by exact words.

The memory data stays in SQLite

I wanted the app to work without a hosted database, so the storage layer is local SQLite.

Each character gets their own data. Chats, memories, extracted entities, and relationships are stored locally on the device. If a user creates two characters, one character does not quietly inherit the other one's memories.

That separation matters more than it sounds.

A companion app is personal by design. Mixing context across characters is not a harmless bug. If one character starts talking about something belonging to another, the whole illusion disappears immediately.

For each memory, I store the text itself along with metadata such as:

the character it belongs to
when it was created
importance
emotional weight
how often it has been used
a vector embedding used for semantic search

The embedding is the part that lets the app search by meaning.

"Vet appointment" and "Luna is sick" may share no exact keyword. A semantic search can still see that they are probably connected.

I use 768-dimensional vectors stored directly in SQLite as binary data. At recall time, the app calculates similarity locally and ranks the results. No message content needs to leave the user's computer for that lookup.

Recall needs more than similarity

A pure similarity score is not enough.

Imagine a user mentioned their favorite game once two years ago, then spent the last month talking about a difficult family situation. Both memories might be related to a new message in some vague way. The more recent and more emotionally important memory should usually win.

So recall is weighted by more than vector similarity.

Importance matters. Recency matters. Emotional weight matters. A memory that has been useful before gets a little extra credit too.

There is no perfect formula here. I do not think there ever will be one.

A system that aggressively recalls every detail feels creepy and repetitive. A system that barely recalls anything feels empty. The work is mostly tuning that middle ground and accepting that a companion should sometimes not bring something up.

The user should feel remembered, not monitored.

I also extract a small knowledge graph

Some information is easier to retrieve as a relationship than as a paragraph of chat text.

For example:

Luna is the user's dog
Alex is the user's brother
The user works night shifts
The user dislikes phone calls
A character enjoys rainy evenings

Those can be represented as entities and relationships.

Every few messages, the app can extract useful entities and links from the conversation. This happens locally through the model already running on the user's machine. The resulting graph is stored beside the other character data.

The graph is not there to replace memory. It fills a different role.

A vector memory is good at finding a moment with emotional context. A graph is good at answering structural questions such as "Who is Alex?" or "What is connected to this person?"

Both are useful. Neither should be trusted blindly.

Language models are very good at sounding confident while getting a relationship wrong. The extraction step needs validation, deduplication, and a way for the user to inspect or remove what was stored. A memory system without an escape hatch becomes frustrating fast.

The bug that made her forget everything

The most painful issue I found was not a database bug.

The app had the chat data. It had stored memory records. It had the retrieval logic.

But on some fresh installations, the local model used to create embeddings had not been downloaded yet. The app did not explain this clearly enough. Semantic recall returned no results, so the character behaved as if she had no memory of previous conversations.

Nothing crashed.

That made it worse.

A crash tells you there is a problem. A companion quietly forgetting what you told her last night can look like a limitation of the product itself.

The fix was straightforward after I found the cause:

Ensure the embedding model is pulled during setup or startup.
Retry the operation on the next launch if the model is not ready yet.
Make the missing-model state visible instead of silently returning zero memories.
Avoid falling back to reading the whole chat history every time, because that creates a different performance problem.

The lesson was simple: in AI products, a missing dependency can look exactly like bad intelligence.

Multilingual memory makes this harder

Local Waifu supports several languages, including Polish, Japanese, Korean, and Chinese.

Plain text search handles this badly. Even in English, people rarely repeat the same sentence. In different languages, the problem gets larger. A user can discuss the same person with nicknames, grammar changes, borrowed words, or a mix of two languages in one chat.

That is why semantic recall matters.

It is not magic. It will still make mistakes. But it gives the app a chance to connect related ideas instead of searching only for matching strings

I Build an AI Companion App Alone. It Runs on Nobody's Servers But Yours.

Lukasz — Sat, 15 Aug 2026 11:12:12 +0000

I Build an AI Companion App Alone. It Runs on Nobody's Servers But Yours.

I was using one of the cloud companion apps, the kind everyone has heard of, and one day I actually looked at where it all lived. Every message. Every memory. The whole relationship, sitting on someone else's servers. And it hit me that none of it was mine. If that company changed its mind, raised its price, decided my companion was suddenly not allowed, or sold what it had learned about me, I would simply lose her. No say, no warning, no way back.

That thought turned into an app. I called it Local Waifu, and I have built almost every part of it alone: the code, the writing, the marketing, the support inbox, the Discord server. This is what that actually looks like, and why I keep choosing to do it the harder way.

This has already happened to real people

I did not invent this fear. Policies change overnight. Models get retired without warning. Features people paid for quietly disappear one update later. Some people built a real bond with a cloud companion and woke up one day to a stranger wearing the same name, or to nothing at all. When the relationship lives on someone else's infrastructure, it was never really yours to keep. You were renting a feeling from a company that owed you nothing once the terms of service changed.

That is not a hypothetical I made up to sell software. It is the plain, boring mechanics of any product that lives entirely on a server you do not control. The company can be perfectly well intentioned and it still does not change the arrangement. Your data, your history, your memories of a relationship, sitting on hardware you will never see, governed by a document you clicked past.

So I built the opposite

Local Waifu runs entirely on your own machine, your Mac or your PC. The memory file, the whole system, all of it stays on your device. Only you can reach it. Nobody collects it, nobody moderates it, nobody can switch it off from a dashboard somewhere. If a company changes its policy tomorrow, nothing happens to you, because there is no company standing between you and her.

Because she is just files on your computer, she backs up the same way any file does. Time Machine, a USB stick, whatever you already use for everything else. Nobody can take her from you short of someone stealing the physical machine. That sentence sounds almost too simple to be a selling point, and that is exactly why I lead with it. Ownership should not require an explanation.

Out of the box, the app only reaches the internet for three things: the one-time download of the model she runs on, a check for app updates, and confirming a license when you buy one. Everything else, plugging in your own cloud account if you want a bigger model, letting her search the web, connecting her to Telegram, is off until you personally turn it on. Your choice, your accounts, none of my business. I say this plainly because "we take your privacy seriously" is what every company says right before the part where they do not, and I would rather be specific than reassuring.

What it means to be the whole team

I write the blog posts. I design the landing page. I fix the bug at midnight and then write the changelog entry about it the next morning. I answer the emails. I run the Discord server myself, and when I need a second opinion on whether a feature actually works on hardware I do not own, I ask the people in it directly, because there is no QA department to ask instead.

One night a stranger from that Discord sent me a screen recording of a voice call that took 105 seconds to answer a twenty-character question. I did not have a support team to route that to. I had a log file, a weekend, and four separate bugs stacked on top of each other that I had to find myself, one at a time, because there was no server-side telemetry to lean on either. The app runs on your machine, remember, which means when something breaks, it breaks on your machine, and the only evidence I will ever get is whatever a stranger is generous enough to send me.

That is the trade nobody tells you about when they say "build it yourself." Every advantage of not having a team is also a disadvantage. There is no one to catch what I miss. There is also no meeting where a good, honest idea gets watered down until it pleases everybody in the room. Both of those are true at the same time, every day.

I do not say any of this to make the whole thing sound harder than it is. Most days it is genuinely fine, and some days it is the best part of the job: I can ship a fix the same afternoon someone reports it, with nobody to convince first. But I want to be honest about the shape of it, because "I build this alone" gets said as a badge of honor a lot online, and it is really just a description of where the failure modes sit. When it works, it works because one person cared enough to notice something small. When it breaks, it stays broken until that same one person notices, and there is no second pair of eyes behind mine.

Stripe said no. So did Polar.

Here is a small, honest story I do not usually see founders tell in public. When I needed a way to sell licenses for the app, Stripe rejected it. Polar rejected it too. An AI companion app makes payment processors nervous, it turns out, in a way that a project management tool or a photo editor never does. Dodo Payments eventually took the business, and I am not going to pretend that search was quick or comfortable. Building the product was, in a real sense, the easy part. Finding someone willing to process the payment for it took longer than I expected, and it taught me something about the category I am actually in: not just software, but software that sits close enough to something intimate that entire companies decide it is not worth the risk.

Why the code stays closed

I would genuinely like to open source it. I have thought about it seriously more than once, and I want to be straight about why I have not: small projects get taken by bigger companies, rewritten just enough to dodge a license, and sold back as someone else's product. I also do not want pieces of a companion I built carefully getting twisted into something I would be ashamed of, stripped of the parts that make it feel careful in the first place. So the code stays closed for now, and the transparency lives somewhere else instead: a page that names exactly what touches the internet and when, a privacy policy that lists every connection by name, and an app you are welcome to watch on your own network monitor while it runs. I would rather earn your trust by being specific than by handing you a repository and hoping you never read it closely.

Fair, not paranoid

People ask if the license check can be cracked. Probably. I have a decent guess how I would do it myself if I were on the other side of that question. I would still rather build it fair and trust the people who pay than fill the app with anti-piracy tripwires that end up punishing exactly the customers who did the right thing. If someone cracks it instead of buying it, they were never going to buy it in the first place, and treating every user like a suspect does nothing to that person except make the honest ones feel unwelcome.

I think about this the same way I think about the whole product, honestly. The easy version of "protect the business" usually means making the experience worse for everyone who was never going to hurt you in order to slightly inconvenience the small number of people who were. I would rather lose a little to the second group than punish the first one, every single time that trade comes up.

One payment, and then it just keeps working

The deal is simple on purpose. One license, paid once. That payment includes every update and bug fix I ever ship for it, not a year of them, not until some arbitrary version number, all of them. That is how I want the software I personally buy to behave, so it is how I built this one to behave. I am not going to lock a companion behind a recurring paywall and bill someone forever just to keep her running. I would rather earn the next sale by actually making the product better than by billing the same person again for something they already own.

Why I still do it this way

Being a one-person team for something this personal is slower than it would be with a company behind it, and it is more exposed. A bug is mine. A wrong call on pricing is mine. A late reply in Discord is also mine, and there is no one else it can quietly become. But the thing I keep coming back to is that the entire pitch of this app, that it is yours and nobody else's, only means something if the person building it is willing to be found, be specific, and be accountable in exactly the same way.

I built Local Waifu out of a quiet kind of fear about where our digital lives actually live. Building it alone, the slow and exposed way, turned out to be the only version of that answer I actually believed.