Building a social media scheduler in 90 days — the public log

Eighteen days from now — if everything I cannot control falls into place — Smart Post Studio will be a real product that real people can buy. As I write this, I'm sitting at my kitchen table watching the cron logs scroll past on a second monitor, waiting for a scheduled X post to fire. It will fire in about ninety seconds, or it will silently fail in a way I have not yet anticipated. Both options remain open.

This is the post I wanted to read when I started this project, and couldn't find. It's not a how-to. It's not a victory lap. It's a record of what it has actually felt like to build something on a deadline, alone, when nobody is asking you to.

The decision

Smart Post Studio started, as most things do, with a mild irritation that wouldn't go away. I was helping creators schedule posts across six platforms. None of the existing tools fit. I wrote down what I'd want, looked at the list, and thought: this is two months of work, maybe three.

That estimate, like all software estimates, was wrong by a factor of about 1.5x. We are now around 75 days in. The target launch is May 22, my birthday, because I'm sentimental and also because I needed an immovable deadline. Whether the actual launch lands on May 22 depends on platform approvals (Meta, TikTok, Fanvue) that are out of my hands. The date I'm building toward is May 22. The date it actually goes live could be a week or two later. I'd rather tell you that now than spin it.

Picking your own birthday as a launch date is, on reflection, a slightly insane thing to do. It guarantees that any slip cuts directly into the part of the year you'd otherwise be allowed to be happy. I do not recommend it. I also wouldn't undo it.

The stack

I made the technical choices in about ninety minutes on day one, which was either the smartest or the stupidest thing I did. Electron and React for the desktop app. Cloudflare Workers for the API. Cloudflare D1 for the database. Microsoft Graph for transactional email. Anthropic's Claude for the AI Writing Studio.

Why these things? Mostly because I had used all of them before and didn't want to spend week one learning new tools. The advice you'll hear from indie founders is "use the boring stack you already know," and they are absolutely right. The advice you'll see on Hacker News is "use this exciting new framework that just hit 1.0," and they are absolutely wrong. There is no glory in the framework you ship with. There is glory in shipping.

The one thing I almost regret is Electron. It is a heavy, uncool, and slightly unloved technology. People will tell you to use Tauri. Tauri is probably the future. But I needed something that worked on day one and would still work on day ninety, and Electron's ecosystem has had ten years to make every weird desktop edge case someone else's problem already. I will probably migrate eventually. Probably.

The pivot from web to desktop

The first version was a web app. I had it building and deploying on day three. It looked nice. It also had a fundamental problem I didn't appreciate until day eight: web-based OAuth flows for desktop creator platforms are a nightmare.

The specific issue is that platforms like X (Twitter) and TikTok require localhost callbacks for desktop OAuth. A web app can't bind to localhost. So you end up with a Rube Goldberg machine of redirect URIs, hosted callback handlers, and token-passing through opaque hashes in URL fragments, all of which fail in interesting and platform-specific ways.

The second issue was the offline thing. I wanted the app to work in cabins. Web apps don't work in cabins.

So on day eight I scrapped most of the front-end and rebuilt it as Electron. I kept the API. I kept the database schema. The actual scheduler logic was the same. But the auth flows became dramatically simpler — every desktop instance is its own localhost server, the OAuth flow Just Works™, and tokens live in the OS keychain instead of a session cookie.

I lost a week. It was the right call. I would do it again.

Most of the work in building software is figuring out which version of the problem you're actually trying to solve. — Some thought I had at 2am, day 9

The platform approval saga

If you ever build a tool that integrates with social platforms, the single thing I want you to internalise before you start is this: your timeline is not your timeline. It is the meta-platform team's review queue.

Every major platform — Meta (Instagram, Facebook, Threads), TikTok, X, YouTube, Fanvue — requires you to submit your app for review before they let real users authenticate. Each review takes between five days and three weeks. If anything goes wrong, you go back to the bottom of the queue. The reviewers are not malicious. They are also not in a hurry.

I submitted Meta first, two weeks ago. They are reviewing. I submitted TikTok, twice — the first submission bounced because of a technicality in the demo video. I re-recorded the video. They are now reviewing. I submitted Fanvue last week. They are reviewing.

None of these are "approved" yet, two and a half weeks before launch. This should make me anxious. Sometimes it does. The thing that helps is remembering that the platforms have processed thousands of these. Mine is a single ticket in a stack of work that someone else manages. There is, genuinely, nothing I can do to speed it up. There is no email I can send. There is no engineer I can DM. There is only the queue, and the queue has its own rhythm.

I have learned to stop refreshing the dashboard.

The bug that ate Tuesday

About a month in, the scheduler started silently failing on certain posts. The logs showed a tick every minute, the post would queue, and then nothing would happen. No error. No retry. Just absence.

I spent Tuesday — all of Tuesday — chasing it. I added logging. I added more logging. I added a diagnostic harness that pretended to be the scheduler. The harness worked. The actual scheduler did not.

Around 9pm I found it. The scheduler was reading from a JSON store where the date string had been corrupted by a too-clever bit of slicing in the composer — "2026-04-22T17:11" with "00" appended without a colon, producing "2026-04-22T17:1100", which JavaScript parses as NaN. The scheduler compared NaN to "now," got NaN, treated it as not-due, and silently skipped the post forever.

The fix was three lines. The bug had eaten an entire workday. This ratio — minutes of fix to hours of finding — is, in my experience, approximately constant. It is the central law of software.

The waitlist thing

I'm going to be honest about the waitlist because the temptation to brag about it is strong and the brag would be misleading.

The waitlist is not zero. It is also not "thousands." It's a small group of people who heard about Smart Post Studio mostly through word of mouth, signed up, and now occasionally email me asking when launch is. Each one of those emails matters more to me than I expected. They are the closest thing this project has to evidence that I'm not building this for myself in a vacuum.

What I've learned from those emails: most people don't care about the technical decisions. They care about whether the thing will reliably post their content at 8pm on Friday. They are correct to care about that, and not the other things.

What I'd do differently

If I were starting again on day one with what I now know on day seventy-five:

• Submit platform approvals on day three, not day forty. The review queues are the long pole. Get in line before you've even built the integration. You can always add the integration to a stub later.
• Build the scheduler validation layer first. The bug that ate Tuesday was foreseeable. I could have written one defensive function on day five that would have saved me twelve hours later.
• Pick the desktop stack on day one, not day eight. Web-first felt safer. It wasn't. The platforms told me what shape the app needed to be, and I should have listened the first time.
• Tell more people earlier. I waited too long to talk publicly about the project. Not for marketing reasons — for accountability ones. The week I told ten people about the May 22 deadline was the week I started actually shipping.

What it feels like

The thing nobody tells you about indie founder life is that the dominant emotion is not excitement. It is not anxiety either, though there's plenty of that. It is something closer to flat patience — the feeling of doing a thing for the eighth hour of the day, on the sixty-eighth day in a row, knowing that if you do it again tomorrow it will probably be slightly better than today.

This isn't dramatic. It is, in fact, the opposite of dramatic. Most days I write code, deploy it, watch the deploy fail in some new way, fix that, redeploy, and then look at the clock and notice that it is 4pm and I have not eaten lunch. There are no Big Moments. There is only the long quiet middle.

What helps is having one specific creator in mind. Not a market segment. Not a user persona. One actual person. Mine is a creator I know who runs four Fanvue accounts and used to have to copy-paste her caption into six different scheduling tools every Sunday night. Every feature decision goes through a single filter: does this make her Sunday night easier? If yes, build. If no, cut.

That filter has saved me from at least a dozen features I would otherwise have built and regretted.

Eighteen days

The target is May 22, 2026. Whether it actually launches on the day depends on the platform reviewers and a small number of variables I haven't met yet. I will write another one of these posts after, on time or off, with the parts I can only honestly say once it's all real. Whether it goes well or badly, I'll write the truth.

If you want to be there at the start, the waitlist is here. Waitlist members get the first month free, which is the smallest thank-you I can offer for the gift of being patient with someone who has not yet shipped.

And if you're building something yourself, on your own deadline, I'll close with the only thing I'm sure about: the deadline matters more than the framework matters more than the feature matters more than the marketing copy. The version that ships beats the version that doesn't, every time, no matter how rough.

Eighteen days, give or take. Ship the rough one.

This is the first post in what I'd like to make a recurring build log. The next one will probably be written after launch — both the post-launch glow and the post-launch panic permitting. If you want to know when it's up, the waitlist (or RSS, when I add it next week) is the way.