The feature your users are already faking

Wed, 22 Jul 2026 00:00:00 +0000

Hailey didn’t raise a feature request. She didn’t ask me to add a button. She didn’t even describe it as something missing from krites.

She just showed me what she’d already started doing.

We’ve both been playing with Gemini for a long time now. Not in any grand strategic “the future of work” sense, just in the way two people in the same house share daft little experiments with each other. Sometimes to impress, sometimes to make the other one laugh, and sometimes because one of us has found a use for it that actually sticks.

This one stuck.

She’d started uploading sets of her photos to Gemini and asking it to critique them. Not edit them. That’s an important distinction. She wasn’t handing the machine a frame and saying “make this better”. She was asking it to look at her work, build a sense of her style, and then talk back to her about composition, colour, light, story, balance, the bits that are hard to improve when you’re mostly working on your own.

Photography can be lonely like that. It looks collaborative from the outside because there are people everywhere, especially at a wedding, but the improvement loop is often just you, your screen and a folder full of decisions. There isn’t always a team around you to poke a frame and say, “that one nearly works, but the crop is fighting you”, or “the colour’s lovely, but you’ve lost the subject”. So she’d found herself a coach.

And I was thrilled.

She was not asking it to do the work

The bit I liked most was how she was using it. She’d give Gemini a set of photos so it could build a rough profile of her work: the things she reaches for, the shapes she likes, the kind of light she keeps coming back to, the little patterns you don’t always spot in your own output because you’re too close to it. Then she’d pass it raw images for critique and suggested edits.

Then she’d do the post-processing herself.

That’s the whole point. The machine wasn’t replacing the craft. It was giving her something to argue with while she practised it. She’d take the suggestions, try to make the edits herself, sometimes do the opposite just to see what happened, and keep going until she was happy with the image. Then she’d send the result back, alongside the original, and ask for a second round.

Sometimes the response was good. Sometimes it was bad. That’s AI for you, it can be bob on one minute and then confidently wander into a hedge the next. But the loop was useful, and watching over her shoulder I could see the change. She was getting quicker. More confident. The images were moving from good to properly, annoyingly good, and a new fine-art direction was starting to appear in the work.

You don’t interrupt that because it wasn’t on your roadmap.

The workaround is the spec

This had not featured in krites at all. Not really. I had a roadmap full of culling, developing, retouching, object removal, local models, decision capture, all the machinery I thought a photo tool needed… and a critic that helped Hailey learn from her own edits was not on the list.

Which is funny, because the one real user of the tool had already gone and built the workflow for herself out of whatever was lying around.

That is about as clear a product signal as you’re ever going to get. Not a survey answer, not a support ticket, not a pretend persona in a planning document. A real person, trying to do a real job, stepping around your tool because another tool gives her something yours doesn’t.

The workaround is the spec.

I don’t mean that in the neat product-manager way, where every bit of user behaviour becomes a sticky note and a prioritisation meeting. I mean it much more literally. If someone is already doing the thing, and the thing is working, your first job is not to defend the shape you had in your head. It’s to pay attention.

The defensive version would have been easy. krites is local-first. I have written quite a lot about that already, and for good reason. Wedding photos are not disposable pixels. They are clients’ memories, and the default position of the tool is that they stay on Hailey’s machine. I could have reached for the principle, folded my arms, and explained why uploading images to a cloud model wasn’t what krites was about.

But principles are meant to serve the person using the tool, not win arguments against them.

Making the exception explicit

So the job became smaller and more interesting: not “should krites ever use a cloud model?”, because she was already doing that, deliberately and usefully. The job was “can I make this workflow quicker, clearer and harder to trip over?”

That means an AI review feature that is off until she configures it, explicit about where the image is going, and advisory only. It can critique. It can compare. It can keep a record of the rubric and the profile she is building. It can maybe make the whole loop less copy-pastey and more repeatable.

What it cannot do is quietly turn itself into the judge.

The cull still has to be deterministic where it can be. The tool still has to protect the originals. A review still doesn’t get to change a verdict, rewrite an image or pretend its opinion is fact. It is another thing in her bag, somewhere between a loupe, a notebook and a very enthusiastic assistant who occasionally needs telling to calm down.

That shape matters because the feature only makes sense if it preserves the behaviour that made the workaround valuable in the first place. Hailey was learning by doing. The review was useful because it gave her friction, language and direction, not because it took the mouse out of her hand. If I build the feature in a way that edits for her, I’ve missed the point so badly I should probably go and sit on the step for a bit.

A user beats an architect

This is one of the quiet advantages of building for one person you can actually watch. There’s nowhere to hide. No analytics dashboard to misread, no “users might want” hand waving, no imaginary market segment. There is just the person the thing is for, doing something you did not expect.

That can bruise the ego if you let it. I built this tool for her, after all, and here she was using something else for a piece of the work. But that is a stupid way to look at it. She wasn’t rejecting krites. She was showing me the next missing bit, before either of us had the language to ask for it.

Good tools grow like that. Not from the clean roadmap alone, but from the little sideways movements people make when the clean roadmap runs out. The spreadsheet someone keeps exporting because your report isn’t quite the one they need. The shell script wrapped around your CLI because one flag always comes after another. The photo critique pasted into Gemini because the tool that owns the library doesn’t yet have a way to ask for help.

Those workarounds are not always features. Sometimes they’re warnings. Sometimes they’re proof that your tool is aimed at the wrong job entirely. Sometimes they’re a sign that the right answer is to make the other tool easier to reach, not to swallow it whole. But they are almost always information, and information from real use is gold dust.

We did the same thing with a kitchen

This isn’t only a software thing, either. The campervan has taught us the same lesson with plywood and plumbing, which is substantially harder to revert than a bit of Go, as it turns out.

We rearranged the kitchen twice. Not because a drawing convinced us, but because Hailey used it while the van was half-built. She made drinks, moved things around, worked around the bits that weren’t finished, and those workarounds told us the plan was wrong. The thing looked sensible on paper, then a real person tried to live with it and the whole spec changed.

That is annoying. Obviously. It is also the best design feedback you are ever going to get, because it comes from use instead of imagination.

So yes, the AI review is going into krites. Not because the roadmap said so, and not because I woke up one morning desperate to let a cloud model into a local-first photo tool. It is going in because Hailey found a loop that helps her get better, and my job is not to interrupt that loop to preserve the neatness of my original idea.

My job is to build around it.