We’re still here — and Forge is starting to become real

It has been almost two weeks since our last update, so we wanted to share a small look at what has been happening behind the scenes.

There is no big new Spixor feature to announce today.

And, for once, that is actually a good thing.

In our previous update we talked about spending the rest of 2026 strengthening the foundation underneath Spixor instead of trying to force a constant stream of visible releases.

That work has continued, and a lot of our attention recently has gone into Spixor Forge.

Forge started as an internal idea: give ourselves a better way to understand what belongs where in Spixor, what depends on what, what is safe to change, and what still needs a decision before development can continue.

It is now becoming something much more practical.

Turning a roadmap into something we can actually work from

One of the problems we have been trying to solve is that a roadmap can look organised while development itself is still messy.

A feature might have a clear name, but that does not automatically answer questions such as:

• What exactly is this feature responsible for?

• Which existing behaviour needs to be preserved?

• Which requirements have actually been agreed on?

• How do we know when the work is finished?

• Which part of Spixor is allowed to change?

• Does another part of the product already own that responsibility?

• Does something still need a decision before development should start?

We have been building those questions directly into Forge.

Instead of simply having a list of things we want to build, Forge is gradually becoming a place where a piece of work moves through a more deliberate process:

definition → requirements → product work → acceptance criteria → execution

That probably sounds much less exciting than a new Builder feature.

But it solves a problem we have repeatedly run into during Alpha: starting work before enough of the surrounding product decisions were actually clear.

We have also been testing the process on real Spixor work

We did not want to design this system in isolation.

So we have been using real parts of Spixor to test it, including areas of the public website and parts of Forge itself.

That has already exposed several places where our own internal process was not strong enough.

For example, we found situations where a decision had technically been made, but was not carried forward clearly enough into the next stage. We found cases where something could look “ready” according to a simple technical check while still missing important context.

We also found that the information an developer would receive was sometimes much shallower than the information a reviewer of the work could see. Those are exactly the kinds of problems we want to find now.

Not after Spixor is much larger.

The next step: making Forge actually execute the work

This is the part we are working towards now.

Forge already helps us structure and validate work.

The next step is for it to also become the place where that work can actually be carried out by the developers we use.

We want Forge to know:

• what has been approved;

• what the developer is allowed to work on;

• what must not change;

• what the expected result is;

• how the work should be split into smaller steps;

• when the developer should continue;

• when it should stop;

• and when a decision genuinely needs to come back to us.

We are currently building the concept of a persistent Mission inside Forge.

A Mission should be able to continue independently from a browser tab or individual developer. If one execution attempt reaches a limit, temporarily loses capacity or needs to continue later, the overall Mission should still exist.

That also means we are working towards seeing things such as:

Ready to execute
Running
Waiting
Needs You
Validation
Completed

directly inside Forge.

Eventually, we want to be able to open Forge, see what needs attention, review what an develoepr is doing, start the work and follow its progress without manually coordinating several separate tools.

Forge is not finished.

The new execution workflow is not finished.

The broader Spixor restructuring is not finished.

And we are deliberately not pretending otherwise.

But the difference compared with a few weeks ago is that the foundation is becoming much more concrete.

We are no longer only talking about how we want development to work.

We are starting to build the system that should let us work that way.

And once that system is strong enough, the goal is simple:

spend less time managing the process of building Spixor, and more time actually improving Spixor.

More soon.

- Spixor