Building a SaaS is one problem.
Getting people to discover it is another.
After working on several SaaS projects, I noticed that many indie hackers and small teams could build good products but struggled with distribution. Product discovery platforms can help, but I wanted to build something focused specifically on SaaS, AI tools, apps, and developer products.
So I built CodeHype, a SaaS launch and discovery platform where founders can submit their products and get a dedicated product page.
You can check it out here: https://www.codehype.ai
This is how I built it and some of the things I learned along the way.
The idea
The initial concept was simple.
A founder submits a SaaS product, we review it, and it gets published on the platform.
Each product gets its own page containing its description, features, links, screenshots, and other relevant information.
I also wanted launches to have an SEO component. A product page should be useful for people discovering the product through search engines and AI search systems, rather than existing only for launch day.
That meant the technical architecture needed to be simple, fast, and easy to scale.
Tech stack
The current stack includes:
Next.js for the application
Supabase for authentication and database
Vercel for hosting and deployment
Cloudflare R2 for image storage
Dodo Payments for payments
Resend for transactional emails
Google Analytics and Google Tag Manager for analytics
Beehiiv for newsletters
I chose this stack because it allowed me to build quickly without maintaining a traditional server infrastructure.
Building the product submission system
One of the first things I needed was a structured submission flow.
A founder can submit information about their product, including:
Product name
Description
Website
Category
Logo
Screenshots
Social links
Founder information
The submission enters a review process before being published.
This became important because an open directory can quickly accumulate low-quality or spam submissions.
Instead of automatically publishing everything, I wanted to retain some control over the quality of the directory.
Generating product pages
Every approved product gets its own URL.
For example:
/products/product-name
The page contains the information submitted by the founder and additional metadata generated for search engines.
This creates a growing collection of pages around specific SaaS products and categories.
One lesson I learned here is that having thousands of URLs doesn't automatically mean having thousands of useful SEO pages.
Every page needs a clear purpose and enough unique information to be valuable.
Image storage with Cloudflare R2
Images became another problem.
Product logos and screenshots can become expensive and slow if you serve everything directly from your application infrastructure.
I moved product images to Cloudflare R2.
The application stores the relevant image URL while R2 handles the actual object storage.
This keeps the application layer relatively lightweight and makes it easier to manage product assets separately from the main database.
Authentication with Supabase
I used Supabase for authentication and database functionality.
This made it possible to let users create accounts and manage their submissions without building an authentication system from scratch.
Users can save information during the submission process and return to complete it later.
For a directory, this is particularly useful because submissions can contain several fields and assets.
Adding paid launches
The platform started with a free submission option.
I later introduced paid launch options for founders who wanted additional exposure.
The basic model looks like this:
Free Launch
A founder can launch without paying, with certain requirements around the backlink/badge.
Paid Launch
Paid tiers provide additional visibility and features.
Premium placements
Products can also purchase additional promotional placement on the platform.
The important part for me was keeping the basic submission accessible while giving founders optional ways to get more exposure.
What happened after launch
The first version went live with a relatively small amount of content.
Then the number of submissions started increasing.
Within the first 10 days, more than 200 products had been submitted/listed.
The platform also reached hundreds of registered users.
That created a new problem.
Scaling a directory isn't only about adding database rows.
You also need to think about moderation, SEO, page performance, image optimization, email notifications, payments, and the overall submission workflow.
One unexpected SEO problem
One of the biggest lessons came from Google Search Console.
Some product pages weren't being indexed as expected.
I initially assumed that generating a sitemap and creating unique URLs would be enough.
It wasn't.
I had to look at several things:
Page quality
Internal linking
Metadata
Structured data
Canonical URLs
Sitemap configuration
Page performance
Crawlability
I also discovered that adding structured data simply because it was available isn't always a good idea.
For example, product listing pages don't necessarily fit Google's Product structured-data requirements.
So instead of adding more schema markup, I removed schema that didn't accurately represent the page.
The lesson was simple:
SEO isn't about adding as much markup as possible.
The markup needs to accurately describe the content on the page.
Performance became important
As more products were added, page performance became another area I had to work on.
Large HTML responses, unnecessary JavaScript, images, fonts, and database operations can quickly make a site slower.
Some of the optimizations I worked on included:
Reducing unnecessary server-side operations
Optimizing image delivery
Preloading important fonts
Reducing unnecessary JavaScript
Improving database queries
Moving static assets to appropriate storage
Reviewing components that were being rendered unnecessarily
The biggest lesson here was to measure before optimizing.
It's easy to spend hours optimizing something that barely affects the actual user experience.
What I would do differently
If I were starting the project again, I'd spend more time designing the data model and SEO architecture before launching.
Directories have a different problem from normal SaaS applications.
Every new product can create another page.
That sounds great initially, but it also means your architecture needs to handle:
Thousands of URLs
Duplicate content
Low-quality submissions
Categories
Search
Filtering
Internal linking
Indexing
Images
Moderation
I would also build the moderation system earlier.
Once submissions start increasing, manually managing everything becomes difficult.
What I'm building toward
CodeHype started as an experiment in SaaS discovery.
The goal now is to make it easier for people to discover useful software while giving founders another distribution channel for their products.
The platform is available at:
If you're building a SaaS, AI tool, developer tool, or app, I'd also be interested in hearing what you're building.
Building the product is only one part of the process.
Distribution is an entirely separate engineering and business problem.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.