How I built a testimonial app in under three hours
Here’s the process I went through to build a production testimonial gathering app for my website in under three hours.
As background, I previously paid around $40 a month for a SaaS product that did this, but was confident I could build what I needed and save the monthly subscription.
Before we start, here is a three minute video of what I built so you can see where we are headed in the rest of this article.
OK, so how did I get there.
I followed my own AI Development Guide which walks you through the steps I’ll cover here.
In short - I spent:
1/3rd of my time (1 hour) on planning and project set up
1/3rd of my time (1 hour) on UI development
1/3rd of my time (1 hour) on debugging and deployment
Step 1 - What is the goal?
I had a clear understanding of what I wanted to achieve because I already used a SaaS tool to do the same thing.
I started off by describing the key use case into a Google Doc using Wispr Flow to dictate.
I then grabbed some screenshots of the current product and added them in as well.
Get yourself to a point where if you could share this Google Doc with someone else they would be able to describe what you want to achieve (is it a web app, a prompt, an algorithm, a document?)
Step 2 - Understand the problem
Now we want to get a clear understanding of what the actual problem is that we need to solve.
In my case it was, “how are we going to enable customers to easily provide a testimonial, that I can then approve, and then shows it automatically on my website.”
That is quite a simple one, but I’m working on other projects where the problem is more complex involving many complex calculations and manipulation of data.
Often the way this is handled today is with experienced people who ‘just know’ how to handle different scenarios.
This is where you need to write down the problem (and how it is solved today) in excruciating detail so that another human could follow the instructions.
I do this with a Claude Project, where I feed in my previous Google Doc and additional user interviews and research.
In my testimonial example I then ask Claude,
“Based on what you know about the problem we are trying to solve, can you propose three alternative approaches, and then suggest criteria that we can use to assess each option. Then provide me with your recommendation and reasoning.”
I love this because I always get ideas that are outside of what I was initially thinking.
Even if I stick with my original idea I will complement it with something I learned from the other options.
Step 4 - Solve ‘the thing’
’The thing’ is the crux of what you are building. For my testimonial app I didn’t have a calculation, or scoring system, or algorithm that I needed to develop - but I regularly do in other projects.
There is no point moving on to building a fancy front end if you haven’t solved ‘the thing’.
I do this with a combination of my Claude Project (which now has more context about the problem, Grok 3 (increasingly using this for complex long running discussions) and OpenAI Deep Research for developing a strategy for solving ‘the thing’
Typically I will be using these AI models to develop a script or mini-app running as an artifact/canvas to test out the calculations.
“In your project knowledge I have provided you with all of the details about how our team manually solves this problem today.
Without writing any code, I would like you to suggest ways that we could solve this with technology.
Potential solutions could be:
A prompt for a one-time use
A prompt for ongoing repeated use
A mini-application for internal use on a local machine
A mini-application for internal use via a browser
Any other approach you think is appropriate”
Step 5 - Create a Product Requirements Document (PRD)
Having solved ‘the thing’ I now move on to defining the product that I want to build.
Here I lean on the expertise of Product Managers much greater than I using ChatPRD, a platform built by Claire Vo, Chief Product and Technology Officer at LaunchDarkly.
Containing templates for PRDs, APIs, Compliance and many more, I’m able to borrow from years of Claire’s experience and bring it into my projects.
With some quick chats with ChatPRD I am able to develop a detailed PRD including user stories, functional components, personas, licensing, technical considerations and a high level project plan.
I export this to Google Drive and immediately add to my Claude Project so Claude now has this context as well.
Step 6 - Map out the UI
Now we can start architecting our product.
Our Claude Project now has:
The goal we are trying to achieve
The problem we are trying to solve
The proposed solution to ‘the thing’
The Product Requirements Document
(and if you have them, screenshots for what you are ‘borrowing’ from)
Now you can ask your Claude Project,
“Based on what you have in your project knowledge, create a list of all the pages/screens required for this product. At this stage, do not provide any more detail - I just want the list of pages and a brief overview of what that page will be used for.”
Having received the list of pages and had some interaction with Claude about which pages might be missing or need changing, you can now ask one by one,
“Now for [this page] help me define a page structure - to include the different sections, components and suggested text, labels and inputs required. We will be using Shadcn UI so feel free to reference standard components from that library.”
(Note: Shadcn is a commonly used library of visual components)
Now repeat this page by page. The reason we do this in bite-sized chunks is to keep Claude focused on the task in hand and for us to be able to review and comment as we go rather than having to assess a list of 20 pages at once.
Once complete, ask Claude to save them all as an artifact and then save to your Project for easy future reference.
Step 7 - Build the pages
It is only now, step 7, that we actually start to build anything. In my testimonial example I used Lovable - a fantastically intuitive AI enabled development platform.
And now you see the magic of all the pre-work we have done.
I create a new project with something like:
“Build me a blank project with a cro-optimised hero image for a testimonial gathering application where I am going to provide you with details in a moment about what screens we need.”
Lovable spins up a basic UI that I can start to work with.
I go back to my Claude Project and ask,
“Can you create a 500 word overview of our project to add to my Lovable Project knowledge. Include a summary of our PRD, screens and use these branding guidelines [insert any colours/fonts]”
Now take this text and drop it into the project knowledge in Lovable.
Note: at the moment you cannot add/link files to project knowledge, hence needing to add it as text.
Now you can go page by page. You can add your PRD to the chat as an asset, plus any logos or images that you want to use.
Build in bitesized chunks following the screens you have defined in your Claude Project.
“Now we are going to create the login screen. Here is the page structure I have defined. [copy in the page structure from Claude].”
I should note at this point that I am continuing to speak to Lovable via Wispr Flow - I am not typing anything, other than copy paste from Claude.
You will now find you are racing through the building of the app, because you have all the context and are providing clear, bite sized instructions to Lovable.
Step 8 - Advanced/ask for help
Now I reached the third hour in my process - I have the core of a working app but I needed to add:
A Supabase database to store testimonials
iframe functionality to embed on my website
Deploy the project to a custom URL
Debugging things that aren’t working
This is where it can easily feel like the wind gets taken out of your sails.
“Ah it was all going so well, and now I just have errors and things aren’t working - I should just give up.”
Sense check time - we are 120 minutes in and we nearly have a working SaaS application.
Stay the course and use a few of these debugging techniques:
“Fix this error” - this actually works a large percentage of the time in Lovable
“Consider three different reasons why this might be failing and suggest which you think is most likely and why” - this gives Lovable permission to look at non-obvious causes
“Restore" - Lovable allows you to restore to a previous version, so if you are stuck just go back 3 or 4 steps and try with some new prompts.
Step 9 - Deploy
And now you are ready to go live for some testing. I won’t cover much here because it will depend on your usecase, but you have a couple of options:
Host with Lovable, who will put your app on a lovable.dev domain
Use Lovable’s built in integration with Github and deploy on your own domain with Vercel or Netlify.
Top Tip: Another good reason for using the Github integration is that with Claude’s new Github integration you can now pull your Lovable code into your Claude Project - fantastic to be able to collaborate on rolling out new features in your PRD roadmap.
Get started!
I hope that gives you a good walkthrough of the steps I followed.
If you want to follow along in realtime, I recorded a video with no editing or speeding up.
It includes my internet going down in the first four minutes, the kids coming home from school, my dogs barking….its as it happened!
Will be useful for you to watch that, and have this article and the AI Development Guide up on your screen at the same time.
If you found this guide useful, and would like to test out what I build by saying a few words about what you found helpful - I would be extremely grateful!
Good luck and let me know what you build!
Get Started
Whenever you are ready there are three ways I can be helpful:
Model 101 Playlist: 20 minute guides to using ChatGPT, Claude, NotebookLM for work
AI Inspiration Briefing: Show your people the path forward in this 60 minute live session
Kowalah: Buying platform to help you pick the right AI tools for your business