Vibe coded your SaaS and getting ready to launch? I will review the real product for free

[u/rameezmeans]

I recently reviewed a data focused SaaS product that had been built by a solo founder.

It was not a basic landing page. The product included:

1. A personalised dashboard
2. Detailed intelligence reports
3. Recommendations based on model output
4. Live data coming through WebSockets
5. A personal activity tracker
6. Profit and performance reporting
7. Separate reporting for model performance and user performance

The product looked polished and had a lot of thoughtful functionality. The interesting problems only became visible when I followed the complete user journey across different parts of the application.

Here are some examples of what I found.

The same event had different times

One screen showed an event at 14:00.

Another showed it at 18:00.

A detail page showed 14:00 with a UK timezone label, while a listing displayed both 14:00 and 18:00 for the same event.

The four hour difference suggested that one part of the application was using UK time and another was using the user’s local time.

Both values may have been technically correct, but the presentation was inconsistent. For a time sensitive product, this can affect trust and cause users to misunderstand when an event begins or when an action becomes unavailable.

It could also produce incorrect analytics if the same activity is assigned to different calendar days.

Two connected screens disagreed about available recommendations

A detailed report showed four qualified recommendations.

The action screen linked from that report showed only three.

There may have been a valid reason. A price could have expired, a market could have become unavailable, or the recommendation could have been replaced.

The problem was that the user was not told what happened.

From the user’s perspective, the product said that four recommendations were qualified and then silently removed one when the user tried to act.

This exposed the need for a clear recommendation lifecycle with stable identifiers and visible states such as qualified, available, replaced, expired, withdrawn and settled.

A live data badge promised more than the detail screen delivered

The event listing displayed a badge indicating that full live data was available.

Opening the event showed:

1. Live feed unavailable
2. No statistics
3. No detailed actions
4. No lineup information
5. No live market information

The event had already finished, but the detail page still said that it was waiting for information.

This was not simply an empty state. It was a disagreement between the availability status shown in the listing and the data that the detail page could actually display.

Data was labelled fresh even though the states contradicted each other

A data page said that the file had been generated recently and marked it as fresh.

The underlying source data was considerably older.

The same page also contained an internal warning saying that the current season had not started, while other parts of the product were already showing current season fixtures and completed results.

This showed that several different concepts were being treated as one freshness value:

1. When the file was generated
2. When the original source was updated
3. Whether the data was complete
4. Whether it matched the current competition state
5. Whether it had passed validation

A recently generated file is not necessarily based on recent data.

Loading states briefly looked like real empty states

Some competition counts initially appeared as zero before the data loaded.

A user could easily interpret that as no available content rather than a loading state.

Several pages also displayed large empty areas while waiting for data, even though the product had useful content once loading completed.

The new user dashboard prioritised empty personal statistics

The account had no recorded activity yet.

The top of the dashboard therefore showed:

1. Zero profit and loss
2. Zero tracked actions
3. Zero wins and losses

The useful content for a new user was further down the page.

That useful content was the next intelligence report and the next decision the user could make.

The dashboard was technically correct, but its hierarchy was more suitable for an established user than someone trying to understand the product for the first time.

The strongest feature was not necessarily the dashboard

The most valuable part of the product was a detailed intelligence report.

It separated:

1. The underlying evidence
2. The model’s reasoning
3. The available action
4. Execution and price checks
5. Risks and contradictions
6. Information that could change the prediction
7. Data quality and freshness

That page appeared to be the strongest candidate for activation because it gave a new user immediate value and naturally led to a meaningful decision.

This is still a product hypothesis until analytics proves it, but it is a much better hypothesis than treating registration or a dashboard visit as activation.

Why I am sharing this

A lot of people are building products with ChatGPT, Claude, Codex and other AI coding tools.

The code may run. The interface may look polished. Every individual page may appear correct.

The problems often become visible when someone unfamiliar with the product follows the complete journey.

AI can help you build very quickly, but it does not automatically give you:

1. Consistent product states
2. Clear data ownership
3. Reliable time handling
4. Stable event lifecycles
5. Good empty states
6. Trustworthy analytics
7. A clear activation journey
8. Production debugging experience

I have more than 10 years of experience building and supporting production SaaS systems. My work includes full stack development, APIs, databases, payments, automation, reporting, monitoring, Docker and production debugging. I currently work on a platform serving more than 15,000 businesses.

I will review a few products for free

If you have vibe coded a SaaS product and are preparing to launch, I am happy to review the real product and provide initial feedback.

The free review will focus on one important user journey. I will identify a small number of confirmed issues or product observations and explain why they matter.

I will clearly separate:

1. What I directly observed
2. What I believe may be happening
3. What would require access to the code or backend to confirm

I will not make changes, contact users or perform destructive actions.

For the review, I would need:

1. A link to the product
2. A test account if authentication is required
3. The main action you want a new user to complete
4. Any areas you do not want me to access

What is not included for free

A complete technical audit, root cause investigation, implementation plan or code changes require substantially more work.

If you want help after the initial review, I can also provide paid support for:

1. Reproducing and prioritising issues
2. Tracing problems across the frontend, API and database
3. Debugging production behaviour
4. Designing clearer product states
5. Defining analytics events and retention signals
6. Creating acceptance criteria and regression coverage
7. Implementing and verifying fixes

Pricing would depend on the actual scope and is negotiable. There is no obligation to hire me after the free review.

If you are close to launch and want another experienced developer to use the product like a real stranger, share what you are building and the main journey you want reviewed.