Cover image for Shipping Software Is Harder Than Building It

Baaqar Naqi

When I published v2.0.0, I thought the hard part was over.

The CLI could turn Claude artifacts into native Windows applications in a single command. It worked on my machine, the demos looked great, and I was excited to share it.

Then people started using it.

That's when I realized the difference between building software and shipping software.

The bugs only users can find

Most of the problems weren't visible in a five-minute demo.

Some applications worked perfectly.

Others silently lost all of their data after being closed.

Some builds succeeded exactly once.

The second build failed unless the runtime cache was manually deleted.

Everything looked correct...

until someone actually tried using it.

The rabbit hole

What I thought would be a quick patch became a deep dive into things I'd never touched before.

Over the course of v3 I ended up learning far more than I expected:

  • Git branching and release workflows
  • Semantic versioning
  • GitHub Actions
  • npm packaging
  • npm pack
  • Runtime integrity verification
  • SHA-256 checksums
  • Neutralino runtime management
  • JavaScript debugging
  • Integration testing

None of those were part of the original project idea.

Persistent storage finally works

This was the biggest challenge.

Artifacts using localStorage behaved differently depending on where they were running.

Inside Claude everything worked.

Inside the generated desktop application...

not always.

Tracking this down took far longer than writing the original feature.

The result is that applications now persist their data correctly across launches without requiring any code changes.

If your artifact uses localStorage, it should simply work.

Runtime improvements

The runtime layer also received a major overhaul.

Version 3 now handles:

  • automatic runtime downloads
  • integrity verification
  • cache recovery
  • consecutive builds without manual cleanup

Those aren't exciting features to demo, but they're exactly the kinds of improvements that make a tool feel dependable.

Better testing

I also spent a lot more time writing tests than writing features.

The project now covers:

  • React artifacts
  • HTML artifacts
  • Tailwind
  • CSS imports
  • image imports
  • unsupported imports
  • rebuilds
  • persistent storage

That gave me much more confidence when fixing bugs, because every change could be verified instead of hoped for.

AI didn't replace engineering

This project started because of AI.

Ironically, the hardest parts had very little to do with generating code.

The difficult work was understanding why something behaved differently after packaging, reproducing bugs, reading logs, and validating fixes.

AI made me faster.

It didn't remove the need to understand the system.

Looking ahead

Version 3 isn't the biggest release in terms of new features.

It's the release that made me comfortable recommending the project to other people.

Sometimes the most valuable release isn't the one that adds the most.

It's the one that makes everything you already built reliable.

If you've been following the project since v1 or v2, thank you for trying it, reporting bugs, and helping shape this release.

You can find the project here:

I started this project thinking AI would let me build software without learning the messy parts. Instead, it pushed me straight into them. Somewhere between broken CI pipelines, checksum mismatches, runtime bugs, and release engineering, I realized I'd accidentally learned more about shipping software than I ever planned to.