Vibe Coding My Way Off SaaS

I've been experimenting a lot with vibe coding lately, and with the new models available it's becoming clear that this is a very fast way to build bespoke software.

Along the way I've found a pattern that works for me and makes up for some of the pieces AI hasn't quite been able to get right yet. In my opinion, of course. Every workflow is going to have its own holes. Depending on the requirements I may drop or add steps, but overall this is the process that has worked really well for me, given I have the time.

Wireframes first ​

The first step is building out very high fidelity wireframes in any wireframing tool. I build every screen this way, and it takes a lot of time. It's also the step I refuse to skip.

Placing items on the screen myself means that later, when I reference specific things, the AI has the context to know exactly what I'm talking about. When I've skipped wireframing, the apps that vibe coding produces just aren't very good. That step is critical.

The design pass ​

Once the screens are built, AI takes the reins and speeds things up. I pass my wireframes in and tell it to make them look a certain way using a design language I describe. I also tell it at this point which tools and frameworks I plan to use, so it knows what flexibility it has.

The output is my wireframes converted into designed images. Once all of those are looking good, I move to code. Getting from wireframes to designs that look right, applied across every screen, is a huge milestone toward something that really works.

Components before pages ​

Here's where I let vibe coding take control, but not by handing it a full screenshot and saying "make this." That's definitely not what I do.

Instead, I break each designed screen down into its individual components and build those up first. This is front-end only at this point. I don't jump to the back end yet. I stay hyper directional in what I tell it to do, and it does a pretty good job.

For example, with a dashboard I'd start with "make the navigation bar as described" and be fairly detailed about it. I'm usually talking all of this out with Wispr Flow, which I recently wrote about, and that makes the back-and-forth very easy.

I've found you do have to explicitly say "make these things components." Each nav item becomes a component. The avatar at the top of the screen becomes a component, because I want to reuse it elsewhere. If the framework I picked already ships those pieces, I tell it to prioritize them, but still componentize so the site has a system.

Once the component library exists, I have it catalog the components so there's something to pull from later. I'm also creating skills along the way so it knows how to do specific things. Then I iterate this through the entire set of wireframes until the front end is ready.

Then the back end ​

With the front end componentized, I start wiring in the back end. For me that's Laravel; for you it may be something different.

Again, I walk it through very specific steps: build a model for this, build a controller in this way. You have to decide the architecture yourself. Are you extending a base controller with children off of it, or using invokable controllers where each one does a single thing? Those calls are yours to make.

The other thing I always do is tell it to make actions, so the logic can be reused from the web UI or the CLI. And just like the front end, I create skills against each of these processes, so when I want to jump back into a specific task later, I can.

Not production, and that's fine ​

I'm not looking at every single line of code. The whole point of vibe coding, for me, is to experiment and move fast, not to build something production ready. If I were shipping this to other people, there would need to be a lot more fine tuning.

But these bespoke apps serve primarily me, and that's the ultimate picture: I can boot all this up and get an app I really like, specific to my workflow, without reaching for SaaS.

Where I still use SaaS is infrastructure, and I think that's the piece that will be retained for a while. I want my AI tools to reach out and hit APIs to do certain things: pull a media library of images in, that sort of thing, so I don't have to go find it all myself. I'm starting to pull those infrastructure pieces into whatever I'm building.

Doing more at once ​

Here's the part that has changed things the most for me. As this repository of bespoke apps grows, each one does certain things for me, and I can throw AI against all of them. With Claude and another AI up and running, and Wispr Flow letting me talk to each prompt, I'm task switching between projects that are all moving at the same time. Some of these tasks are repetitive and easy, and those are the ones that really stack up in parallel.

I keep wanting to call it brute force, but that isn't quite the word. Before, I simply wouldn't have had the time or energy to do any of this. Now I can push through it. Whatever the right word is, the takeaway is the same: I'm able to get a lot more done.

That's my overall process for vibe coding apps that are bespoke to me. It works very, very well, but you have to put in the time on the wireframes. Everything else builds on that.