Saúl Martí_

It started as a way to verify coding-agent work and keeps expanding into the workflow around it.

I’m trying to make coding agents predictable enough to trust without pretending the models themselves are deterministic.

The project keeps moving toward a stricter system for planning, implementation, evidence, review and cost control.

Better models don't remove the need for better process.

Deterministic structure matters most when the system itself is unpredictable.

Evidence, cost and handoffs matter as much as code generation.

The system grew too quickly once memory, tools, users and context all had to work together.

The architecture needed more research before it made sense to keep adding features.

SpecRail became the more focused problem worth solving first.

Agent systems get complicated very quickly once memory, tools and users interact.

There was no blocker. I just stopped caring enough to keep pushing it.

Organizing information well can matter more than adding features.

The idea kept expanding until maintaining an entire editor ecosystem became the project.

A full Code-OSS fork was too expensive to maintain for the questions I actually wanted to explore.

Building the whole product is not always necessary to validate the idea.

Maintaining an IDE is an ecosystem problem, not just an editor problem.

AI-native workflows matter more than owning the entire IDE.

Recreating the atmosphere required far more art, animation and content than expected.

Visual identity can be as expensive as gameplay.

Recreating a feeling is harder than recreating a mechanic.

The core idea worked, but the generated experience was not good enough to justify the complexity.

Existing products already solve much of the problem, so it needs a much stronger angle before I keep building.

The cost of generating high-quality audio made the idea harder to justify as a side project.

Turning information into audio is easy. Making the audio worth listening to is not.

Existing products raise the bar: a side project needs a real angle, not just the same feature.

The scope kept expanding until it became closer to a personal operating system than a side project.

Combining calendar, notes, documents, tasks and chat made the product much harder to keep coherent.

The idea still makes sense, but the amount of work required stopped matching its current priority.

A personal knowledge system becomes an operating system very quickly.

Centralizing context is powerful, but scope explodes fast.

The more tools you unify, the harder coherence becomes.

The technical proof worked, but turning it into a reliable product meant dealing with networking constraints, NATs, firewalls and edge cases that existing products already handled well enough.

The experiment had answered the question I started with.

Proving the technical idea is very different from turning it into a reliable product.

Routime stopped making sense as a standalone product once the idea expanded into Mindflow.

Memory only becomes useful when it can be queried naturally.

A reminder system gets much more interesting when context becomes conversational.

The combination of idle, action and unlocks was interesting, but it still felt too derivative.

Combining idle and action only works if both sides reinforce each other.

Unlocks are only interesting when they change how you play.

I paused it because I still like the idea, but I need a clearer progression system before building more.

Simple mechanics can support surprisingly deep progression.

A clicker lives or dies by its progression loop.

The interesting part was solved technically; the harder problem was making it replayable without manual content.

Procedural generation only matters if it creates enough variety to stay interesting.

The idea was useful, but notes alone were not enough for the system I wanted to build.

Capturing information is only useful if you can retrieve it later.

Notes become more valuable when they stop being isolated.

The infinite version was more interesting than the clone, but good procedural difficulty was much harder than expected.

Generating content is easy. Generating good content with controlled difficulty is the real problem.

The idea worked on paper, but without affordable restaurant data in Spain, the experience never had a solid foundation.

The concept was interesting. The data economics were not.

A product can be a good idea and still be blocked by bad economics.

If the data is the product, the quality and cost of that data define everything.

Sometimes the right decision is to stop before writing more code.

Most of the tools already existed elsewhere, and maintaining my own versions stopped making sense.

Simple tools still need a reason to exist.

What started as a smarter shopping list slowly turned into a product-data maintenance problem.

Not every useful feature deserves the maintenance it creates.

The idea was technically possible, but iOS and Android no longer allowed the kind of persistent background behavior it needed.

Platform restrictions can kill an otherwise valid idea.

A technically possible product can still be too unreliable to ship.

Sometimes the constraint is not your code, but the operating system.

It became a real product, then slowly stopped being the thing I wanted to spend most of my time on.

I still maintain it and fix things when needed, but my curiosity moved elsewhere.

Shipping changes the way you think about software.

Maintaining a real product teaches things prototypes never do.

A better platform can completely reshape the same idea.

The web version did its job, then the idea simply moved to mobile.

The best way to learn is to build something you actually want to use.