Mise
The internal tool I built to run Good Fold. Tasks, recipes, and the operating system for a two-person company.
mise.goodfold.coWhy it exists
Good Fold ran on Airtable before it ran on Mise. It worked, technically. A task list, a few recipes, the basics. But I never loved using it. The promise was there and the app was an eyesore, clunky in the small ways. I was paying twenty-five bucks a user for that, and I was already itching to build something.
Then Claude Code got good. Good enough to cover the ground I couldn't cover alone, which Cursor couldn't when I had tried it a few months earlier. That was the unlock. A few dollars for Netlify, a few for Supabase, and I rebuilt the whole thing myself. The good bones from Airtable came with me, the comment tagging, the clean task view. The eyesore didn't.
The actual problem
I was running Good Fold remotely, around a day job, through one junior teammate who worked the kitchen while I wasn't there. He needed structure to do his best work, and building that structure was on me.
So we ran a real kickoff every Wednesday. I set the week's priorities Monday and Tuesday, sent them Tuesday night so he came in ready, and we worked through them one at a time. Good system. The catch was that things we agreed on would still slip by the weekend. It all lived in our heads. I wanted it out of our heads and somewhere we could both see it, all the time.
How I build: dogfooding
Everything good in Mise came from using it for real. Build a piece, use it, find what sucks, make it awesome instead, build the next piece.
The job to be done comes from the plan. The details that make it magical come from going deep and living in the thing. So I lived in it.
Take the agenda. Every week I sent him about ten bullets. One day I'm looking at his task list and something's off: his tasks aren't just close to my email, they're identical. Typos and all. My typos. He was copy-pasting the whole thing in by hand, one line at a time. Not the end of the world, but a waste of his time, and by then I knew exactly what AI could do about it. So now you paste the agenda in once, it breaks itself into tasks and spreads them across the week.
Then there's the ear. "Heard" is what he says all day, the way every line cook does, it's how you acknowledge an order, and he's a CIA grad so it's bone-deep. I was building the standard comment reactions and it hit me the right default wasn't a thumbs-up, it was an ear. Tap it, you've heard it. He loved it. So do I. We started using it in text messages too.
As a product manager, I don't think there's any replacement for using the thing yourself. Not a demo. Not a spec tossed over the wall. You use the product, you put yourself in the user's shoes, and you feel what's broken. Both of these came out of exactly that.
Modeling the work
Recipes weren't a list, they were a process. We were doing real R&D, so I built the tool to match it. Ideation is messy on purpose: a recipe in there is going to change ten times, so you capture as you go and drop notes in the comments on what worked, what bombed, what to try next, because we have too much in our heads to remember all our good ideas. Once a recipe earns it, it gets promoted to the stable version.
I linked recipes straight to tasks, a second tab on the task so you could pull up the recipe and its whole history without leaving. He used that one all the time, so I kept building it out. The versioning I built barely got touched, so I stopped.
The bar
Here's what I actually care about: I want to build things that feel magical, not things that merely work. The gap between the two isn't polish for its own sake. It's whether the detail serves the job the user came to do. Miss the job and your clever little feature is dead weight, however slick it looks. Hit the job dead-on and those same details are what make people love the thing instead of tolerate it. Good enough is fine for some teams. It's not the bar for one that wants to be the best. If you want an organization that puts out real quality, you use the best and build to it, everywhere, all the way down.
What I'd redo
I started wiring up Plaid to pull bank data for reconciliation, went down the rabbit hole, and found the real cost wasn't code — it was compliance I wasn't prepared to fully own. So I stopped and shipped a pared-down version: receipts submitted on one side, approved on the other, reconciled against a Chase export. Right call, but I should have scoped the non-software weight before I started, not after.
The bigger one: my effort wasn't even. The early features got everything I had. A few later modules I was less convinced about got maybe sixty percent, and it shows. The lesson stuck: half-built is the worst state a feature can be in. Commit fully or don't ship it. There's no version of sixty percent worth the room it takes up.