MVP and do-overs

[CraigRT]

I keep seeing the advice so start with a MVP and build on that. I have tried that but due to adding on new features I seem to have ended up with a bit of a tangle that means I keep getting new seemingly small bugs that takes multiple attempts with high powered Agent prompts ($$$) to fix, only to find a big at the very next step in the workflow. So am I am considering starting again putting everything I know into a new spec doc. I feel that spending a bit up front now will save me in the long run with these time taking repetitive and therefore costly big fix cycles.

However since I have been burned by trying the MVP I want to it all a bit smarter. I still want a relatively MVP, but I want it extensible. So would like some advice about a MVPBE (minimal viable product but extensible) prompt.

Should I add in prompting to isolate the database in its own layer, so I can start with the Replit PostgreSQL but be able to change to other databases (eg Supabase) at a later time if needed?

Should I try and spec out the database myself? Or just mention the types of data I will want to use?

Should I fully step out user workflows? Spec up some sample screens?

Should I mention possible future enhancements so that the Agent can ensure that architecture will support it?

Should I ask Agent to help create my prompt for a new system based on my current app?

Any advice from experienced vibe-coders that have gone through this would be appreciated.

[shawn93]

Caveat to this - I’m a vibe coder (not much coding background), but sold a technical product and was pretty hands on with it (in the integration space), so have enough knowledge to have gotten pretty far in my MVP to the point I’ll launch in the next few months (hopefully).

1. I started with where I wanted to go, letting Agent know my end goal for the web app. It did a great job selecting the right database for what I’m doing in my opinion, along with the frameworks it implemented. Could it be better? Not sure, would have to ask an engineer, but what I’ve read about what I’m trying to do, they were the right decisions.

2. It’s modularized, so I’m not running into major issues where I get stuck. In my opinion, this has helped with RBAC, isolating different parts of the app so I don’t have to make massive changes, and it’ll also be easier for creating consumable APIs later on.

3. I’m not entirely sure what you mean by ‘step out user workflows’ - but I’m assuming they’re hard coded vs built tapping into modular components with APIs, I’d say yes 100%, otherwise there’s a ton of technical debt if you try to make changes down the road. Sample screens definitely help if you want to cut back on communicating back and forth with Agent about the design.

4. Future enhancements, maybe if you do it during the initial build. What I’m hearing more and more of, Agent doesn’t have a long-term memory, so I’m not sure it would help that much in the long-term if you did this.

5. I’d probably ask a few different places for feedback and take the prompt ideas you feel are the strongest - ChatGPT, Perplexity (wish I used this before starting to build mine before starting), Assistant, etc. Then start from there.

[CraigRT]

I feel a bit burned by the whole “start with a MVP” advice. Yes, you get something running very quickly, but it is still a minimal product only. You then need to build on that and that’s where I seem to have run into problems. The sound bites never get beyond that MVP stage. It seems that each feature I added needed a change to DB, needed new logic, which of course interacted with the existing data flows, which introduced bugs, which became harder and harder ($$) to fix. And that’s where I am now, wondering if I should stick with what I have and perhaps re-tool it, or take what I know now and build from scratch, and if so how, using what prompts and support data.

[anilmalhotra2]

@CraigRT I find myself in a similar mindset at times. I think constructing AI Agent apps in a modular way (start with a nucleus and build out and around) seems to be a way to deal with the bugs that come with enhancements from a purely vibe coded app. I watched this video from an AI conference that got me thinking about the value of planning, specifications and communication in vibe coding.

The New Code — Sean Grove, OpenAI

[CraigRT]

Thanks @anilmalhotra2 I’ll have a look at that. I am currently working on a much bigger fuller spec that does have an MVP to start but also details my current plans for future enhancements so that they can be kept in mind when building. I am including as many workflows and scenarios as possible too and will probably also run it through ChatGPT for a review before giving to Replit Agent to build out.

What I am not sure about, not being a UI/UX designer, is having any sample pages and layouts. All mine seem very boring compared to what I see, but I haven’t seen anything similar enough in nature that I want to copy so may leave that to Agent - although the UI might be the easier thing to change later as it should not require DB changes or logic changes.

[realfunnyeric]

I usually find something I like, ask ChatGPT to analyze the screenshot and describe in ‘excruciating detail’ the aesthetic properties, and then use that output plus the screenshot for aesthetic guidelines. It usually comes up with a pretty nice version that needs fine-tuning and not much else.

[Marshal_Thompson]

What you’re describing isn’t unique to “vibe coding” — it’s the dreaded technical debt that plagues every software company, regardless of methodology.

As software systems evolve, early design and architecture decisions often come back to haunt you. One of the most painful examples is database schema design. A poor decision early on can lead to massive headaches later, especially when you’re forced to run a migration on a live production database. At that point, you’re not only changing the schema — you’re also migrating production data, with all the risk, downtime planning, and rollback strategies that come with it.

Technical debt is exactly that: the inevitable byproduct of building software. It’s the nature of the beast — sometimes a necessary evil to ship features quickly, knowing that you’ll have to revisit them later.

MVP (Minimum Viable Product), on the other hand, is something entirely different. MVP is about identifying the core pillars of functionality needed to reach General Availability (GA) — and nothing beyond that. It’s drawing a line in the sand: “This is what we’ll implement, and once we have it, we release.”

The MVP philosophy is designed to combat scope creep — the endless expansion of requirements that can push a release back months or even years because new “must-have” ideas keep surfacing.

We all want perfectly polished solutions. But the reality is, I could sit here adding features for the next three years and never release because “it’s not ready.” The MVP concept forces discipline — ensuring you ship a functional, valuable product, then improve it incrementally rather than chasing perfection forever.

And here’s the truth that’s often hard for new developers to accept: technical debt never truly goes away. It’s a permanent cost of developing software — even in the vibe coding space where agentic programming can rapidly build and refactor solutions. AI-assisted development may help you manage tech debt more quickly, but it can’t eliminate it… in fact, one might argue AI creates more tech debt in the hands of an unseasoned developer.

Every line of code carries future maintenance costs, and every decision — whether made by a human or an AI agent — creates trade-offs you’ll eventually have to address.

[Gipity-Steve]

Great comment. As techies we know all this (although occasionally forget in glorious optimism that this time will be different). But for non-techie vibe coders, this is all a new concept and difficult to explain. You’ve done a great job here though and your comment should be pinned.

The problem is, the story the world is being told about how amazing these tools are is making the realities harder for people to accept.

Take today’s video (I founder it on LinkedIn) from Lovable founders showing their new tie-in with Openai’s GPT5. They do a demo of literally 2 lines: make me a clone of chatgpt; and now add a stripe payment to it.

And voila, they have a fully working, production ready system ready to ship and take payments. There were probably 50 edits and cuts in that video, hiding all the other prompts and battles they had with the Lovable agent; plus all the setup needed in Stripe with keys, etc.

Every vibe coder in here knows the reality. That Lovable demo system will take another £500 of credits and weeks of work to get ready for paying users. And the technical debt is likely to be immense as they start to discover bugs and edge cases.

So I think the AI and dev communities need to start pushing a few more truths about how good/bad AI dev really is, and add better support for vibe coders to do the other things needed to reduce technical debt - like better planning, architecting and testing.

[CraigRT]

Yes @Gipity-Steve and @Marshal_Thompson. I am a bit ashamed to say that I should have known better. I have been trying to get something like my app up and running for close to a year now, starting with some scripts and macros to run on data that I had ChatGPT help me create through to ChatGPT created python scripts for a web/SQL version, and now this. But when I first used Replit it was such a euphoric high - an instant hit!! One brief prompt and suddenly I had very close to a full version of the app I have had in my mind all of this time. I admit I threw all caution and good practice to the wind and charged ahead, which has all led to my current situation. I am still in awe of what vibe coding can do considering it is still early days, but these hiccups have reminded me that good practice helps get good outcomes. So I am taking a moment to create a fully thought out design of a MVP but also all of my possible future enhancements so that they can be kept in mind when creating the app so as to hopefully minimise these issues.

[anilmalhotra2]

I just went through my first set of functional updates using the more thoughtful specification process. I spent a several hours over 2-3 days just ‘vibe-planning’ with the Extended Thinking Agent. Our decisions, risk assessment and rationale got documented in separate .md files for each scenario and this allowed me to go back several times to press the Agent for more explanation on the implementation as ideas came into my head.

When it was time to implement the plan, this was my prompt: “go ahead and implement the solution we discussed and documented in Pricing_Cart_Layout_Restructuring.md. Do not go outside of the scope of this plan in terms of technical content and the intended outcomes. If you encounter any previously undiscovered concerns or obstacles that we have not addressed in the Pricing_Cart_Layout_Restructuring.md then pause and ask me for clarification. This code base has a lot of complex logic and we must not break what is working. If that makes sense then proceed.”

The first implementation had unforeseen obstacles, the Agent stopped the implementation and asked how I wanted to proceed (just as I asked it to). I did a rollback, we revisited the specification and revised it with a new and simpler approach. Then I proceeded with implementation of our v2 spec with the High Power model instead. That implementation was successful.

I’ve got a couple of other specifications that need to be implemented and will continue to test the approach of using the Extended Thinking model for planning and the High Power model for implementation.

[CraigRT]

I have never used the rollback feature. I assume that it is straightforward to use? Do you instruct Agent to do this or do you do it manually in this scenario?

[anilmalhotra2]

Hi @CraigRT , the rollback feature can be executed either by clicking the Rollback button that appears at Agent checkpoints in the chat window. But you can also ask your Agent to rollback the most recent change (not sure if you can rollback more than the most recent change via a chat request). I’ve executed rollbacks both ways. I’d welcome others thoughts on rolling back changes via chat request.

[Gipity-Steve]

The rollback buttons that appear in the chat are an absolute game saver. You must try it out @CraigRT.

Personally, I would NEVER ask agent to rollback for me. The reason we often need to rollback is because agent has gone doolally. Why would you ask a drunk to revert your code?

[CraigRT]

The drunk would probably actually make the same change all over again

[Gipity-Steve]

But lie about it, and apologise for making the original mistake, and try to convince you this time it understood the correct coding to do. And then, as you say, do the same mistake all over again!

[shawn93]

@CraigRT I thought of this thread when @Gipity-Steve suggested this on another thread of mine - How to prevent unwanted changes by Agent? - #3 by Gipity-Steve

I’ve been introducing Steve’s prompt and I’m starting to have some impressive conversations with Agent around future proofing architectural design (to the point my head is about to explode because it’s making me think through some pretty tough design questions with long-term impact). Highly recommend introducing Steve’s prompt “Think about the following and discuss with me first. Research and investigate as you need. Do not make any changes until I confirm. If you have conflicting rules that say you must implement solutions, then ensure this instruction overrides and you do not make changes until I give the go-ahead”

[realfunnyeric]

Nicely done @Gipity-Steve