This is the build-detail companion to What building an AI product taught me about selling one: what I built, how I built it, and the practical limits I ran into.
What I built
rendus.ai is a working AI media and workflow product, built around multi-provider model orchestration, a node-based workflow engine, scheduled publishing, a credit ledger and organisation-level permissions. The live demo is up; this was a learning project, not a startup launch. The point was the build, not the business.
It has three modes for three levels of user. Prompt mode is the single-shot surface: type a prompt, get an image or video. Templates wrap prompts into reusable formats, so the question shifts from “what do I prompt?” to “which template fits?” Workflows are the most interesting: a node-based canvas where users compose multi-step pipelines that run on demand or on schedule, with one node’s output feeding the next.
Generation runs across multiple model providers. The model becomes interchangeable; the system around it is what holds everything together.
How I built it, and what broke
The foundation is open source. I used Supastarter as the SaaS monorepo base, covering authentication, billing, organisations and shared package structure, and React Flow as the basis of the node-based workflow. That let me spend time on the differentiated parts: the AI workflow engine, the node-based editor, the credit ledger and the model registry. In a one-person build, the question is not “what can I build from scratch?” It is “what can I avoid rebuilding so I can spend time on what matters?”
I used Claude Code for architecture, refactoring and multi-file changes, then added Codex as a second opinion for debugging. This was the adversarial-coding approach in practice: one model builds, another challenges, and I make the final judgement. I never accepted the first answer as final, asking a second model to argue the opposite case and to say specifically what would break.
That worked best as a three-pass loop: scaffold the rough shape, challenge the architecture and rewrite it, then run it and fix what broke. Trying to do all three in one prompt is where vibe-coding goes wrong; the model shortcuts and you get plausible-looking code that doesn’t work.
The credit ledger was the sharpest lesson. I gave the model the requirements (atomic reservations, reconciliation, refunds on failure, auditability, usage tracking) and it produced a workable first pass. But deciding what risk to carry and which trade-offs were acceptable still came from me. So did deciding what not to build: the model implemented every feature I described, including the ones I should have cut. AI increases execution speed; it does not remove the need for product judgement. If anything it makes judgement more important, because bad ideas are now cheaper to build.
These lessons aren’t unique to a one-person build. They apply at enterprise scale too, only with higher stakes.
Was rendus actually a “harness”?
A caveat worth being precise about: a harness is usually an agentic term, where the model chooses its own next step. rendus.ai isn’t that. It runs on model API calls inside workflows I orchestrate, so I define the control flow and the model executes the steps. The lessons hold regardless, because the hard parts (memory, context, validation, governance, economics) live in the orchestration layer whether the model picks the path or I do.
A harness has a recognised set of parts: memory and context, tools, orchestration, infrastructure and guardrails, evaluation, and observability. Building rendus showed me which of those are hard. I shipped orchestration in the workflow engine, tools in multi-provider image and video generation, infrastructure in the model registry and provider routing, economics in the credit ledger, and governance in the permissions model. I deliberately built provider choice into the product to make the models interchangeable.
That is the whole thesis in miniature: the model is the swappable part, the harness is what you own.
Where I hit the wall was memory and context as a shipped system rather than a lesson, and evaluation and observability as real disciplines rather than instincts. Those gaps aren’t an accident. They’re exactly why three of my five learnings exist. The parts everyone agrees are core are the parts that are genuinely hard to build well. So rendus is most of a harness: it has the parts people skip, economics and permissions, and is lighter on the parts everyone calls core but few finish.
That is the lesson that holds whatever you build. The model is the interchangeable part. The system around it is what you own, and the judgement that runs it is what decides whether any of it creates value.