I'm hesitant to even take a look at this project due to the whole "vibe coded in 3 weeks" thing, though. Hearing that says to me that this is not serious or battle-tested and might go unmaintained or such. Do you think these are valid concerns to have?
Planning, design, management alignment, finding customers, integrating with other products, waiting for review, etc. Basically all the human stuff that can't be automated away.
Your comment reminds me to add building a support team to the list.
Good software is expensive regardless of the involvement of LLMs because you need someone to take responsibility. Large companies will save a buck because there may be fewer people needed to take said responsibility, but it's probably a marginal saving compared to the overall scheme of things.
E.g. Buffer charges around $50 per year per social media account, which gives you an unlimited number of collaborating user accounts. And their single user plans are even cheaper.
I don't see how self-hosting would be a worthy investment of your time/effort in this case, unless you are in some grossly mismanaged organization where you have several devops engineers paid for doing literally nothing.
Consider having an account for each common social media platform, then multiply that for every project, that grows quickly.
It's $120/year/account for multi-user setup, and $60/year/account for single-user.
Which is still dirt cheap if you use social media professionally. E.g. what would $360 buy you if you try to do self-hosting? Maybe a day of work from a devops engineer to get this deployed for you?
Last time I “vibe coded” something (internal) and I liked it because I couldn’t find external solution.
I admire coders who can finish their code into deliverable and usable piece.
Issue here is software abundance and ppl will start to hesitate due to absurd pile that they should evaluate.
It reminds me the statistics of ice cream global sales. People want certainty so they choose chocolate or vanilla :)
Therefore many good software projects will have a problem to find users.
ironically, i didn’t read the article because i come to comments now to see if its been identified as AI slop, so i don’t know which area this falls into
Now however, many people just use it to mean any ai-assisted coding.
One person says “vibe coding” to mean a throwaway script to scrape some page. Others use it to mean a code reviewed app built by a team using Claude.
It is so broad as to be meaningless at this point
You can just vibe code it yourself. If your requirements are narrower (eg. you only need support for 3 networks and not 12), you will end up with something that takes less time to develop (possibly less than a day), it will have a smaller surface for problems, and it will be much better tailored to your specific needs. If you pay attention to what the LLM is doing it will also be easier to maintain or extend further.
The surface for security vulnerabilities also gets narrower, since you "only" have to trust the LLM (which is still a huge ask, but still better than LLM + 1 random person).
+1.
The password manager I use full time now is “Kenpass”, which has exactly one user: me. I have it on iOS/macOS/Linux, browser extensions, CLI and (native, no electron) UI for each, syncs with my homelab server over my wireguard tunnel, and it covers all my use cases. Took me maybe a week (a few hours total, spread around.) I feel no reason to share it with anyone, it does exactly what I need and I only need to fix the bugs I find, for myself.
We’re really living in crazy times.
> If you pay attention to what the LLM is doing it will also be easier to maintain or extend further
That's another nice part: I actually really enjoy feng-shui refactoring code to fit my tastes, and I've given the LLM's code a bunch of refactoring passes essentially "just for fun". I understand the codebase enough that sometimes I implement features myself instead of having the LLM do it, if I'm in the mood to. But I'd probably never have the time or energy to start such a project from scratch... having the initial MVP done in essentially one shot was a huge boost.
A few hours including iOS? Don't you need to go through lots of hoops even if it's only for personal use? Isn't it time-limited or something?
> username "ninkendo"
Absolutely checks out.
Please share more ken related software names you use lol
I just don't go run around different social media sites advertising my stuff. I built it for myself, if someone else likes it, they can use it.
If they want a feature they are free to suggest it, but I'm also free to ignore their wishes completely if I don't need the feature. It's an open license, they can fork it.
On top of which, any such vulnerabilities will be mostly low value: n different implementations, each with their own idiosyncrasies, 90% of them serving one person.
I think what I mean by "newfangled" is; this isn't a low-level C memory managed bit flipping thing; this is the sort of thing that's already built on top of layer of layer of the cruft that the web already is, for better or worse.
But, of course, that's not how most programmers use - at least I'd like to think. One thing is when people with zero programming knowledge vibe code something in that fashion, but for serious (read: big) products I'd like to think that you're still forced to do some book keeping.
It can be done though. And i say it as a developer for 20 years now.
Is there anything like that out there?
Tools like instaloader are a start, but screen scraping might be the best bet to avoid detection/banning.
made me think of Pidgin, the chat client that could talk to any chat server
I have a few ideas if my own, perhaps yours is something that could be created.
I don't mean to belittle the cool tool you made, I'm just grumpy about the loss of what the social network could have been and what we got when it morphed into social media.
- Only 140 characters - Increasing that added to the slop. Brevity was soul - No 'For you' algo. You had to find and follow the people you wanted to follow and then read all of their posts - RTing it was literally adding RT in front of the other person's tweet. - There was a 'like' icon (I think - don't remember) - There was no paid 'verified' accounts. You had to signal your official twitter account through different means. - There was no monetization for random clickbait ragebait content. - Ads are not that intrusive on twitter. That as a monetization strategy still works. - You only discovered people and not content.
Before writing any code, I spent time on detailed specs, an architecture doc, and a style guide. All public: https://github.com/brightbeanxyz/brightbean-studio/tree/main...
I broke the specs into tasks that could run in parallel across multiple agents versus tasks with dependencies that had to merge first. This planning step was the whole game. Without it, the agents produce a mess.
I used Opus 4.6 (Claude Code) for planning and building the first pass of backend and UI. Opus holds large context better and makes architectural decisions across files more reliably. Then I used Codex 5.3 to challenge every implementation, surface security issues, and catch bugs. Token spend was roughly even between the two.
Where AI coding worked well: Django models, views, serializers, standard CRUD. Provider modules for well-documented APIs like Facebook and LinkedIn. Tailwind layouts and HTMX interactions. Test generation. Cross-file refactoring, where Opus was particularly good at cascading changes across models, views, and templates when I restructured the permission system.
Where it fell apart: TikTok's Content Posting API has poor docs and an unusual two-step upload flow. Both tools generated wrong code confidently, over and over. Multi-tenant permission logic produced code that worked for a single workspace but leaked data across tenants in multi-workspace setups. These bugs passed tests, which is what made them dangerous. OAuth edge cases like token refresh, revoked permissions, and platform-specific error codes all needed manual work. Happy path was fine, defensive code was not. Background task orchestration (retry logic, rate-limit backoff, error handling) also required writing by hand.
One thing I underestimated: Without dedicated UI designs, getting a consistent UX was brutal. All the functionality was there, but screens were unintuitive and some flows weren't reachable through the UI at all. 80% of features worked in 20% of the time. The remaining 80% went to polish and making the experience actually usable.
The project is open source under AGPL-3.0. 12 platform integrations, all first-party APIs. Django 5.x + HTMX + Alpine.js + Tailwind CSS 4 + PostgreSQL. No Redis. Docker Compose deploy, 4 containers.
Ask me anything about the spec-driven approach, platform API quirks, or how I split work between the two models.
I ask, not to condemn, but to find out what your process was for developing the requirements. Clearly it was done with LLM help but what was the refinement process?
One main thing I did was to use the deep research feature of Claude to get a good understanding of what other tools are offering (features, integrations etc.)
Then each feature in the specs document got refined with manual suggestions and screenshots of other tools that I took.
> Before writing any code, I spent time on detailed specs, an architecture doc, and a style guide. All public: https://github.com/brightbeanxyz/brightbean-studio/tree/main...
> It took me tho 4 full days to get the specs to the level I was happy with.
When I click on history there I see only a single commit for these docs. Would you be willing to share some or all of the conversation you had with the LLM (in a gist or in the repo) that led to these architecture docs? Understand if you can't, but I'm sure it would be super instructive for people trying to understand the process of doing something like this and the types of guide rails that help to move the process forward productively.
What you describe has also been my experience so far with building projects mostly with AI but with detailed specs but Rails instead of Django.
1. You mentioned developing tasks in parallel—how many agents were you actually running at the same time? Did you ever reach a point where, even if you increased the degree of parallelism, merging and reviews became the bottleneck, and increasing the number further didn’t speed things up?
2. I really relate to the idea of “80% of features in 20% of the time, then 80% on polish.” Did you use AI for this final polishing phase as well? In other words, did you show the AI screenshots of the screens and explain them? Also, when looking back, do you feel that if you had written the initial specifications more carefully, you could have completed the work faster?
First I triggered all work streams per layer and brought them to a level of completion I was happy with. Then you merge one after another (challenge in github with the @codex the implementation and rebases when you move to the next work stream.
This is roughly how it looked like:
Layer 0 - Project Scaffolding
Layer 1 — Core Features Stream A — Content Pipeline Stream B — Social Platform Providers Stream C — Media Library Stream D — Notification System Stream E — Settings UI
T-0.1 (Scaffolding)
│
T-0.2 (Core Models + Auth)
│
┌───────────────────┼───────────────────┬──────────────┐
│ │ │ │
Stream A Stream B Stream C Stream D
(Content) (Providers) (Media) (Notifs)
│ │ │ │
T-1A.1 Composer T-1B.1 FB/IG/LI T-1C.1 Library T-1D.1 Engine
│ T-1B.2 Others │ │
T-1A.2 Calendar │ │ Stream E
│ │ │ T-1E.1 Settings UI
T-1A.3 Publisher ◄──────┘ │
│ │
└──────────◄───────────────────────────┘
(Publisher needs providers + media processing)
Layer 1 complete
│
┌───────────┼───────────┬──────────────┐
│ │ │ │
Stream F Stream G Stream H Stream I
(Approval (Inbox) (Calendar+ (Onboarding)
+ Portal) Composer
│ enhance)
T-2F.1 Approval
│
T-2F.2 Portal
Additionally, your token usage is very high since you are having so many agent do work at the same time, hence I very often reached my claude session token limits and had to wait for the next session to begin (I do have the 5x Max plan)
Isn't this a SaaS-pocaplyse testament? What's stopping anyone from doing the same to BrightBean? What's stopping anyone with a little of domain knowledge and a $200+ Claude to clone your app and build yet another gap-filling, slightly improved content-syndication version and go-to-market? Is it worth taking it to the market when anyone can perpetuate the cycle?
I'm genuinely interested in knowing your thoughts.
This will be 2 types of products.
1. A product which requires tech that is not inside the training data distribution of the models underlying coding agents. This is usually then very cutting edge.
2. A product that uses data/insights to generate value for a customer to which a coding agent has no access.
These are the only abstract moats I can think of, the rest will be a race to the bottom
- "In the AI Age, Data is your only Moat!"
Thanks for sharing such valuable insights JanSchu! B-)
It being open source doesn't help it either, so easy to malus/chardet it.
It's been running flawlessly for months without a single error. In fact, spooky good. I still feel nervous about it, though and check it every morning.
It is built mostly as a web app in .NET 10 Razor with SQLite db.
The APIs for the social networks are the hazy bit. As OP mentions, some are badly documented. Some are a pain to get access to. I was using a driven browser to post to Twitter, but they opened their API recently, which was nice.
[0] I used Claude in Github Copilot, so total cost was less than the $10/month in credits.
The tool shows all pipelines, builds, buildagents and approval ready in one place at a glance. For the most actions I use the public api but approval I use the internal api because they are still not public, since 4 years.
The tool runs so smooth it scares me too! My guess is that the apis are so stable that it will work for the next 10 years.
Questions: why no X? Do you have a feature to resize (summarize?) to the text to fit into short boxes?
If you're building anything serious and your data integrity is important, use Postgres.
Postgres is much stricter, and always was. MySQL tried to introduce several strict modes to mitigate the problems that they had, but I would always recommend to use Postgres.
Probably Postgres is there because you can use it as a queue (https://livebook.manning.com/book/just-use-postgres/chapter-...)
And for hmtx I simply wanted to have something lightweight that is not very invasive to keep things simple and dependencies low.
In my head this was a good consideration to keep complexity low for my AI agents :-)
Also calling HTMX old makes me feel old.
Yes, and Django feels like more of a Drillator than a simple screwdriver to me.
It's simple, it works, it's efficient, safe, and there are tons of online resources for it. Excellent choice, even more so when using a coding agent.
Svelte even older (2016, SvelteKit was just an new version in 2022)
SQLAlchemy is ancient (2006)
Use newer tech, like HTMX (2020)
(/s obviously)
Curious how you handled the queue and retry logic when a scheduled post fails partway through on one platform but not the others. Did you end up building a per platform state machine or something simpler?
I also added tons of unit-test, it helped ai agent to detect regression while producing code.
Technically that forces anybody who would modify it/use it as a baseline for their own product to share the source code.
Is this a purposeful decision?