How do you test your product before launch?
I recently came across what the majority calls "vibe coding" and I am addicted. As I am a marketing guy, I couldn't resist in creating not one, not two, but 8 apps, which are basically systems to solve my own problems and frustrations.
However, I couldn't help but notice that all these tools are far from perfect. Lovable, Replit (which I use extensively now) say they did something, but in reality, they made only the surface.
Now, you will be quick to say that I didn't give them the correct prompt or instructions so there you have it - incomplete.
You may be right, as I am still learning.
But, I remembered the good old days I was working at a toy company and I was their "Marketing Manager" (essentially their everything guy). One of my responsibilities was to test the toys we produce.
What I remember was endless testing of electronics, voices, and flows, for a physical product that once was confirmed and entered production, there was no turning back. One mistake or oversight, and the product was totally ruined.
So creating my apps now reminds me exactly those days. I spend more time testing flows than actually creating the whole thing. And it takes time.
My process is this:
When I was testing toys back in my 30's I used to draw the entire process on paper. Now, seems this also works for digital products, and thank God we also have ChatGTP. I work with it to create a basci structure which I then print out with tick boxes. Maybe this counterintuitive for most, but I am not used in checklists on a screen - I want to also note changes.
I break the whole project in components, like "user authentication", "billing", "visual canvas" and once a crticila piece needs to be connected with another, I am testing this flow. Once another one does, then I retest the same flow and then the new. For exampl, lets say that I simulate a user visits the website and then decides to take a free trial. Does the clicking of the button takes him to the billing? When this does, does it redirect to the user registration? Then does it send an email and so forth. This maybe very common to you, but for a non coder it is rocket science, still
Finally I do something many find it crazy - my old bosses used to, but they understood it. I actuall ytook this advice from John Carlton, a famous copywriter. Once I finish testing - or if testing goes wrong - I sleep on it for 2-7 days. I do something else, like building another app, or working with my clients or my staff. Lately I find extreme joy in gardening :-) Then I come back and the flow works like a charm - which means two things I was either tired and made mistakes, or the universe was against me:-(
What is your process? How do test your products? I would love to exchange some thoughts and possibly refine my approach.
Replies
We often maintain a channel of 1-200 seed users before release, where we centrally collect feedback and conduct testing.
Hey Sal, your piece of advice is pretty valid. I would add: Ask someone else to test the product.
Because you are based, and oftentimes some "gaps" can be unnoticed.
The best thing is to:
Hire someone specialised/experienced, so an expert will guide you to the "almost" perfection
Give access to several people and ask them/observe on the call how they approach it.
@busmark_w_nika Thank you for your kind reply. I totally agree and most certainly left that part out, as I am considering it as part of the pre-launch marketing, which is also a fantastic way to give it away for a select group of people who meet certain prerequisites and also get your first testimonials this way.
Also, this group can be named as "Founder's group" which also actively can participate in the app's development :-)
Thank you again for this super valuable comment!
@sal_georgiou1 Founder's group sounds good. :)
Regarding giving free trials, I think it makes sense with people where you observe their pain points and come up with a solution. And if such people have a lot of followers, they will be enthusiastic about using your product.
Just 2 days ago, someone offered me access to a tool that is very relevant to me, and it left a very positive impression that I want to spread awareness about it.
@sal_georgiou1
"Testing before launch is non-negotiable. When you’re solo, you don’t have the luxury of a big QA team—but that just means you need to be sharper and more structured. Here's how I do it:
Break it down into testable chunks – I don’t wait until the end. I test as I build—module by module. Frontend, backend, integrations—they all get isolated testing first. Bugs are cheaper to fix early.
Real-world use cases – I always test like a real user, not a developer. I create user flows that mimic actual client scenarios. If it’s a dashboard, I’ll try weird inputs, lost connections, and even edge-case behavior. It’s about pressure-testing, not just checking boxes.
Cross-device and cross-browser – Especially for web apps. What looks perfect on Chrome might break on Safari or mobile. I use tools like BrowserStack or even just my own devices to double-check responsiveness and performance.
Feedback loop – I always run a closed beta with 3–5 trusted clients or peers. They give brutally honest feedback. They’ll catch things I’m blind to after working on it for weeks.
Automate the essentials – I keep some automated tests for critical paths—login, payments, key features. It’s lightweight, but covers the backbone.
Final sanity check – Before launch, I step away for a day, come back with fresh eyes, and do one final run-through as if I’m the end user seeing it for the first time.
Launching solo doesn’t mean cutting corners. It means building trust by making sure what you launch works, from day one."
IXORD
I support other people who give access to their product to N number of people and watch reviews. This is also called "shadow launch" and it is quite popular in the announcement of any features or product.
But how to do it if you don't have much resources? @busmark_w_nika
The tools are changing and fast. There are people on all sides of the vibe coding spectrum. Some who believe this will be something, pushing this hard, trying new approaches, documenting, sharing them. Others who are trying, getting stuck, learning, trying again. And many others are still staying away. Many software engineers are hesitating to use vibe coding.
At this moment, there are many things that work but it needs going step by step. Basically keeping the core ideas around good software engineering like automated tests, continuous integration, using git branches, etc. It is important to build the software in small steps and be able to run the software at each step - to be able to test it.
You are already doing great by breaking the project into components. Asking LLMs to the create the technical tickets from your high level description also helps. The coding agent matters too. Claude Code gives a much more software engineer's workflow and as the project becomes bigger this is very helpful.
I forgot to mention, rest is super important. Our brains need time to compose our day's actions/attempts. With vibe coding, we feel like we should accomplish everything super fast. This does not work since the models are not at the level of a skilled engineer. So we need to have conversations with them. This needs our cognition to be sharp.
I wrote about my thoughts after vibe coding for 4 weeks full-time: https://www.reddit.com/r/vibecoding/comments/1lxzuqg/4_weeks_fulltime_vibecoding_what_i_can_share/
I am happy to help, happy building!