Learnings from my first Lovable product build

I've been eager to start using a vibe coding tool. For those that have followed me for a while, I was very excited at using no-code tools back in 2023 and to be honest, was lacking AI to really seal the deal of "yes, you too can make an app and ship it."

That situation has now changed. A slew of apps have hit the market, and probably thanks to Lenny's Newsletter, I started using Lovable earlier this year in March. Now in July, and nearing the completion of my first app, I feel like I'm in a good position to share what I've learned and what I think is next.

Spoiler alert: Vibe coding still needs a product strategy going into it!

Starting with Lovable

When I was thinking about using a vibe-coding tool, my current situation was using Cursor a Meng To's Design Code course. It was going relatively well, but having listened to Lenny's podcast and a subsequent live stream, I was hooked!

What I needed was a project to work on. I actually do have an app that I want to bring out, but the problem I find with personal projects is that they're highly ignorable! What I needed was a client project.

I sent a few LinkedIn DMs and after a few days, received an intro to Dr Andrew and Alastair, two sports rehabilitation practitioners who had made a system on spreadsheets that they wanted to commit to an app. Having received long timescales and highly priced proposals from a specialist agency, I made a counter offer:

"Let's do a 3 sprint approach on the key features using this new vibe-coding method and see where we get to!"

They agreed, and started sharing ideas, whilst I started prompting.

Advice for those starting out

We went straight into it. I would take their descriptions of features, format into a prompt using ChatGPT and then prompt within Lovable. After a few hours, I had auth, navigation, key features, some dummy data and UI that would've taken days to design (even using a design system) and then hand over to a developer to commit to code.

Coming into the third sprint, I recognised an inconvenient truth. These were first-time founders, and whilst I was saying Minimal Viable Product, what we had so far resembled more of a version 1, with some shortcomings. I was prompting at the same time as learning their business and somethings struck me. Some things were nested within a 'parent' category and some things weren't. A lot of the features fed into 5 different types of report and actually each feature was quite complex and deep in hierarchy.

I think it's worth remembering that with any initial build, you're building to validate. There will be ideas of features in there. There may also be big features that could later be scrapped. I think the key here is to not love your product too much and just acknowledge that the first release is your best guess and very likely the shape of the app will change after that in some small and big ways.

Recommendation: I was feeding off instructions and some sketches. I didn't really see the shape of it or be able to respond using my experience designing many other apps. I think (and will try next time) designing the journey and the key features is still a worthy exercise.

Now, I am one of those that dislikes discovery. I see it from the stakeholder point of view. "So you ran a workshop and researched our business. Does that mean you've got nothing to show in the first week of working with us?" These are the conversations I feel like we can move past.

Maybe the recommendation here is to do a sprint of an initial build, then with the second sprint create the journey and map the features. You've started, so you're not in a simulation, and you may have already encountered some issues. That's a great time to get into the planning of it!

It's getting better (or recognising when you're going in loops)

Late into the first sprint, I encountered a short-coming. No doubt when you read this, Lovable has bettered their model and accuracy (even now I'm using a trial of their agent that claims and seems to provide better accuracy), but anyway as I was saying - I felt at some points that I was simply going round in circles.

I'd make a change and realise only in a review that Lovable had removed a feature we had previously in the product. There was also a complicated table UI that we needed an editing function to rename and Lovable just couldn't solve it.

Recommendation: I think Lovable and others are superb at starting a product. As it gets more complex, I think it's still time to involve a developer. I had a fantastic one I work with, but in these cases, it's actually more effective to use a 'scalpel' here rather than a 'hammer' of a vibe coding prompt.

For my practice, I think a designer can vibe code, work out the journey, the features and commit to GitHub knowing there are currently some shortcomings. The advantage is that you see the shape of the app super early, fantastic for client meetings, and it solves so many problems that have plagued app development for decades. The discovery, design, develop method dissolves. You truly can design through prompts and at the same time, a friendly developer can start setting up environments, get Cypress ready and solve those persistent database issues.

Keep trying

It's a fast moving industry, but as ever, I'm keen to start using and learning and not waiting - which seems to be the position of most other businesses and designers I know. "Wait and see" positions rarely reward.

With these new tools, I think honesty is the best policy. Andy and Alistair know that I'm learning at the same time as they're learning about making product. The benefit though is that if they had gone with that other agency, after 6 weeks, they would hardly have started, deep in discovery, whilst with the same amount of time and some new tech, Andy and Alastair are doing their first client demos and getting that all important feedback.

I know which position I would rather be in.