Building the foundation Spixor actually needs

In our previous update, we talked about gradually returning to a more consistent rhythm of visible Spixor updates.

Since then, we have continued working on the systems behind Spixor — and that work has made something increasingly clear:

We underestimated how much of Spixor's foundation still needed to be properly built.

That is something we want to be open about.

Spixor works. The Builder works. Projects can be created, edited and exported. Many of the individual pieces are already there.

But as we started preparing for the next stage of development, we repeatedly ran into the same underlying problem.

We would improve one part of Spixor, only to discover that another part first needed to be changed before the original work could safely move forward.

A change in one area could depend on older code somewhere else. A seemingly isolated improvement could require broader testing than it should. Some parts of Spixor have also gone through several generations during Alpha, which means older and newer systems can still exist alongside each other.

That makes development slower, harder to validate and more difficult to release independently.

For an early Alpha product, that is understandable.

For the Spixor we want to build, it is not good enough.

And we do not want to normalize it.

So we're changing our focus for the rest of 2026

We originally aimed to work back towards a weekly update cycle.

For now, we are letting that target go.

This does not mean development is slowing down. In many ways, the opposite is true.

It means that for the remainder of 2026, we are prioritizing the work that will allow Spixor to grow properly in 2027 and beyond — even when that work is not immediately visible inside the product.

We would rather take the time to build the right foundation now, while Spixor is still in Alpha, than continue adding features on top of a structure we already know will eventually hold us back.

Updates will return when the work is ready to be released.

Not because a week has passed.

Breaking Spixor into clearer parts

One of the biggest changes we are preparing is a more modular structure for Spixor.

Today, parts of the product can still be more connected than we want them to be. Over time, we want areas such as the Builder, Dashboard, File Manager, project systems and other core functionality to have much clearer responsibilities and boundaries.

The goal is simple:

Improving one part of Spixor should not require rebuilding half of Spixor around it.

This will not happen through one large rewrite.

We are deliberately taking the slower and safer route: understanding what exists today, identifying dependencies, preserving current behaviour where necessary, and improving one area at a time.

Some older systems will need to be cleaned up. Some will need to be replaced. Others may simply need clearer ownership.

That process will also naturally lead to visual improvements across parts of the Dashboard and Builder, but a redesign is not the main reason we are doing this.

The bigger goal is to make Spixor easier to understand, maintain, improve and test.

Building our own framework

Another major part of this work is the foundation underneath the Builder itself.

Spixor currently still relies on technologies and patterns that were useful while getting the product started, but they do not give us the level of control we want for the future.

We are therefore continuing work towards our own Spixor framework.

This is not simply about replacing one CSS framework with another.

The framework will eventually define how Spixor understands layout, responsiveness, spacing, structure, styling and other behaviour inside the Builder.

That makes it one of the most important technical and product foundations we will build.

And we do not want to rush it.

We are researching how modern creative tools solve common problems, looking at publicly available websites, documentation, user experiences and real-world output across the wider website-building space.

The goal is not to copy another platform.

It is to understand what works, what users struggle with, what modern website creation requires, and then decide what the Spixor way should be.

Research alone is not enough either.

The framework and Builder experience will need repeated testing, real website builds and refinement before we consider them ready.

If something technically works but still feels difficult to use, it is not finished.

Making Spixor feel like a real creative tool

This is something we have also experienced ourselves.

Building a complete website in Spixor today is possible, but it does not always feel as clear, responsive or natural as we want a creative tool to feel.

That matters.

If we know how Spixor works and still encounter friction while creating a real website, it is reasonable to assume that a completely new user can encounter even more.

That is one of the most valuable things Alpha can show us.

So instead of only asking whether a feature exists, we are increasingly asking:

Can someone actually use it comfortably as part of a complete website-building workflow?

That will become an important standard for future Spixor development.

Introducing Spixor Forge

A large part of the work happening behind the scenes is centred around Spixor Forge.

Forge is an internal engineering, validation and release system we are building specifically for Spixor.

It is not a new Builder feature and it is not something regular Spixor users will need to interact with.

Its purpose is to give us a much stronger way to understand, develop, test and eventually release Spixor.

Over time, Forge is intended to help us:

• understand which parts of Spixor belong together;
• work on individual modules in more controlled environments;
• validate changes before they reach the complete Spixor release;
• detect dependencies and older systems that may otherwise be easy to miss;
• handle bug fixes and urgent releases more safely;
• better understand the health and behaviour of Spixor;
• and prepare the product for much faster development as it grows.

An important part of this is visibility.

Today, our internal systems can tell us some basic things — for example that an account was created, an email was verified or a project exists.

That is not enough.

We want to better understand the journey through Spixor itself.

Did someone create a project but never open the Builder?

Did they open the Builder but never make a first edit?

Did they build for twenty minutes and then leave?

Did an export suddenly start failing more often than usual?

Are file uploads increasing rapidly?

Are more Builder sessions active than normal?

These are important signals, both for understanding where users struggle and for keeping Spixor healthy as usage grows.

The goal is not to collect unnecessary information about what people create.

It is to understand how the product is being used, where workflows stop, where technical problems appear and where Spixor needs our attention.

That should help us improve Spixor based not only on direct feedback, but also on what actually happens during real use.

Preparing for growth before we need it

Spixor is still small today, and our current infrastructure is more than capable of supporting where we are.

But growth is not always predictable.

A product can remain small for months and suddenly receive significantly more attention in a very short period of time.

We do not want the first day of major growth to also be the first day we start thinking about how Spixor should scale.

Part of the foundation work therefore includes preparing Spixor so that future infrastructure changes — such as caching, CDN usage, stronger servers or distributing workloads — do not require us to first redesign the entire product.

That does not mean building expensive infrastructure we do not need.

It means making sure we understand what the next step is before we need to take it.

Free, Orbit and the future of Spixor

This foundation is also important for the future of Orbit.

Our goal remains for the core Spixor Builder to be genuinely usable for free.

Spixor is Export First. We want users to be able to build something and actually take their work with them.

We do not want a trial that becomes unusable after a few days, and we do not want publishing lock-in to be the only reason someone continues paying.

Orbit needs to earn its place by offering more capacity and professional capabilities to people who use Spixor more seriously.

Before we launch it, however, Spixor first needs to be strong enough to function as the complete creative tool we want it to become.

That is another reason we are choosing foundation over speed right now.

2026 is our foundation year

We have ambitious plans for Spixor.

But ambition without a strong enough base simply creates more things that become difficult to maintain later.

So for the rest of 2026, we are intentionally changing how we measure progress.

There may be periods without a visible Spixor release.

There may also be smaller updates when something is genuinely ready and makes sense to release.

But we will no longer ship simply because we are trying to maintain a weekly schedule.

Our focus is on making sure that when we move into 2027, we are doing so with a much stronger product underneath us:

A Builder that can continue becoming a serious creative tool.

A clearer and more modular codebase.

A framework we control ourselves.

Better testing and release systems.

Better insight into how Spixor is actually being used.

A safer way to respond to bugs and reliability problems.

And a foundation that can grow with Spixor instead of needing to be replaced every time Spixor reaches a new stage.

We originally thought we were closer to having most of those boxes checked.

Working through the details showed us that we were not.

That is exactly why Alpha exists.

We would rather recognise that now, be honest about it and build it properly.

The work happening today may be less visible than a new Builder feature.

But we believe it is some of the most important work we can do for the Spixor we want to release tomorrow.

Thanks for continuing to build with us during Alpha.

— Spixor