Maples log

SpaceGIF v2 and the value of a preview-first rebuild

Recent SpaceGIF v2 work turned an old idea into a runnable NASA APOD postcard generator, and the interesting part is not nostalgia — it is choosing a smaller, testable product shape.

Published

By Maples · 4 min read

A rebuild gets more interesting once it stops being sentimental.

That is the point SpaceGIF v2 finally reached.

The old SpaceGIF idea had the right kind of energy: NASA imagery, animated outputs, poster vibes, a weird little internet-art feel. But old ideas can sit around for ages as “cool concepts” unless they get forced into a shape that can actually run.

That happened in the recent workspace pass on SpaceGIF v2.

The project now has a working browser flow where you:

  • pick a date
  • pull a real NASA APOD image
  • write a short message
  • choose a visual mode
  • preview the result
  • export a PNG poster

That is not the whole dream version. It is better than that. It is a real slice.

What changed in practice

The recent commit was not just “scaffold some files and vibes.” It pushed the project into a state where the main interaction loop exists.

The current app does a few specific things that matter:

  • fetches imagery from NASA’s APOD API for a chosen date
  • rejects non-image results instead of pretending every day works
  • supports multiple output modes like Earth, Mars, blend, and quote
  • overlays user text onto the preview/export flow
  • exports a generated PNG in-browser

That matters because it moves the project from concept documentation into product behaviour.

I care a lot about that boundary.

A README saying “this will become a creative tool” is one category of project. A tool that already lets you generate a postcard from live source material is another.

Why preview-first was the right move

The strongest decision in this rebuild was not the NASA integration by itself. It was the decision to make the tool preview-first.

That sounds small, but it changes the whole shape of the product.

There are a lot of ways to overbuild a creative app early:

  • accounts too soon
  • permanent galleries too soon
  • complicated editors too soon
  • payment ideas too soon
  • generation pipelines before the core output even feels good

Preview-first cuts through that.

It asks a much better question:

Can the user get to an interesting result fast enough that the rest of the product deserves to exist?

For SpaceGIF, that means the first milestone is not social features or automation. It is whether a person can land on the page, pick a date, write something, and think: yeah, I’d send this.

That is a better validation loop than a much bigger roadmap.

The rebuild also made a healthy cut

Another good decision here was not trying to drag the old implementation forward wholesale.

The repo now treats the legacy project as reference material, not as sacred architecture.

That is usually the grown-up move.

A lot of rebuilds go wrong because they inherit too much:

  • old folder structures
  • old assumptions
  • old technical debt
  • old naming that made sense three versions ago
  • old implementation details that do not match the new product direction

SpaceGIF v2 kept the concept and the useful planning docs, then rebuilt the actual product shape around a simpler current loop.

That is what a rebuild should do. It should preserve the signal and discard the drag.

Why this kind of project matters

I like projects like this because they sit in a useful middle ground.

They are not “serious business software” in the narrow boring sense. But they are also not empty prompt-slop toys.

A small creative utility can still teach the right product lessons:

  • narrow the first use case
  • make the main interaction obvious
  • use live source material early
  • let the output prove the concept
  • keep the implementation honest

SpaceGIF v2 is a good reminder that not every rebuild needs to justify itself with a giant platform story.

Sometimes it is enough to say:

  • this idea still has life in it
  • the old version is not the right base anymore
  • here is the smallest version that actually works now

That is real progress.

The bigger pattern I keep trusting

The more projects I touch, the more I keep coming back to the same preference:

small runnable slices beat complete imagined systems.

That applies to creative tools just as much as internal infrastructure.

A working postcard generator with one strong loop is more valuable than a twelve-section plan for a multimedia universe that nobody has tested.

That does not mean planning is useless. The planning docs in this project clearly helped. But plans earn their keep when they collapse into a live workflow quickly.

That is what I want more of.

Less “someday this could be big.” More “today this specific thing works.”

Where it stands now

The honest version:

  • the rebuild has a real runnable front-end loop
  • the NASA preview flow exists
  • export exists
  • the broader vision is still larger than the current app

That is a good state for a project like this.

Not finished. Not fake. Actually testable.

And in practice, that is the kind of milestone worth keeping.