Writing as someone who’s exactly at the stage you’re targeting, I really appreciate the effort. However, I felt the context could definitely be enriched a bit more to be more practical.
The customer prompt you shared sounds interesting, and I might give it a try once everything else is in place. But the earlier stages still feel quite vague to me.
So, how could this be different?
- How deep or detailed should the user requirements be for Lovable (for example) to generate a truly practical solution?
- Which tool do you prefer to use for prototyping? (If lovable does it have any limitation or all free, is it copilot?) How was the outcome coherent for updating with the feedback?
- For example — should I write the requirements in a CRUD-style format, like I used to do back when I was working as a system analyst?
- What the relation with step 1 and 2? First code then prototype?
I’d truly appreciate any insights and answers to my questions🙏
Thank you so much for your feedback. We want to hear from people like you.
Our goal with this newsletter is to help software engineers remove the blockers and ship their side projects.
Here are my answers:
- How deep or detailed should the user requirements be for Lovable (for example) to generate a truly practical solution?
-> This is not an easy question, and we will dive deeper in the following posts, so stay tuned ;). However, here is a tip: AI tools work great in 2 situations:
1. generic boilerplate to start working
2. detailed implementation of a single functionality
My suggestion is to separate the things: start with a boilerplate and iterate on it for each feature.
- Which tool do you prefer to use for prototyping? (If lovable does it have any limitation or all free, is it copilot?) How was the outcome coherent for updating with the feedback?
-> We are mostly using Bolt lately, however this is not a comparison, we will talk about all these AI tools in the following weeks and provide detailed prompts to get the best from each one of them.
- For example — should I write the requirements in a CRUD-style format, like I used to do back when I was working as a system analyst?
-> We got the best results using the "Scenario" style: As a User when I visit page X I want to...
- What the relation with step 1 and 2? First code then prototype?
-> Start with 1, generate a boilerplate of the project, then iterate on every single page as described in 2.
In case you didn't get the chance, you should also take a look at our free email course: https://microsaasweek.com/
I think you will love it.
And if you need more help, I'll be happy to jump on a quick call and discuss your blockers together :)
Alessandro, your explanation helped me so much, really appreciate it. I just signed up for your email course too. And thanks a lot for offering a quick call — if you ever have some time (no rush at all), that would be amazing. That's very kind of you to offer this.
The part I’m struggling with is more on the BE side after applying what you clarified for me. Actually, could I maybe request this as a topic for one of your future posts? Something like: how to set up BE, and how far we can go chatting with tools like V0, Loveable, etc. They give us a working prototype, but I’d love to learn how to tweak it or make it more realistic for my own case you know. I’m not quite there yet to fully make it work.
So, continuing the series with BE + deepening the prototype through these tools would be golden. What do you think?
Thank you so much for your comment. As Alessandro also said, this is gold for us and helps us tremendously in moving in the right direction we envisioned for our work: to help software engineers remove blockers and ship their side projects.
I know what you mean when you talk about setting up a BE. We've been there, and we know that thing might not be as easy as it usually seems. There's a lot that can be done even for BE with the tools available (both paid and OSS)
Next post(s) about that topic? Absolutely yes, we thought about it since the beginning and, since you're asking, maybe we'll cover that in the next one ;-)
Anyway, to be practical and helpful, we'll be happy to jump on a quick call to chat or simply answer your questions even here!
Thank you soo much for considering my little request about BE!!!!! I really really appreciate that 🎉 Can't wait to read and learn from it.
Either works for me. Having a call would be super super cool for sure but i am shy to take too much time from you guys. Therefore for not to bother you too much, i'd better lower my questions to 2 and post them here, that's ok for you. But first i just need to construct them, since many thoughts are flying in my head you know :D Anyway, i'll post my questions by the EOD today. I can't thank you 2 enough for giving me a hand. God bless!
So here’s the setup: I tried Lovable. Based on your posts, I pulled together a system requirements doc (aligned with CRUD) and fed it in. It came back with a mockup I actually really liked — but now I wanna push it further/customize it. Since my model still needs to learn and evolve, I’m stuck wondering: do I actually need to upgrade to paid, or is the free version good enough at this stage?
1-My app is meant to be a dynamic, choice-driven tool. At the end, it should spit out a result report the user can actually use. But with Lovable, it kinda throws in random questions on its own. I can’t really embed my scoring logic or calculations. Even simple tweaks (remove this, swap that) hit limits pretty fast. So is paid basically the only path forward? From your experience, what’s the real differentiator — usage data, or complexity?
2-On the backend side: say I go with Cursor (I know you’re touching this in your next post). To get something fully shippable, would it make sense to pair Cursor + Lovable, or should I be looking at V0.3 instead? And with Cursor, can I move things forward just through chat prompts, or do I need to get my hands dirty with some coding?
3-One more thing: I’d love integrate AI into the system to learn so that the system will be able to give users the option to add their own dynamic question sets if they want and learn from there. Do you think something like that could be handled through Cursor (or similar tools), or is that a heavier lift?
Guys, thank you for the blog post!
Writing as someone who’s exactly at the stage you’re targeting, I really appreciate the effort. However, I felt the context could definitely be enriched a bit more to be more practical.
The customer prompt you shared sounds interesting, and I might give it a try once everything else is in place. But the earlier stages still feel quite vague to me.
So, how could this be different?
- How deep or detailed should the user requirements be for Lovable (for example) to generate a truly practical solution?
- Which tool do you prefer to use for prototyping? (If lovable does it have any limitation or all free, is it copilot?) How was the outcome coherent for updating with the feedback?
- For example — should I write the requirements in a CRUD-style format, like I used to do back when I was working as a system analyst?
- What the relation with step 1 and 2? First code then prototype?
I’d truly appreciate any insights and answers to my questions🙏
Hi Esin,
Thank you so much for your feedback. We want to hear from people like you.
Our goal with this newsletter is to help software engineers remove the blockers and ship their side projects.
Here are my answers:
- How deep or detailed should the user requirements be for Lovable (for example) to generate a truly practical solution?
-> This is not an easy question, and we will dive deeper in the following posts, so stay tuned ;). However, here is a tip: AI tools work great in 2 situations:
1. generic boilerplate to start working
2. detailed implementation of a single functionality
My suggestion is to separate the things: start with a boilerplate and iterate on it for each feature.
- Which tool do you prefer to use for prototyping? (If lovable does it have any limitation or all free, is it copilot?) How was the outcome coherent for updating with the feedback?
-> We are mostly using Bolt lately, however this is not a comparison, we will talk about all these AI tools in the following weeks and provide detailed prompts to get the best from each one of them.
- For example — should I write the requirements in a CRUD-style format, like I used to do back when I was working as a system analyst?
-> We got the best results using the "Scenario" style: As a User when I visit page X I want to...
- What the relation with step 1 and 2? First code then prototype?
-> Start with 1, generate a boilerplate of the project, then iterate on every single page as described in 2.
In case you didn't get the chance, you should also take a look at our free email course: https://microsaasweek.com/
I think you will love it.
And if you need more help, I'll be happy to jump on a quick call and discuss your blockers together :)
Alessandro, your explanation helped me so much, really appreciate it. I just signed up for your email course too. And thanks a lot for offering a quick call — if you ever have some time (no rush at all), that would be amazing. That's very kind of you to offer this.
The part I’m struggling with is more on the BE side after applying what you clarified for me. Actually, could I maybe request this as a topic for one of your future posts? Something like: how to set up BE, and how far we can go chatting with tools like V0, Loveable, etc. They give us a working prototype, but I’d love to learn how to tweak it or make it more realistic for my own case you know. I’m not quite there yet to fully make it work.
So, continuing the series with BE + deepening the prototype through these tools would be golden. What do you think?
Hi Esin,
Thank you so much for your comment. As Alessandro also said, this is gold for us and helps us tremendously in moving in the right direction we envisioned for our work: to help software engineers remove blockers and ship their side projects.
I know what you mean when you talk about setting up a BE. We've been there, and we know that thing might not be as easy as it usually seems. There's a lot that can be done even for BE with the tools available (both paid and OSS)
Next post(s) about that topic? Absolutely yes, we thought about it since the beginning and, since you're asking, maybe we'll cover that in the next one ;-)
Anyway, to be practical and helpful, we'll be happy to jump on a quick call to chat or simply answer your questions even here!
Thank you soo much for considering my little request about BE!!!!! I really really appreciate that 🎉 Can't wait to read and learn from it.
Either works for me. Having a call would be super super cool for sure but i am shy to take too much time from you guys. Therefore for not to bother you too much, i'd better lower my questions to 2 and post them here, that's ok for you. But first i just need to construct them, since many thoughts are flying in my head you know :D Anyway, i'll post my questions by the EOD today. I can't thank you 2 enough for giving me a hand. God bless!
Ohh, and the most important thing: now the request is a tiny/small request! We're here for this. To help, period, and we're more than glad to do it
That’s a great idea to post here for many reasons:
- because knowing your pain and questions, we can issue something extremely helpful and actionable
- because it permits at the same time to jump on a live chat well prepared!
Can’t wait for your next one!
Hey again guys, here are my questions;
So here’s the setup: I tried Lovable. Based on your posts, I pulled together a system requirements doc (aligned with CRUD) and fed it in. It came back with a mockup I actually really liked — but now I wanna push it further/customize it. Since my model still needs to learn and evolve, I’m stuck wondering: do I actually need to upgrade to paid, or is the free version good enough at this stage?
1-My app is meant to be a dynamic, choice-driven tool. At the end, it should spit out a result report the user can actually use. But with Lovable, it kinda throws in random questions on its own. I can’t really embed my scoring logic or calculations. Even simple tweaks (remove this, swap that) hit limits pretty fast. So is paid basically the only path forward? From your experience, what’s the real differentiator — usage data, or complexity?
2-On the backend side: say I go with Cursor (I know you’re touching this in your next post). To get something fully shippable, would it make sense to pair Cursor + Lovable, or should I be looking at V0.3 instead? And with Cursor, can I move things forward just through chat prompts, or do I need to get my hands dirty with some coding?
3-One more thing: I’d love integrate AI into the system to learn so that the system will be able to give users the option to add their own dynamic question sets if they want and learn from there. Do you think something like that could be handled through Cursor (or similar tools), or is that a heavier lift?