A user changed how I’m building Seturon’s course editor
Seturon is an adaptive learning platform, and I had been treating course architecture as a graph-editing problem.
Technically, a creator could configure modules, decision points, and learner routes. In practice, one existing user could explain the learning change they wanted, but the settings were too difficult to operate without support.
That changed the interaction model we’re testing.
Instead of making creators learn our internal vocabulary, Mira should become the main control surface. The creator describes a change in ordinary language. Course Canvas shows the exact structural proposal. Nothing changes until the creator approves that specific revision.
Before building it, I wrote the failing contract.
Today, all 14 backend acceptance tests fail with 404 because the proposal endpoints do not exist yet. That is the intended RED state. The contract covers:
- no mutation before exact approval
- stale proposals fail closed
- accepted human content stays intact
- apply is atomic and undoable
- tenant boundaries and unsupported actions stay enforced
I also collected five browser scenarios for reviewing a diff, adjusting it, rebasing a stale proposal, undoing, and reading the same state without relying on color. Those scenarios are not running against a working implementation yet.
So this is not validation. No creator has completed the new flow. The useful result is narrower: one user conversation changed the product abstraction, and the RED suite now defines what we refuse to fake while building it.
If AI proposes changes to an existing artifact, which contract would you test first?
Thanks for writing this up. Bookmarking it for later.
Thanks for writing this up. Bookmarking it for later.
Helpful post. How did you get your first bit of traction?
Appreciate the honesty here, most people only share the wins.
Helpful post. How did you get your first bit of traction?
Makes sense. Are you planning to charge for it, or keep it free for now?
Nice progress. What is the next thing you are focusing on?
Interesting. How are you measuring whether it is working?
Helpful post. How did you get your first bit of traction?
Helpful post. How did you get your first bit of traction?
Appreciate the honesty here, most people only share the wins.
Makes sense. Are you planning to charge for it, or keep it free for now?
Nice progress. What is the next thing you are focusing on?
Interesting. How are you measuring whether it is working?
Thanks for writing this up. Bookmarking it for later.
Love posts like this. The best changes I made this week came from watching one real person use the product, not from my own roadmap. Curious: did the user tell you directly, or did you notice it in how they used it? For me the useful stuff has come from watching behavior; people rarely tell you what's annoying.
Both, and the mismatch between the two was the useful part. The user could describe the learning change they wanted quite clearly, but couldn’t translate it into our settings and graph without help.
They told me where they were stuck, and then I watched what they tried next. That turned the requirement into something much more concrete: let the creator state the intent in their own language, translate it into an exact proposed diff, and change nothing until they approve that diff.
So I agree: the complaint alone wasn’t enough. Their behavior showed where our internal product vocabulary had diverged from theirs.
This is great work — reminds me of some of the calls I've had to make building Xstream4K. What would you do differently if you started over?
Helpful post. How did you get your first bit of traction?
Appreciate the honesty here, most people only share the wins.
Makes sense. Are you planning to charge for it, or keep it free for now?
Helpful post. How did you get your first bit of traction?
Interesting. How are you measuring whether it is working?
Nice progress. What is the next thing you are focusing on?
Interesting. How are you measuring whether it is working?
The contract you wrote first is the right one: no mutation before exact approval. That’s the one most AI-proposal systems get wrong earliest, usually by shipping an “auto-apply suggestions” toggle that sounds like a time saver and becomes a trust destroyer. Once a creator discovers the system changed something they didn’t approve, they stop trusting the proposals entirely, even the good ones.
The stale-proposals-fail-closed choice is the second most important. Silently rebasing means a proposal approved against version 3 gets applied to version 7, and what was approved isn’t what happened.
We hit a milder version with our CMS dynamic zones — content editors describe what they want, the system has an internal vocabulary they don’t speak. That gap is where silent errors live.
Writing the RED suite before the implementation exists is the part most founders skip.
Your CMS dynamic zones example sounds very close to the failure mode we hit: the user understands the outcome, while the product expects them to speak its internal vocabulary.
The RED suite is partly there to protect us from our own optimism. “The proposal looks reasonable” isn’t enough; the system has to preserve the exact approval boundary even when the underlying state changes.
How did you handle that vocabulary gap in the CMS? Did you make the internal structure more visible to editors, or translate their intent behind the scenes?
This is useful. How are you finding your first users so far?
Good write-up. What would you do differently if you started again?
Helpful post. How did you get your first bit of traction?
Helpful post. How did you get your first bit of traction?