Like most of you here I got tired of other solutions that just never did what I needed them to, asked too much or pivoted in a direction that didn’t suit my needs anymore. I’ve been building many products lately, most of them being macOS and iOS apps, and I needed some basic reporting that keeps privacy at a focus, but provides useful product telemetry and feedback. I’m starting the build tonight, and will post updates as I have them.

The idea is simple, and like most of my products, I open source the engine, and build a saas for people that don’t want to manage the engine or set up (same as https://citeworthy.io operates).

If you develop macOS or iOS apps and have ideas for what you want to learn and understand from your users, this is for you, and I’ll happily give free SaaS seats to anyone that helps me test or starts to use the product early.

This is my first build in public post, so I’ll follow it up with other posts and link to the earlier ones for history.

So, let’s get to it. First step - the open-source package swift-stats. Watch it come to life here: https://github.com/awizemann/swift-stats

Just wanted to thank this community for all their feedback, feature requests, and support for Scarf, the open-source macOS Hermes GUI. I started building this very early in the Hermes days, before they even had a web interface. It's now very mature and used by thousands on a daily basis.

https://github.com/awizemann/scarf

Keep the feedback coming, and I am always open to issues, PRs, feedback and requests!

All joking aside, it was a minor issue that the mechanic fixed in 5 minutes. A wire came off the ignition coil/relay. I thought I checked, but that’s why you have good mechanics. Getting new oil and a few minor things to justify the tow.

This is the second version of a 6-month endeavor to replace several tools I use to scan, organize, and find the over 8,000 PDFs that have followed me through life: tax returns, warranties, medical records, bank statements, and more. I pretty much scan everything I need to keep, and went paperless years ago. Scanning, storing, organizing, and reading private documents like this, stored on your own machine, with no data ever leaving it, were table stakes. It has been thoroughly tested, security-audited, and developer-signed and sealed.

Because of the scanner work, natively driving ScanSnap scanners without the need for any third-party applications, it has been a struggle to get Apple to approve the application for App Store distribution, as their "app sandbox" creates issues with some scanners (it fully works with the iX1300, but I only own that scanner, so I need other users to test their scanners with it). You can use it across multiple machines with iCloud syncing, and rest assured, it ONLY uses your iCloud setup and only if you want to sync; there are no servers, no telemetry, no tracking... I don't even know if you are using the application except when it is downloaded and when Sparkle runs to get an update. Even then, I just get a cryptic "ping".

This will be a paid application (one-time, $24.99), but testers and people who genuinely love it and talk about it (post a public review, etc.) can get it for free, because I know many out there have suffered with the same issues I have for years.

Grab a copy now here (https://shabubox.com) by downloading the 30-day, fully functional trial. If you send any feedback that improves the application, or fall in love with it and post about it, it's yours for free.

Enjoy, battle-test it, scan with it, and organize your files with it.

I figured I would post this here, and some of you would get a kick out of it. I have been working on my personal site, and it has grown considerably. I notoriously suck at SEO, so I built a tool that can help me with it. It is still early, but proven in production on my site (and now several others). The next version will include refinements, expanded MCP access, and AEO/GEO features.

If anyone wants to kick the tires and give me feedback to improve it, I would appreciate it. It is free, open-source, MIT-licensed, and I would like to make it better for myself and others.

https://github.com/awizemann/seo-agent

After two years of a custom build by CJ International, this black beauty is on its way from the UK to me. I hand-selected everything, and the entire concept was stock, but way better. They delivered 100%. I test-drove it in the UK before it departed via ocean transport. I’ll update the group when she lands.

For the curious: fully rebuilt from the chassis, all numbers matched to the heritage certificate. 1999 TD5 with a factory, programmable automatic transmission (don’t judge, I have a manual 300tdi already, and wanted a daily driver).

I'm the solo dev behind this, so flagging the self-promo up front.

The problem I kept hitting: every new agent session starts blind. CLAUDE.md and .cursor/rules files grow, go stale, get truncated, and quietly rot, and there's no good way to tell when a note no longer matches the code.

So I built Memophant, a native macOS app that keeps project memory as plain markdown inside your git repo and exposes it to any agent through a bundled MCP server. Git is the source of truth. The app is just a fast native UI on top, and the MCP server is how your editor actually reads it.

What the MCP server exposes (a few of the tools):

• search_memories: hybrid search over an atomic knowledge graph of facts and decisions
• search_code: queries a SQLite-indexed symbol map of the repo (Swift today, more languages coming)
• write_memory: agents propose durable notes, you approve them per item
• plus tools for the wiki, tasks, sessions, design notes, and a vendor registry where secrets stay in your Keychain and reads happen behind a one-click approval

Because it's MCP, the same memory is wired into Claude Code, Cursor, Codex, and Gemini without copy-paste. One detail I care about for this crowd: every note records the commit it was written against, so when the code drifts the note flags itself as stale instead of silently lying to the next session.

It's a one-time $49.99 license with a 30-day trial, no account, no cloud (your Anthropic key, used only for the in-app AI actions, lives in the Keychain). It is out now, not a waitlist.

Site with the full tool list and screenshots: https://memophant.co

I'd genuinely like feedback from people who run a lot of MCP servers: does the per-tool approval model feel right, and what would you want a memory server to expose that mine doesn't?

I have been building two commercial applications over the past several months (along with a few open-source ones) and realized that I didn't want to use an existing support platform or just rely on email. I already had great workflows for my GitHub Issues, so why not leverage that? That's why I built GitTickets, A drop-in Swift package (macOS 13+ / iOS 16+) that gives any app a "Report an Issue / Feature Request" surface backed by the app's own GitHub repository Issues.

End-users get a native form, screenshots, diagnostics, and a privacy banner. Submissions land directly as issues in your repo. Users browse their past submissions and see your replies as a thread, inside the app.

I just tagged the first version, after testing end-to-end on an app I will be releasing soon.

https://github.com/awizemann/GitTickets

Feel free to kick the tires and let me know if you find anything. As always, a star is appreciated.

The problem I kept coming back to: when you buy software from a solo dev, you're betting they stick around. If they don't — burnout, life, a pivot — the app stops getting updates and you never see the source. You're stuck with a dead binary.

So I drafted a license to fix that. Short version: the software is a normal paid/commercial product while it's maintained. But if the developer goes dormant — no commits or releases and no support response for 12 months — the full source automatically publishes under MPL-2.0, for everyone, permanently. I'm calling it the Heirloom License.

It's basically BSL/FSL, except the trigger is abandonment instead of a fixed calendar date. The conversion is delivered by a GitHub Actions dead-man's switch: if you stop checking in, it flips the private repo public and swaps in the change license.

A few deliberate choices:

• Copyleft on sunset (MPL-2.0), not MIT — so nobody can grab the abandoned code and re-close it. The commons stays open.
• Public on sunset, not "purchasers only" — keeps it enforceable and dodges a verification nightmare once the dev is gone.
• The license text is CC0; only the name and badge are reserved.

I want to be honest about the limits, because pretending otherwise is the whole problem this is trying to solve: a license is a promise, the switch is just the delivery. The switch can be defeated (delete the account, disable Actions). So the contract is the binding part and the automation is good-faith on top. That's stated plainly in the docs.

It's v1.0-draft, not lawyer-reviewed yet — I've filed the open legal questions as issues so they're public. Repo has the license text, a plain-English summary, the reference switch, and a setup guide: https://github.com/heirloom-license/license

What I'd genuinely like torn apart:

• Where does the dormancy trigger break? (dev on medical leave for a year, say)
• Is "public on sunset" the right call, or should prior purchasers get a head start?
• Biggest legal hole you see in a self-executing, conditional grant like this?

(Disclosure: I wrote it, and my own Mac app will be the first to use it.)

I am building several applications (and have a few open-source ones in the wild), including Scarf and Harness, under https://github.com/awizemann. I have been interested in buying a few new applications that have shown up here, but the worry I have, and shared by many, is what happens if these projects are abandoned. Is there validity in creating or using a policy that the developer can publish, stating that if it goes unsupported, it will be open-sourced? Interested to hear your thoughts.

Hey FOSS! I'm Alan, I'm a developer that has been building Mac, iOS and web applications for over 30 years. Recently, I started a few Open Source projects and ran into the age old problem of user testing....

Developers have always been plagued by a problem: how do you user test when your application isn't ready for distribution yet? How do you maintain consistent user testing with different user personas after your application is released? This is the same issue regardless of platform, Mac, iOS or Web - so I built Harness.

Not a UI test. A user test. Harness is a native macOS dev tool that drives your iOS Simulator, your macOS app, or a web app the way a real user would. You write a goal in plain English and pick a persona; an LLM agent reads each screen, decides what to do, and pursues the goal — tapping, typing, scrolling, navigating. When something is confusing, ambiguous, or a dead-end, the agent flags it. Every run produces a replayable timeline of screens, actions, and friction events you can scrub through later. No accessibility identifiers, no source-code access, no pre-written plan — the agent reasons from what's on screen.

Free and Open Source!

I hope you like it. Feel free to review the code, play with the application, and let me know what features or functionality you might want to add to make it better.

For more information, please check out:
https://awizemann.github.io/harness/

Or grab the latest release, fully signed universal binary:
https://github.com/awizemann/harness/releases/tag/v0.3.1

The open source Hermes Agent GUI is growing up. The project based model that supports graphical dashboards, integrated and embedded web sites for each project, now also supports per-project KanBan boards, bringing the project based management of Scarf fully up to date with Hermes, but with even more per-project power.

Grab the latest today, signed binaries are available here:
https://github.com/awizemann/scarf/releases/tag/v2.7.5

A new iOS build is coming soon (in TestFlight).

Here are the full release notes:

What's in 2.7.5

A feature release that lifts Scarf's Kanban surface from a read-only list (the v2.6 placeholder shipped while upstream Kanban was still mid-rework) to a full drag-and-drop board with the complete Hermes v0.12 mutation surface wired up — plus per-project boards bound to a Scarf-minted tenant slug, and a read-only board on iOS for at-a-glance status from your phone. No data migrations, no schema changes; pre-v0.12 hosts gracefully hide the surface.

New features

Mac

• Drag-and-drop Kanban board (scarf/Features/Kanban/Views/KanbanBoardView.swift). Five visible columns — Triage / Up Next (todo + ready) / Running / Blocked / Done — collapsing Hermes's seven status values into a layout that doesn't waste space on ready, which the dispatcher only ever holds for a few seconds. Triage hides itself when empty; archived hides behind a header toggle. Drop a card onto a column and Scarf maps the gesture to the right Hermes verbs through a pure transition planner: drop-on-Running fires kanban dispatch (the dispatcher then spawns a worker), drop-on-Blocked opens a sheet asking for a reason and calls kanban block, drop-on-Done opens a result sheet and calls kanban complete, blocked → running chains unblock + dispatch. Forbidden transitions (anything dropped on Done; anything dragged out of Triage) reject with a red drop-target stroke and a tooltip explaining why — Done is terminal, Triage is promoted by a specifier worker, neither has a CLI verb that maps cleanly. Optimistic local updates apply on drop and revert on CLI failure with a toast, so the UI feels instant.
• Side-pane inspector (KanbanInspectorPane.swift). Click a card and a 420 px pane slides in from the trailing edge. Not a modal sheet — modal would block triaging the next card after closing. Header carries the status, an inline assignee menu (more on that below), workspace kind, and tenant; below that, four tabs render hermes kanban show <id> data: Comments (with an inline composer that calls kanban comment), Events (the task_events log with per-kind glyphs), Runs (one row per attempt with outcome badge + summary + error), and Log — the worker's captured stdout/stderr from hermes kanban log <id>, polled every 2 s while the task is running with a "● streaming" indicator and auto-scroll to the latest line, snapshot-only with a refresh button when the task is in a terminal state. The action bar at the bottom has all the per-status verbs — Start (which is claim rebranded as a user-visible action), Complete, Block, Unblock, Archive — every one with a help tooltip explaining what it does and what Hermes verb it invokes. The "Archive" tooltip explicitly notes Hermes has no hard-delete: archived tasks remain in ~/.hermes/kanban.db and are recoverable via the "Show archived" toggle until hermes kanban gc runs.
• Inspector auto-refresh. While the inspector is open, the detail (header, action buttons, comments, events, runs) re-fetches every 5 s on the same cadence as the board itself, so a worker transition (e.g. running → done elsewhere) is reflected without the user having to close + reopen. The Log tab's 2 s poll runs separately and self-cancels the moment the task transitions out of running.
• Inline assignee picker on the inspector header. The assignee badge is a clickable menu — set means a .brand (rust) chip, unassigned means a .warning(yellow) chip so the eye catches it instantly. Tapping opens a menu of every known profile (union of ~/.hermes/profiles/, current task assignees, and the active local profile from HermesProfileResolver) plus an "Unassigned" option. Selection routes through kanban assign and immediately follows with kanban dispatch so the task gets picked up promptly. Solves the "I assigned a profile but nothing happened" gap end-to-end without the user touching a terminal.
• Health banner in the inspector. Surfaces two conditions that previously left users staring at a stuck task with no explanation. Yellow when the task is unassigned in ready / todo: "Won't run automatically — Hermes's dispatcher silently skips tasks with no assignee." The dispatcher's own --json output literally lists these under skipped_unassigned; we now surface that to the human. Red when the most-recently-completed run ended in a non-success outcome (stale_lock / crashed / gave_up / timed_out / spawn_failed / reclaimed / failed): banner displays the outcome label + the raw errorfield from the run record, so you don't have to dig into the Runs tab to discover it. The red banner is suppressed while a fresh attempt is running — once status flips back to running, the previous outcome is stale signal and the Log tab's live stream is the right thing to look at.
• Card-level signals. Cards in running get a 2 px ScarfColor.info left edge + a subtle title shimmer so live work is obvious at a glance. Blocked cards get a 2 px ScarfColor.warning left edge + a ⚠ glyph next to the title. Done cards dim to 0.7 opacity in light mode, 0.55 in dark, with a green ✓ in the title row. Cards in ready / todo with no assignee get a yellow ⚠ glyph in the title row with a tooltip explaining the dispatcher won't pick them up — same signal as the inspector banner, just at the board level so triage is one keypress away.
• Board | List toggle at the top of the route. The v2.6 read-only list view is preserved in KanbanListView.swift and surfaced via a segmented picker, so users on narrow windows or anyone who prefers a flat sortable list can opt in. Choice persists across launches via u/AppStorage.
• New Task sheet (KanbanCreateSheet.swift). Title, body (markdown supported), assignee (defaults to HermesProfileResolver.activeProfileName() so newly-created tasks actually run), workspace kind (segmented Scratch / Worktree / Project Dir; locked to Project Dir on per-project boards), priority slider, comma-separated skills with autocomplete from ~/.hermes/skills/, optional tenant (hidden on per-project boards — the slug is implicit), and a "Send to triage" toggle. Submit fires kanban create --json and immediately follows with kanban dispatch so an assigned task transitions ready → runningwithin seconds rather than waiting for the gateway dispatcher's internal cycle.
• Kanban moved from Manage → Monitor in the sidebar. It's runtime work-in-progress, not configuration. Sits between Activity and the rest of Manage so users see "what's happening right now" at a glance.

Per-project Kanban

• DashboardTab.kanban on every project, capability-gated on HermesCapabilities.hasKanban. Renders a project-scoped KanbanBoardView filtered to the project's tenant slug. Workspace defaults in the New Task sheet are pre-pinned to dir:<project.path>. Empty state explains the project doesn't have any tasks yet and offers a "New Task" CTA — the empty board IS the discovery surface.
• Tenant minting via KanbanTenantResolver. Each Scarf project gets a stable scarf:<slug> tenant minted on first kanban interaction and persisted to <project>/.scarf/manifest.json (new optional kanbanTenant field on ProjectTemplateManifest). Slug rules: lowercased, hyphenated, ≤ 48 chars, scarf: prefix to avoid collision with hand-typed tenants. Once minted, the tenant is immutable across rename — tasks already on the board carry the original slug, so renaming the project doesn't orphan them. Bare projects (no manifest) get a sentinel manifest written with id: scarf/<project-id> + version: 0.0.0 + just the kanbanTenant set; the ProjectAgentContextService reader recognizes the sentinel and refuses to surface it as a "Template" line in the AGENTS.md block, so the project doesn't suddenly start advertising a fake template to the agent.
• Agent-side tenant injection. ProjectAgentContextService.renderBlock emits a "Kanban tenant" line inside the <!-- scarf-project --> markers in <project>/AGENTS.md whenever a tenant exists, instructing the agent to pass --tenant scarf:<slug> on hermes kanban create. ChatViewModel.startACPSession already calls refresh(for:) before opening every project chat, so the agent reads a fresh tenant on every session start with no extra wiring. Agents are imperfect at flag discipline; a forgotten --tenant lands the task in the global "Untagged" group rather than failing — acceptable v2.7.5 behavior.
• kanban_summary dashboard widget (KanbanSummaryWidgetView.swift). New widget kind for project dashboards: shows the top three running / blocked / todo tasks for the project's tenant by priority, plus a glance footer ("12 todo · 3 running · 5 blocked") sourced from kanban stats. Polls every 10 s while the dashboard is foregrounded. Widget vocabulary registered in tools/widget-schema.json and rendered on the catalog site via site/widgets.js; template authors can drop a { kind: kanban_summary, max_rows: 3 } block into dashboard.json.

iOS / iPadOS

• Read-only Kanban tab on ProjectDetailView (Scarf iOS/Kanban/ScarfGoKanbanView.swift). Same five-column collapse rendered as a horizontally-paged segmented Picker of single-column lists — HIG-friendly on iPhone where a 5-column grid forces unreadable card widths. Pulls live status, assignee, workspace, skills, priority chips. Tap a card → modal NavigationStack detail sheet (ScarfGoKanbanDetailSheet.swift) with the same Comments / Events / Runs tabs the Mac inspector has. Read-only in v2.7.5 — mutations + drag-drop on iPad land in v2.8 once the Mac flow is fully shaken out. Card titles use semantic .headline (not ScarfFont) so Dynamic Type works; chrome (badges) stays on ScarfBadge for fixed visual weight per the project's iOS conventions.