Building SaaS in 2026: Are you vibecoding your own product or engineering it the "old way"?
I've been a professional developer for 10+ years (WordPress ecosystem, and React, TypeScript, Node, the whole stack).
Now I'm building my own SaaS and I'm genuinely torn.
On one hand, I could vibecode the MVP in a weekend with Cursor + Claude and ship fast. On the other hand, I keep catching myself doing things "properly" — writing tests, setting up CI/CD, structuring the codebase like it'll need to scale to thousands of users… for a product that has zero users right now.
I've noticed a weird pattern among senior devs I talk to:
We over-engineer MVPs because we know what bad architecture costs later - but that same instinct is killing our speed to market.
Meanwhile, non-technical founders are shipping with Lovable and bolt in days and getting real feedback while we're still debating folder structure.
So I'm curious:
If you're an experienced developer building your own product:
-> Are you letting yourself vibecode the MVP, or are you engineering it "properly" from day one?
-> What's the one thing you refuse to cut corners on, even for an MVP?
-> Have you shipped something vibecoded and then regretted (or NOT regretted) the technical debt?
Would love to hear from both sides. I think there's a middle ground here that nobody's really talking about.
Replies
Not a 10+ year dev but I've shipped a few things with Cursor + Claude and I think the middle ground you're looking for is: vibecode the parts users touch, engineer the parts that handle their data.
Frontend, landing pages, onboarding flows, dashboards? Vibecode all of it. Nobody cares how clean your component tree is if nobody's using the product yet. But anything touching auth, payments, or data integrity I'd still do properly because unwinding that stuff later is genuinely painful.
The folder structure debate is the tell. If you're spending time on that before you have paying users, the engineering instinct is working against you. The non-technical founders shipping with Lovable aren't winning because their code is better. They're winning because they're getting feedback on Tuesday instead of architecting until Thursday.
Shipped something vibecoded, hit real users, then refactored the parts that actually mattered. Turned out about 70% of what I would have "properly" engineered upfront never needed to exist at all.
I vibecoded the initial prototype and then went back and re-engineered the parts that actually matter. That's the middle ground nobody talks about and I think it's the right answer for most technical founders.
The thing is, agentic coding is inevitable. The product scales, the economics usually don't. So the question isn't vibecode vs engineer, it's which parts need to survive contact with production and which parts just need to exist. I vibecoded everything that isn't core infrastructure and I don't regret a single line of it. Speed to feedback is everything when you have zero users.
The one thing I refuse to cut corners on: anything that touches reliability in production. Bad architecture you can refactor. Bad reliability habits you carry into your production system will kill you.
@devon__kelley when your product actually starts getting users, how do you usually handle the hosting and infrastructure side if traffic grows or something breaks?
I have started vibecoding MVPs but keep one rule: the problem must be validated before the architecture is — refactoring later is cheaper than building the wrong thing slowly.
@allinonetools_net That’s a great way to frame it.
I’m realizing the biggest early risk isn’t technical debt — it’s product debt from building the wrong thing for months.
Refactoring code is painful, but refactoring a whole idea is much worse
You can still vibe code, but in a more disciplined engineering way: step by step, with a plan, architecture first, and create MD files with the whole plan when needed.
Start with the architecture, ask for tests first, think through the test cases, and verify the results. Use AI like a junior or mid-level engineer, and also as a brainstorming partner when you’re the only one in the room. That approach works well for me.
The key is not to ask it to build the whole thing at once, but to move step by step - just like you would when delegating to your team.
I’m increasingly convinced the right move is: engineer the core, vibe-code the edges.
Protect the critical path, tracking, and anything expensive to rework - but don’t build a “Series A codebase” for a product with zero users.
That balance is probably where most strong MVPs live.
Great question. We are building HelloAria (an AI productivity app for iOS) and honestly we use a hybrid approach. The core architecture and critical user-facing features are engineered properly, but for rapid prototyping of new ideas and internal tools, vibe coding with AI has been a massive time saver. The key is knowing when to switch modes — vibe code the MVP to validate the idea, then engineer it properly once you know it works. 10+ years of dev experience is actually a superpower here because you can spot when the AI is cutting corners.
I have 5 shipped products and I still wrestle with this on every new one. My current take: vibecode the UI and happy-path flows, engineer the parts that are hard to change later (auth, data model, billing). The test suite can wait, the schema really can not.
The over-engineering trap is real. I spent 3 weeks setting up a "proper" backend for a tool that got 12 users and died. The next one I vibed in 3 days and it has actual paying customers. The difference wasn not quality - it was whether I got real signal before investing.
The one thing I refuse to cut corners on even for MVP: how data is stored. UI is replaceable. A messy schema with years of production data on top of it is not.
honestly the whole vibecode vs engineer framing is already outdated imo. im using claude code in the terminal and its not "vibecoding" in the lovable/bolt sense but its also not me manually writing every line. the real skill now is knowing what to specify upfront so the AI doesnt make dumb architectural choices. thats basically engineering but faster. senior devs arent slower because they over-engineer, theyre slower because they dont trust the output and manually verify everything. which tbh is the right call rn because the AI will confidently ship broken auth if you let it