The MOLTamp roadmap: what is coming

Roadmaps are dangerous because they create expectations that bind future you to decisions that past you made under different information. So this is not a marketing roadmap with locked dates. This is a "here is what I am working on, here is what I want to be working on next, here is what is on the maybe pile" — written honestly.

In progress (likely shipping in the next 30 days)

Windows and Linux builds

The biggest single ask. MOLTamp has been macOS-only since launch because that is where I do my own work and that is where the easiest electron-builder pipeline lives. Windows builds are technically already buildable — I just have not done the polish work to ship them. The blockers are: file path handling on Windows (some places assume Unix paths), the auto-update mechanism (Squirrel.Windows vs the macOS Sparkle equivalent), and code signing for Windows binaries (which is expensive and annoying).

Linux is similar. The build artifacts work. The polish for distribution (AppImage vs flatpak vs deb vs rpm) is the unsexy work I have been putting off. Most likely we ship AppImage first because it is the lowest-friction format.

Realistic estimate: Windows in 30 days, Linux AppImage in 45 days, properly distributed Linux packages in 60-90 days.

Multi-tab session improvements

Right now each session is a separate tab and switching between them works fine, but there are gaps. Sessions do not share context, you cannot drag content between them, you cannot easily fork a session. The next iteration adds:

Session history (jump back to previous prompts within a session, like iTerm's marks)
Session forking (clone a session at a specific point and continue down a different path)
Cross-session search (find a prompt across all your sessions)
Session export (save a full session as a markdown transcript)

On deck (next 60-90 days)

Better visualizer pipeline

The current visualizer system supports a small number of preset visualizations and is awkward to extend. The next version makes it a proper plugin system — each visualizer is a self-contained iframe widget with access to the audio analyzer node. This means anyone can build a visualizer with HTML+JS, and the community gallery can host hundreds.

Real-time skin editor

Right now you build a skin by editing the CSS file in your text editor and reloading. The next iteration adds an in-app editor: open the skin settings, see live previews, drag color pickers around, watch the terminal update in real time. This is a significant UI build because the skin variable surface is large. Aiming for a basic version first and deepening over releases.

The blog publisher you are reading right now

This blog itself is built on a publisher we shipped recently. The next iteration adds: image upload, rich-text editing alongside markdown, draft preview, scheduled publishing, RSS feed generation. Probably an extra week of work.

Maybe (no committed dates)

These are ideas that are on the list but not committed to.

MCP server marketplace

MCP (Model Context Protocol) servers are how you extend Claude Code with custom tools — connections to databases, APIs, internal systems. Right now you have to manually add them to your .claude/settings.json. A built-in marketplace where you browse and install MCP servers from inside MOLTamp would be a huge unlock for the community side of the product. This is a real undertaking — needs auth, signing, sandboxing. Probably H2 2026 if it happens.

Cloud sync of skins/widgets

If you use MOLTamp on more than one machine, you want your skins, widgets, layouts, and configurations to sync. Right now there is no cloud sync — each machine is independent. Adding sync requires a backend, account management, and conflict resolution. The infrastructure is ready (we already have user accounts for the community marketplace) but the actual sync logic has not been built.

A mobile companion app

For glanceable status from your phone — what is your agent currently doing, did the build finish, did Claude finish refactoring those files. Not for mobile coding, just for awareness. Niche but cool. Definitely a maybe.

Themes for the website itself

The moltamp.com website currently has its own design that does not match any of the in-app skins. A nice touch would be to let visitors pick a theme for the website that matches one of the in-app skins. Pure vanity. Low priority. Will probably never ship but I keep thinking about it.

What is NOT on the roadmap

To save anyone the trouble of asking:

Built-in agent / model — MOLTamp will always be a shell around other agents, not its own agent. Building an in-house model is not what this product is for.
Mobile or tablet versions of the main app — same reason. The phone is not where serious agent work happens.
Free Pro tier — the $20 license is the entire monetization story. There will not be a free Pro tier.
Subscription model — same reason. One-time purchase forever.
Removing the free tier — the free tier with the periodic nag is staying. That is the point.

How to influence the roadmap

The best way to push something up the priority list is to use MOLTamp daily and tell us what bothers you. The roadmap reflects what users actually run into, not what I imagine they run into. Active community members shape the roadmap more than they realize.

Specific channels:

GitHub issues — the most formal way to file requests and bugs
Discord — the casual way; #feature-requests is the right channel
Twitter — works but does not get tracked as well as the above

The honest part

The roadmap above is what I am thinking about today. Six months from now the priorities will be different because what users actually need will be different from what I currently imagine. I will update this post when things change. Treat it as a snapshot, not a contract.

The thing I am actually trying to build is a tool that you want to use every day, not a tool that hits an arbitrary feature checklist. If a feature on the roadmap turns out to be the wrong call, I would rather drop it than ship it just because I said I would.

That is the deal.