Hi guys, it’s me again.
Recently I built two new projects with Codex, and both of them came from the same kind of frustration.
For a while, I kept thinking about how messy content workflows on X can become when you actually try to take them seriously. Writing one good post is not the hard part. The hard part is staying consistent, finding the right angle, reacting to real posts, keeping your writing style readable, avoiding repetition, and somehow turning all of that into a workflow that does not feel chaotic.
After thinking about that for a while, I ended up building not one project, but two.
The first one is ComposeX.
ComposeX started as the smaller and simpler idea. I wanted a clean writing copilot for X that could help me work from real visible posts instead of staring at an empty input box and forcing ideas out of nowhere. So the idea became very direct: monitor a curated live feed, select a post, then generate both a reply and an original post inspired by that source.
What I liked about this idea was that it stayed manual.
It does not try to become an autopilot. It does not publish for you. It does not pretend that content should be fully automated. In a weird way, that was the whole point. I did not want a tool that removes the writer from the process. I wanted a tool that supports thinking, supports drafting, and makes the workflow faster without making it fake.
That is why ComposeX feels more like a copilot than a machine. You still choose the post. You still decide what is worth reacting to. You still keep control over what gets written. The AI part helps, but it does not take over.
After building that, I started thinking bigger.
Because once you solve the “writing from a live feed” part, another question appears immediately: what happens after the draft?
That is where XontentStudio came from.
If ComposeX is the lightweight writing layer, XontentStudio is the bigger operating system behind the whole process. I wanted to build something that could handle generation, review, approval, scheduling, publishing, and content planning in a more complete way. Not just one helpful screen, but a whole local-first workspace that feels like a real product.
What makes this project more interesting to me is that it is not built around the usual fake productivity fantasy.
A lot of content tools look impressive on the surface, but they rely too much on automation theater. They make everything look “smart,” but the actual workflow underneath feels shallow. I wanted the opposite. I wanted something that starts empty, waits for real setup, works with real account data, and keeps the human review step in the center of the process.
That is also why the local-first direction mattered to me so much.
I like the idea that the workspace belongs to the user. Your drafts, your flow, your planning, your review decisions, your publishing logic. Not another platform trying to trap you inside a polished dashboard. Just a serious tool you can run on your own machine and control properly.
In that sense, these two projects are connected, but they are not the same thing.
ComposeX feels like the focused MVP. It solves one important part of the workflow in a simple way. XontentStudio feels like the broader vision. It takes the same problem space and asks what a more complete system would look like if I treated content production less like random posting and more like an actual operating workflow.
And honestly, that is probably the part I enjoyed most while building them.
Not just making the interfaces work, but thinking about product structure. Thinking about where generation should happen, where review should happen, what should stay manual, what should be scheduled, what should be visible, and what kind of safeguards make the whole thing feel intentional instead of noisy.
Codex helped me move much faster while building both projects, especially when I wanted to explore structure, iterate on features quickly, and test ideas that would normally take longer to wire up from scratch. But the bigger value for me was not just speed. It was momentum. Once I had the initial direction, I could keep pushing the projects forward without losing the energy of the idea.
That matters a lot, because many project ideas die in the gap between “this would be cool” and “this is now real.”
These two did not stay in that gap.
They are now real projects, public on GitHub, and more importantly, they represent the kind of things I actually want to build: practical tools, focused workflows, and products that come from a real need instead of just trying to look impressive on a portfolio.
There is still a lot I can improve in both of them.
ComposeX can become sharper and more refined as a writing tool. XontentStudio can become deeper and stronger as a complete local-first content system. But I already like what these projects say about my direction. They feel connected to a real problem, and they feel close to the kind of builder I want to become.
So yes, this post is about two repositories.
But it is also about momentum again.
One project became two. One simple frustration turned into a bigger product direction. And I think that is exactly why building in public matters. Sometimes you start with a small idea, and if you keep following it seriously enough, it opens the door to something much more complete.
You can check out the projects here:
ComposeX: https://github.com/saitakarcesme/ComposeX
XontentStudio: https://github.com/saitakarcesme/XontentStudio
see ya :)
