Introducing pCraft: A Workbench for People Who Build With LLMs
After a year of doing my most important work out of scratchpads and browser tabs, I got tired of the mess and built the tool I wished I had. It's called pCraft, it's live at pcraft.io, and this is the story of why it exists.
The mess that started it
For a long stretch, the most valuable thing I made lived in the worst possible places.
A prompt in a Python string. A slightly better version pasted into a note. The actual good one buried in a message I'd sent myself at one in the morning so I wouldn't lose it. Every model provider had its own playground, and none of them knew the others existed. When I wanted to know whether Claude or GPT handled a task better, I'd open two tabs, paste the same thing into both, squint at the outputs, pick a winner by feel, and the loser would vanish, along with whatever I might have learned from the comparison.
There was no version history. No diff between "the phrasing that worked" and "the phrasing I tried next." No way to ask the question I kept needing to answer: out of these six ways of saying the same thing, which one actually performs?
The longer it went on, the more it bothered me, because of the obvious irony. Prompting had quietly become the part of my work that most determined whether the software was any good, and it was the least engineered part of my entire workflow. We have Git for code. Postman for APIs. Figma for design. Ableton for music. Mature, opinionated workbenches that treat the thing you care about as a first-class object you can save, organize, version, compare, and share. For prompts and chains, the raw material of everything I was building with language models, we had a text box on five different websites and a lot of copy-paste.
pCraft is my answer to that. It's the workbench I wanted to exist, so I built it.
What it actually is
The shortest honest description I have is "Postman for LLMs."
Think about what Postman did. Hitting an API was something you always could do with curl and enough patience. Postman didn't invent the capability; it gave it a home. A place to save a request, name it, tuck it in a folder, tweak a header, fire it off, and actually see what came back, without rebuilding the plumbing from scratch every single time. It turned a fiddly, throwaway act into a craft you could get good at.
pCraft does that for language models. You bring your own key (your provider account, your keys, I don't resell you tokens or sit in the middle of your bill) and pCraft becomes the place your prompting work lives instead of scattering across tabs and notes.
The core loop is simple. You write a prompt, or you wire up a chain (a few steps where the output of one becomes the input to the next, with variables you can drop in by name) and then you run it and watch it happen, tokens streaming in live, step by step. And the part I use the most: you can point the same prompt or chain at several models at once and see them side by side. Same input, Claude and GPT and Gemini answering in parallel, their outputs lined up where you can actually read them against each other instead of holding two of them in your head across two tabs.
Everything you build is a real, saved artifact. You can keep variations of a prompt around, run them against each other, and mark the one that won. Conversations carry their history, so a chain can reason over what came before instead of starting cold every turn. It's the difference between prompting as a disposable act and prompting as something you can iterate on with intention, and keep.
That's the whole idea. Give the work a home, make it comparable, and stop losing the good version at one in the morning.
Why I think it's useful
I'm biased, obviously; I built the thing. But here's the case as honestly as I can make it, and it comes down to a few shifts that felt small and turned out not to be.
Prompts become artifacts you can reason about. The moment a prompt has a name, a home, and a history, you start treating it differently. You stop guessing and start comparing. You keep the phrasing that worked and you can see why it beat the one before it. Work you used to throw away becomes work you can build on.
You choose models on evidence instead of vibes. "Claude is better at this, GPT is better at that" is folklore until you can put them next to each other on your actual task with your actual input. Running one prompt across several models at once, in the same view, turns a hand-wavy opinion into something you can just look at and decide. That alone has changed choices I would've gotten wrong.
You can compose without wiring. Chaining a few model calls together (feed this output into that step, template in a variable, branch the logic) normally means opening an editor and gluing SDKs together. pCraft lets you build the pipeline and run it as a first-class thing, so the distance between "I have an idea for a multi-step flow" and "I'm watching it run" is minutes, not an afternoon.
Your keys stay yours. Because you bring your own key, your work runs against your own provider account. And your keys are encrypted at rest in a way that means even I can't read them. I was, frankly, a little obsessive about this part. If you want the paranoid-engineer version of how that works, I wrote it up in its own much nerdier post. For this one, it's enough to say: I treat the keys you hand me like they're money, because they are.
And it's one place. Not five tabs, a notebook, and a Slack message to yourself. One place where the work lives.
If you build with language models, whether as a developer, as someone designing agents and workflows, or just as someone who's tired of the playground shuffle, I think you'll feel the same relief I felt the first time I stopped juggling.
What building it taught me
I set out to build a product and, along the way, got taught a few lessons I didn't ask for. These are the ones that stuck.
I built for a scale that didn't exist. Early on, I stood up a genuinely impressive production setup, the kind of infrastructure you'd want if thousands of people were depending on you. Container orchestration, the works. It was beautiful. It was also guarding a fortress with no one inside, and every day it made the actual work slower and heavier. The most productive afternoon of the whole project was the one where I deleted almost all of it and replaced it with something small and boring that a single person can actually run. I'd been building for the company I imagined instead of the reality in front of me, which was: zero users, then one. Turns out the right amount of infrastructure for one user is very little, and admitting that was more freeing than any feature I shipped.
I fell in love with an architecture instead of a product. At one point I committed hard to a clever, privacy-maximal design, one that, on paper, was more elegant and more principled than what I ended up with. I was proud of it. And then it kept fighting every feature I actually wanted users to have. I spent longer than I should have defending the elegant idea before I accepted the uncomfortable thing: I was in love with the architecture, not with what it did for the person using it. When I let the product win, everything got easier. The lesson I keep relearning is that "correct and beautiful" loses to "useful" more often than my ego would like.
Holding someone else's key is a different kind of responsibility. There's a real shift that happens the first time "done" stops meaning "it works on my machine" and starts meaning "it is safe for a stranger to trust me with their credentials." It changed how I think about finishing. A feature isn't done when it runs; it's done when I'd be comfortable with my mom's API key flowing through it. That bar is higher, and it made me slower in exactly the places I should be slower.
Building mostly alongside AI agents rewired how I work. A lot of pCraft was built with AI as a genuine collaborator, and the thing I underestimated was how much that would push me toward writing decisions down. When your pair-programmer has no memory of yesterday's argument, you learn to record the why (why this tradeoff, why not that one) or you re-litigate it forever. I ended up with a paper trail of decisions that turned out to be as valuable as the code. It's a strange new way to build, and I think it's a preview of how a lot of us are going to work.
None of these are the lessons I expected to write down when I started. They're better than the ones I expected.
Where it is, and what I'm asking
I want to be honest about the stage. pCraft is early: pre-alpha, built by one person, moving fast. You will find rough edges. You'll hit something that isn't finished, or an interaction that's clumsier than it should be, or a corner I simply haven't gotten to yet. I'd rather tell you that plainly than pretend it's more polished than it is.
But the core is real and it works, and the thing I most want right now isn't praise. It's your reaction. Go break it. Bring a real task, wire up a chain, run it across a couple of models, and tell me where it got in your way. The gap between a tool the maker loves and a tool that's actually useful to a stranger only closes one way: strangers using it and telling the maker the truth. So please be a stranger who tells me the truth.
This is the tool I wished existed for a year before I made it. If you build with language models and any of this sounded like your own scattered notes and lost 1am prompts, I'd love for you to try it.
You can find it at pcraft.io.
Build something. Compare it honestly. Keep the version that wins.
Trying pCraft, or want to tell me what's broken? I genuinely want to hear it: email me at fcostoyaprograms@gmail.com.