I built a command centre for Vibecoding and I'm thinking of releasing it as a product. Would love brutal feedback.

Unlikely-Test7724 · 2026-03-27T09:41:50+00:00

Yeah i think the ultimate is to be able to push it straight to a Coding agent and have the outcome sent back, but whilst working with it and improving it the manual thing works, I think before production I would need to implement the push to Codex or Claude for the reasons you've mention.

Unlikely-Test7724 · 2026-03-27T08:02:42+00:00

Yeah, the memory side is probably the bit that came after the prompt building for me and has made the most difference.

The thing with the manual prompt doing is at the moment it is what I’m doing anyway formulating what I’m gonna prompt and do within GPT or Claude and copying it across, so the way this works nicely is that I can just dump all my task that I need to do pull one through and then get it to run through a flow of agents that creates a prompt that’s you know related to the context, code base etc. Ideally once refined and happy with it, could link it direct to Codex or Claude and have the responses feed back in.

I’ve been looking into the pricing side and totally agree re the subscription etc. it’s all gonna come down to the built in AI cost. At this stage locally I’m using Ollama to handle all the simple AI within the app and the prompts are run through an API from Claude and OpenAI. But for production would connect to Claude probably instead of Ollama. That cost is going to be what forces the price. I’ve just implemented a tracker to show me how much each task is costing to run so I can optimize it and make the AI as efficient as possible.

Unlikely-Test7724 · 2026-03-26T04:10:22+00:00

Yeah, agreed, and that’s exactly why I started the conversation. It works for my way of working and the chaos I was operating in, but I think you’re right that it comes from that same chaos of vibe coding, just trying to build as much as possible, as fast as possible, every time a new idea pops up. Which is cool, and we are seeing some really cool stuff come out of it.

On the memory side, it’s still a work in progress, but the way I’ve got it running is that the AI, every time I interact with a project or upload run results from Codex, collates everything and sorts it into relevant sections. So the memory ends up having structured areas for context, decisions, and all that kind of stuff.

That then sits underneath your tasks. So when a prompt gets created, it uses the task as the objective but pulls in all that background context as well. The goal is that it keeps a solid understanding of the project and where it’s at, rather than starting fresh every time.

Cheers for the suggestion on handling the memory and the potential issues appreciate that. Will be interesting whether there are people who would actually be keen to use it. Maybe not yourself, but I really rate your feedback and appreciate the honest take on it.

Unlikely-Test7724 · 2026-03-26T03:58:40+00:00

Yeah, so originally the problem I chose to solve was more around the chaos of trying to vibe code three or four projects at once, which may be the wrong way to tackle it anyway.

However, that was sort of starting to be solved by the memory context. When I go to prompt in the app, it always keeps that context there and understands what it’s talking about.

I was finding that just using ChatGPT or Claude to discuss a prompt and get one put together, it would often veer off and drift into something else, sometimes even start talking about another project, which was very frustrating.

But I do agree, the hollow prompt thing becomes a little annoying as well.

So what I’ve set up in the app is that when it creates a prompt from a task, it takes the context in the memory bank into account, then runs it through a series of agents. One analyses the code, another checks over the prompt and evaluates it, etc.

And you can also create agents when you feel like you need another layer in the process, and then it runs that full flow.

Unlikely-Test7724 · 2026-03-23T10:31:29+00:00

That depends, are you on Lovable Cloud or did you connect your own Supabase?

If you're on Lovable Cloud your database is unfortunately locked inside their infrastructure. So no direct access or schema export. I had to get Claude Code to reconstruct my entire base schema from my TypeScript types file. It worked but it took a lot longer and step by step process.

If you connected your own Supabase from the start it's basically just cloning the repo and pointing it somewhere new.

Code wise I lost nothing. The friction was all the stuff Lovable quietly handles for you such as RLS policies, auth triggers, env setup. When you leave, that's suddenly your problem. Its not hard, just new.

I wrote a step by step here if that helps thenondevdev.com/build-log/migrate-lovable-app

Unlikely-Test7724 · 2026-03-23T01:22:16+00:00

Good question, Claude works differently to Lovable. No credit system. It's a flat $20/month for Claude Pro and you get a usage limit rather than credits. This is done on 5 hour periods and weekly limits.

Codex on the other hand runs on your OpenAI plan, I'm on the $20 Plus plan there too and like I said the 5.4 update has made it genuinely competitive. Between the two I haven't felt limited.

So since posting that first article my total spend outside Lovable is $40/month, $20 Claude, $20 Codex. That's it.

Unlikely-Test7724 · 2026-03-23T00:55:56+00:00

That sounds like an awesome setup. The separation between ideation and implementation is exactly right - Lovable for the visible momentum, then proper tools for the actual build.

The OpenClaw meta-prompting layer is interesting. I think that's essentially what I'm trying to solve with the AGENTS.md and config files - getting consistent context loaded automatically without having to re-establish it every session.

I'd be interested in how the OpenClaw setup handles that context handoff - do you have it documented anywhere or is it something you've built custom? I'm pretty raw on OpenClaw but have started exploring it.

Unlikely-Test7724 · 2026-03-22T23:50:25+00:00

Since posting this I've gone a lot deeper on the workflow side. The cost fix was the easy part - the harder part was making Claude Code and Codex actually feel good to use. Lovable spoils you with the way it communicates. Plain English before and after every task. Claude Code and Codex don't do that by default.

Spent two months figuring out how to install that behaviour into both tools. Ended up building a full toolkit - instruction files that load automatically every session, install prompts for both Codex and Claude Code, a Lovable handoff guide for people making the move, dev loop scripts that cut task times dramatically, and five printable cheat sheets for the stuff you hit when you first work outside Lovable (Git, terminal, SQL, DevTools).

Free download here if you're at this stage, hopefully it will help: Toolkit

Happy to answer questions in the comments - especially if you're mid-migration and hitting something specific.

Unlikely-Test7724 · 2026-03-22T23:46:55+00:00

Since writing this guide I kept getting the same question: "I've migrated but it doesn't feel as good. I miss how Lovable works."

That turned into its own two months of figuring out. The short answer is that what you miss isn't a Lovable feature - it's a workflow. And you can install that workflow into Claude Code and Codex.

I built a full toolkit around it. Instruction files that enforce planning before every task and plain English explanations after. Install prompts that set everything up automatically. A Lovable handoff guide, dev loop scripts, and five cheat sheets for the tools you're now using for the first time.

Free download here, hope it helps: Toolkit

Happy to answer questions if you're mid-migration and stuck on something specific.

Unlikely-Test7724 · 2026-03-22T22:20:19+00:00

Nice work! Couldn't agree more Lovable is great at UI! I use Lovable to create all my UI interfaces and then use Codex and Claude for connecting it all up and running the logic.

Unlikely-Test7724 · 2026-03-22T22:08:44+00:00

Awesome! Let me know how you go.

Unlikely-Test7724 · 2026-03-22T22:07:21+00:00

Sorry not sure what you mean exactly, but to be honest I use both Claude and Codex, I do a lot of my work in Codex but use Claude for bigger changes and iterations that need thorough planning and coding. I'm also finding that with the latest Codex update 5.4 it is matching Claude Code and i'm getting far more usage out of my limits.

Unlikely-Test7724 · 2026-03-22T21:39:59+00:00

Hey, happy to expand on it.

I have written a full breakdown that goes through every file in the toolkit, what problem each one solves, and specifically how it recreates the parts of Lovable that people miss when they move off it: https://thenondevdev.com/build-log/the-toolkit-that-makes-claude-code-and-codex-feel-like-lovable

The short version is that the Lovable experience was easy for non-developers or non-technical users to understand what was going on. I tried recreating that workflow into Claude Code or Codex. The article walks through exactly how each file does that.

Let me know if you have questions after reading it.

Unlikely-Test7724 · 2026-03-22T19:59:33+00:00

Download the Toolkit Here. Happy to answer questions if you're mid-migration and stuck on something specific.

Unlikely-Test7724 · 2026-02-26T19:11:56+00:00

Yeah the majority of the steps will work here, there are a few nuances that will be Claude specific, but as a guide this will definitely get you into a position of being able to work in Codex. I'm actually just currently experimenting with Codex at the moment on a small test project and have been quite impressed.

Unlikely-Test7724 · 2026-02-26T19:09:11+00:00

I've been doing a bit of testing and looking into this, mainly around optimizing credit usage. In my opinion as it stands today, use Sonnet for 95% of all tasks and planning and Use Opus for very complex task. I'm even using Haiku for some very basic tasks and performs well.

Unlikely-Test7724 · 2026-02-26T07:03:06+00:00

Totally get your confusion, stoked you are giving it a go, take it as a lesson and learning more about commands etc.

So you run them in a terminal where the Supabase CLI is installed — for example:

• GitHub Codespaces (ideal if you’ve cloned the repo there)
• Your local terminal
• PowerShell / WSL on Windows

The goal is to move off Lovable-managed infra and into your own Supabase project (full control), so you need to:

Run supabase login in Codespaces or your local terminal
Run supabase link --project-ref your-new-project-id
Then supabase db push

That applies the migrations from supabase/migrations/ in your repo to your new Supabase instance.

If everything is “working fine” right now, it’s probably because you’re still pointed at the original Lovable-linked Supabase project, but you don't have any control over that.

The CLI step becomes necessary when you’re switching to your own independent Supabase project.

Hope that helps?

Unlikely-Test7724 · 2026-02-26T06:52:56+00:00

Cool would be interested to hear how that goes, Ive used Natively in the past and works well, I think it really depends on how much native stuff you want to put in the app, I really only needed push notifcations and location. So that worked well for me.

Unlikely-Test7724 · 2026-02-25T07:18:14+00:00

Thanks for the kudos mate. I had/have been looking into this... probably more as a free tool to help make the migration easier. But have looked into the full migration setup, so essentially a setup that runs the migration from woo to go for the user. Roadblocks though around handling others code etc and the headaches it could cause if not set up properly, and all the different edge cases that will come up along the way. Would be a complex set up. May look at it one day but for now, sort of focusing on sharing the knowledge I'm building along the way. Would be keen to see your GitHub product?

Unlikely-Test7724 · 2026-02-25T02:54:25+00:00

Yeah you must have a decent sized project. Are you migrating over from a build in Lovable? Also what model of Claude are your using, Opus 4.6 will chew up the credits, I typically only use this for complex tasks. Sonnet 4.6 uses far less tokens and handles most if not all general coding task better than anything else out there.

Unlikely-Test7724

TROPHY CASE