XCTBL³ Space

Update: We listened. We tightened it. Start at RCRDBL.com.

After getting solid feedback, we reworked how people enter the system.

Instead of throwing visitors into the deep end, we rebuilt the flow so everything starts at RCRDBL.com — the briefing + record layer. It explains what this is before asking you to explore it.

What changed:

• One clear entry point (no signup, no friction)

• “Briefing first” flow

• Records and context upfront

• Less noise, more signal

If you bounced before, fair. That’s on us.

If you’re curious now, start here: RCRDBL.com

Feedback shaped this iteration — keep it coming.

I shared a build update yesterday and noticed something interesting.

People don’t react to this like a typical product. They react like it’s already operating.

There’s no launch funnel here. No polished onboarding. The system runs whether anyone is watching or not.

That’s made it surprisingly hard to talk about.

It doesn’t sit cleanly in familiar buckets:

• Not SaaS (no linear user journey)

• Not content (generation isn’t the point)

• Not tools (very little configuration)

• Not community (yet)

It’s closer to infrastructure you explore than software you adopt. I’m documenting it publicly because I’m still pressure-testing:

• how builders describe systems that don’t ask permission to exist

• whether “usable” can come before “explainable”

• and how others have handled projects that resisted neat categorization

No pitch. No ask. Just sharing the shape of the problem and continuing to ship.

If this resonates, I’m curious how you framed it when you ran into the same wall.

If not - all good. Back to work.

I’ve been working on a project called Space.

It’s not a typical SaaS and it’s not trying to be efficient in the usual ways. There’s no onboarding funnel, no dashboard-first experience, and no pressure to define everything upfront. Instead, it’s a living environment of systems that evolve publicly on a fixed cadence (the 1st and 15th).

The core idea is simple:
What if software felt discovered instead of sold?

Rather than presenting users with a feature list, Space treats systems as destinations. Some are practical. Some are experimental. Some exist mainly to be understood. Each one explains itself gradually, through use and context, rather than documentation walls.

I built this because I kept running into the same pattern in my own projects: optimize too early, explain too much upfront, and you end up building for conversion instead of curiosity. I wanted to see what happens if you reverse that — slow the system down, let it breathe, and allow meaning to compound.

Space is live, free to explore, and intentionally small right now. There’s no growth push and no monetization pressure. Some users choose to support it simply because they want it to keep existing, which I find more interesting than forcing value extraction early.

I don’t know yet if “slow, observable software” is viable long-term — that’s part of the experiment. But so far, it’s been refreshing to build something that isn’t racing toward a pitch deck or a pricing page.

Happy to hear thoughts, especially from anyone who’s tried building outside the usual SaaS playbook.

Space started as a way to test whether systems could explain themselves over time instead of front-loading documentation

I’ve been building a project called Space.

It’s not a traditional SaaS. There’s no onboarding funnel, no dashboard-first design, and no push to monetize early. Instead, it’s a living environment of systems that evolve in public on a fixed cadence (the 1st and 15th).

Users don’t configure tools - they explore them. Some systems are practical, some are experimental, some exist just to be understood.

I wanted to see what happens if software feels discovered instead of sold, and if people are allowed to decide for themselves whether something is worth supporting.

It’s live, free to explore, and intentionally slow-moving. No growth hacks. No promises. Just shipping and observing.

Happy to answer questions if anyone’s curious.