Really cool project — the "no backend, no build step" constraint is genuinely hard to pull off well and you did it.
Couple things I'm curious about:
How does performance hold up when you're layering multiple capture sources simultaneously? That's usually where browser-based tools start to sweat.
Also — the "hackable rather than polished" framing is smart positioning. Are you thinking about specific use cases you want people to fork this toward? Because the talking-head + annotation combo immediately makes me think async demo videos for indie devs who can't afford Loom Pro, or lightweight sales prospecting tools. Would be interesting to see what the community actually builds with it.
One suggestion: a short screen recording (meta, I know) showing the layering and annotation in action would probably cut your "time to wow" significantly. The README explains it well but seeing the canvas manipulation live would land faster.
This is exactly the kind of scratch-your-own-itch story that produces genuinely useful tools. The fact that you ruled out Excel because the barrier was too high is actually a really important insight — there's a massive gap between "technically possible" and "actually usable."
Curious about a few things:
How are you handling price updates for the non-standard assets like physical gold? Manual entry, or did you find an API that covers it?
Also, the multi-currency angle with TL is interesting — currency fluctuation probably creates a whole secondary layer of complexity for your P&L view. How are you displaying that — in a base currency, or showing each position in its native currency?
Last question — have you shown this to anyone outside your own use case yet? Sometimes the constraints that feel personal turn out to be the exact constraints a much bigger group shares. Would love to see where you take it.
Good instinct to ask before building — you're already doing the thing you're selling.
On your questions:
1. Figma clickthroughs + a Loom walkthrough sent to 10-15 target users. Messy but cheap.
2. "Fake" video data is fine if you're measuring the right thing. Click-through on a landing page beats survey intent every time. People lie to be nice; clicks don't.
3. Honest answer: I'd pay if you could show me a case where the video said "no" and saved someone real money. One solid example beats a hundred testimonials.
Bigger concern — 2 devs saying they'd use it isn't validation, it's encouragement. Before you build anything, I'd run your own video prototype of this service and see if strangers convert. Meta, but you'd learn fast.
What's the actual customer you're picturing — solo devs, or teams with some budget?
Strong agree on clicks over surveys. Once I move from a video prototype to a live MVP, the real signal comes from watching what people actually do.
I built UXWizz mainly for this. Self-hosted heatmaps and recordings make it pretty obvious where people get confused or drop off, and you don’t have to rely on polite feedback [0].
Strong agree — clicks > surveys, and behavior > opinions.
The gap I'm trying to fill: before you have the live MVP (and before you invest in heatmaps/recording infrastructure), how do you know which workflow is worth building?
Video prototypes are the "pre-MVP" behavior test — show the experience, see if they click "I'd pay for this" vs just "interesting."
Curious: When building UXWizz, did you validate the "self-hosted vs cloud" decision with video prototypes, or did you ship and learn from early user behavior?
Feels like your tool captures the truth post-launch, mine tries to predict it pre-launch. Complementary approaches.
Great experiment. The "implied context" problem is real and it kills projects.
One thing I'd push back on slightly: the 5 vs 127 framing makes this feel like a volume win for AI, but I think the actual insight is that AI externalizes the assumptions humans carry silently. That's the useful part.
What worked for us was using AI-generated specs not as a deliverable but as a conversation starter. You print the 127 points, sit with the client for 90 minutes, and the deletions become the spec. "We don't need multi-tenancy" is a real decision, not an oversight, once someone's forced to say it out loud.
To your questions directly:
1. Yes, reusable checklists for auth/RBAC/rate limits are underrated
2. 127 points is too many to hand a dev team, but perfect for a client workshop
3. Filter by "can we launch without this" — ruthlessly
This is a real problem — I blew past $300 in a week before I even noticed. The lack of visibility is genuinely alarming when you're letting an agent run autonomously.
Few questions that'd help me understand the scope better:
The risk level tagging (read/write/exec) — is that purely for logging, or are you planning any threshold-based alerting? Like "pause and ask me before you rack up another $50 in exec calls"?
Also curious about the append-only guarantee. What's preventing a compromised agent from tampering with the ledger before your audit? Is that a threat model you've considered or intentionally out of scope?
The Cursor billing pull is clever — did cursor.com's API require any reverse engineering or is that documented somewhere?
Rust was the right call for something sitting in that critical path. Nice work shipping something you actually needed. This fills a gap that the agent tools themselves are weirdly uninterested in solving.
$300 in a week, yeah. That's what pushed me to build this.
Risk alerting - logging only for now. The data's all there (cost, risk, timing per event) so threshold alerts are straightforward to add. I wanted to nail visibility before touching enforcement. It's next.
Ledger tamper resistance - out of scope for v1, intentionally. You're right that a compromised agent with fs access could modify it. The real fix is a hash chain so tampering is detectable after the fact. I didn't want to over-engineer before validating the basic use case, but it's the right next step on the integrity side.
Cursor billing - Cursor stores per-request token usage in a local SQLite db at ~/.cursor-server/data/state.vscdb. That's your data on your machine, vigilo just reads it. The cursor.com billing endpoint wasn't documented but wasn't hard to find by watching network traffic. Worth noting: the cursor-usage command is purely additive — if Cursor changes their schema it degrades gracefully, but the core audit trail (MCP + hooks) has zero dependency on it.
On tool coverage - Claude Code is fully covered via matcher: ".*" on PostToolUse, every built-in tool fires through it. Cursor coverage was partial by default (Bash and Edit only) - pushed a fix today that adds beforeReadFile and beforeMCPExecution to the default setup.
The hash chain approach is exactly right — even a simple append-and-sign pattern would catch post-hoc tampering without much overhead. Worth looking at how Sigstore handles this for inspiration.
Good call on visibility-before-enforcement. Alerting built on shaky data models is worse than no alerting.
The SQLite read is clean. Graceful degradation on schema change is the kind of detail that separates "I built this for me" from "I built this to last."
Curious what your rollout looks like — are people self-hosting, or is there a managed path you're considering?
Sigstore is a good pointer - I'll look at how they handle the transparency log. The append-and-sign pattern is probably the right starting point before going full Merkle tree.
On rollout - fully self-hosted right now, intentionally. The core promise is local-only: your data never leaves your machine. curl | bash, single binary, vigilo setup handles the rest.
A managed offering for teams is the obvious next step if there's demand - but it's a fundamentally different product with different trust assumptions. I'd build it as a separate thing, not by compromising the local-first model.
The MCP angle is genuinely clever — turning metadata management into something Claude can batch-process across locales is a real time unlock.
Curious how you're handling the prompt-to-push workflow in practice. Like, are people writing their own prompts from scratch, or are you shipping example prompts that say "optimize keywords for [target audience] across all locales"? That last mile of "but what do I actually type" trips up a lot of otherwise solid MCP integrations.
Also — the 3-4 hour pain point is real and I've felt it. But I'd bet your strongest conversion argument isn't time saved, it's mistakes avoided. Wrong locale, wrong character count, accidentally overwriting a localization a contractor did 6 months ago. The diff/history story might be undersold in your current framing.
What's your current distribution strategy? Indie iOS devs are a notoriously tight word-of-mouth community if you can crack the right subreddits and discords.
On prompts — in the web dashboard we have AI with deep ASO knowledge baked in, so the suggestions are already tuned for App Store best practices. With the MCP server it depends more on your input, but that's also the flexibility — you can prompt however you want. Shipping example prompts and recipes for common MCP workflows is next on the list.
On mistakes avoided vs time saved — you put a bug in my head with that one. I've personally pushed wrong locales and only caught it days later. The diff/history story is definitely undersold. Going to A/B test the landing page with that framing and see if it converts better.
Distribution — honestly early days. Show HN, Reddit, Twitter so far. Would love to hear which subreddits or discords you'd recommend if you have any in mind.
A/B testing is great, but early stages have to trust your gut/experience on it until you can get some more feedback through the testing.
For distribution: r/iOSProgramming and r/indiegaming are worth a shot, but the real gold is usually the smaller discords. RevenueCat's community has a solid indie dev contingent. Same with some of the Superwall and Adapty Slack groups — people actively talking monetization and store optimization, which is your exact user.
One tactic that works: share the "wrong locale, caught it days later" story authentically. Not as marketing copy — just as a post. That'll land harder than any feature announcement IMO.
Really cool project. The self-development pipeline demo is what sold me — that's not just a toy, that's a proof of a real workflow pattern.
Few things I'm genuinely curious about:
On the CRD design — how are you handling secret/credential scoping per Task? Ephemeral pods are great for isolation, but if AgentConfigs can reference MCP servers, there's a credential surface area question worth thinking through early before people wire this into production pipelines.
On the container abstraction — does the standardized interface currently enforce any output schema validation, or is it mostly convention right now? Would love to know how strict that contract is in practice.
On adoption friction — K8s-native is powerful but raises the floor pretty high. Have you considered a lighter local mode (kind/minikube) with pre-baked configs to let people prototype workflows before committing to a full cluster setup?
Genuinely interested in where this goes. Watching the repo.
Really like the clarity of the problem here — "I skipped runs because I had nobody to go with" is a sentence that sells itself.
One thing I'd watch closely in beta: the cold start problem is going to hit hard at the neighborhood level. A map with no nearby runners is lonelier than having no app at all. Worth thinking early about whether you seed sessions differently in low-density areas, or set expectations so the first experience doesn't kill retention before you hit critical mass.
Also curious — is the real-time location during a session opt-in or always-on? That's probably your single biggest trust lever with new users, especially women running alone. How you handle that could define whether this spreads or stalls.
What's the one thing you most want feedback on at this stage?
Couple things I'm curious about:
How does performance hold up when you're layering multiple capture sources simultaneously? That's usually where browser-based tools start to sweat.
Also — the "hackable rather than polished" framing is smart positioning. Are you thinking about specific use cases you want people to fork this toward? Because the talking-head + annotation combo immediately makes me think async demo videos for indie devs who can't afford Loom Pro, or lightweight sales prospecting tools. Would be interesting to see what the community actually builds with it.
One suggestion: a short screen recording (meta, I know) showing the layering and annotation in action would probably cut your "time to wow" significantly. The README explains it well but seeing the canvas manipulation live would land faster.
Nice work on this.
reply