My setup: a step-by-step journey building makers.page

People ask what my setup looks like more often than I expect for a project this small. Not because the stack is exotic, it is a fairly standard Next.js app on Vercel with a Postgres database, but because the process behind shipping it is the part that is harder to see from the outside.

This is the honest, step-by-step version: what I used, what I skipped, what broke, and what I would do differently if I started makers.page again today.

Step 1: Starting from a problem I actually had

makers.page did not start as a business plan. It started because I review indie products on YouTube and kept getting the same message: "how do I get you to look at my product?" There was no organized way to submit something, no queue, no public record of what got reviewed.

The first version was not a product. It was a form. Literally a Google Form linked from my YouTube description, feeding into a spreadsheet I checked manually.

That matters for the "setup" question, because the real first tool in my stack was not code. It was a way to validate that people would actually submit something before I spent a weekend building infrastructure for zero users.

Step 2: The actual stack

Once the form proved people would submit, I moved to a real app. The stack settled on:

• Next.js (App Router) for the frontend and API routes in one project, deployed on Vercel
• Tailwind for styling, because I do not want to context-switch into a separate CSS file for every component
• shadcn for base UI primitives I did not want to build from scratch (buttons, dialogs, form inputs)
• Neon Postgres for the database, mainly because serverless Postgres fits a Vercel deployment without me managing a server
• Drizzle as the ORM, chosen over a heavier alternative because I wanted SQL-shaped queries I could actually read six months later

None of this is a special or clever choice. The main lesson from picking it was: boring, well-documented tools let me ship features instead of debugging my own infrastructure decisions.

Step 3: Building the submission and review flow first

The core loop of makers.page is simple: someone submits, I review it, approved products get a public profile. I built that loop first, before anything else, including before the homepage looked good.

Concretely, in order:

1. A public /submit form that writes to the database
2. An internal view (not fancy, just a filtered table) for me to see new submissions
3. An approval action that flips a status and generates a public profile page
4. The public /products directory and individual product pages

I did not build user accounts, payments, or admin dashboards in this phase. The entire point was: can one person submit, and can I approve it, end to end. Everything else was premature.

Step 4: Writing the description and SEO layer

Once the core loop worked, the next problem was discovery. A submission form nobody finds does not help anyone.

This is where the site picked up:

• Structured metadata and JSON-LD on product pages so approved profiles are eligible for rich results
• A sitemap and RSS feed generated from the actual content, not hand-maintained
• Dofollow links on approved profiles, because nofollow links quietly hurt new founders more than most directories admit
• A blog covering the exact problems the audience already searches for, like getting a product description approved or finding your first 100 users

None of this happened in week one. It happened after the core loop was proven, because SEO content written before you know your actual audience tends to guess wrong about what they search for.

Step 5: The daily workflow now

The day-to-day process looks less like "building a startup" and more like a routine:

• Mornings: review new submissions, sign up for the product, actually try it, decide approve or pass
• A block of deep work: fix bugs, ship one improvement, sometimes write a blog post
• A short public update: one honest post about what shipped or what broke that day
• Occasional YouTube review: for approved products that fit the channel, filmed as a real first-use, not a highlight reel

That daily update habit is the same discipline I wrote about in building in public without burning out. Separating the building block from the posting block keeps both sustainable.

What broke along the way

Being honest about the setup means being honest about what did not work on the first try:

• The first version of the review flow had no status history, so I could not tell if a submission had already been reviewed and rejected before. Fixed by adding a proper status field instead of a boolean.
• Early SEO metadata was copy-pasted across pages, which meant duplicate titles across products. Fixed by generating metadata per product from the actual submission content.
• I underestimated how much time reviewing products actually takes. A queue that looks manageable at 10 submissions a week does not stay manageable at 50 without a lighter internal review view.
• The original middleware.ts redirect logic needed migrating as the framework evolved, a reminder that even boring infrastructure needs occasional maintenance, not just feature work.

What I would change if I started over

If I rebuilt makers.page from scratch today, knowing what I know now:

• I would build the internal review tooling earlier. It stayed a rough table for too long relative to how often I use it.
• I would write the first two or three SEO blog posts before launch, not months after, since they take time to get indexed and start ranking.
• I would keep the "one core loop first" discipline, which worked, and resist adding secondary features (accounts, notifications, anything non-essential) even earlier than I already did.

Frequently asked questions

What stack do you recommend for a project like this?

Whatever stack you already know well enough to move fast in. The specific tools (Next.js, Postgres, Tailwind) matter less than picking boring, documented technology you are not simultaneously learning and shipping with.

How long did it take to go from idea to a real product?

The Google Form version existed for a few weeks before the first real app version shipped. The core submission-to-approval loop took about a weekend of focused work once I committed to building it properly.

Do you use any project management tools?

Nothing elaborate. A simple task list and the submissions table itself function as the backlog. Overhead scales with team size, and this is a one-person operation.

How do you decide what to build next?

Whatever removes friction from the core loop (submit, review, approve, publish) comes first. Everything else waits until that loop is solid.

The honest summary

There is no secret tool behind makers.page. The setup that mattered was building the smallest possible version of the core loop first, being honest about what broke, and keeping the daily process simple enough to sustain for months instead of one exciting week.

If you are building something similar and want a low-effort distribution channel while you focus on your own core loop, submit your startup to makers.page. I try every product myself before anything goes live.

Related reading:

• Building in public without burning out
• How to get your indie startup featured