Skip to content
// solo-founder · postmortem · site-architecture

Why I rewrote my 19-product site in two weeks (and what I would do differently)

An honest postmortem of a site rebuild — why the old version failed despite "looking fine", what the rewrite changed, and the four decisions I made too late.

by İsmail Günaydın7 min readupdated

The old ToolGenX shipped a year ago. It looked fine. Nineteen products, OG images, JSON-LD on the product pages, Gumroad checkout. Conversion rate in the first 90 days: about 0.04%. One verified sale.

The new ToolGenX shipped two weeks ago. Same nineteen products. New stack, new tone, new checkout architecture, new content layer. The honest answer to "did it work" is "we will see in 90 days". The honest answer to "was the rewrite worth it" is "almost certainly, because the old site had structural problems no amount of polish could fix".

Here is what I changed and why.

What the old site got wrong (and what most "polished" sites get wrong)

Three things killed the old version. None of them were visible. All of them were structural.

1. The Gumroad redirect cost me trust I never recovered

Every buy button on the old site sent the buyer to modernwebseo.gumroad.com/l/<product>. A different domain. A different visual identity. A different cart layout. A different checkout chrome.

For a tiny percentage of buyers this is fine — they know Gumroad, they trust it, they have an account. For everyone else it is a hesitation moment, and on a $19-$119 product the hesitation moment is the difference between purchase and bounce.

I could not see the bounce in any dashboard because Gumroad does not show me the people who arrive on the checkout and leave. They were a black hole. I was optimizing what I could measure (the product page) without seeing what was actually broken (the checkout transition).

2. The product copy was generic AI-template slop

Every product page had "Transform your workflow with...", "Unlock the power of...", "Industry-leading solution for...". I had drafted them in ChatGPT eighteen months ago, edited them lightly, and shipped.

The problem is not that AI drafted them. The problem is that I did not get them back to sounding like a real person had written them. Generic copy means:

  • AI search engines have nothing distinctive to quote.
  • Google's helpful content classifier has more reason to suspect generation.
  • Buyers cannot tell the products apart by reading the copy.

I ran every product description through humanizer-v2 during the rewrite. Em-dash density dropped from ~14 per 1,000 words to ~3. Banned phrases ("transform", "unlock", "in today's") went from frequent to zero. First-person voice appeared for the first time on the product pages.

3. Zero AI search visibility surface

The old site had product schema. It did not have:

  • A Quick Answer block on any page (the GEO-citable structure).
  • A real Person entity for the author.
  • An llms.txt file.
  • An AI-crawler-friendly robots.txt (the default Allow: / worked, but there was no explicit signal that I wanted to be cited).
  • Any cornerstone blog content that AI engines could pull from.

I wrote a separate post on the GEO + SEO short list. The summary is that all five of those things are cheap to add and compound over time. None of them existed on the old site.

What the rewrite changed structurally

The rewrite was not a refactor. It was a different site that happens to sell the same products. The decisions that mattered most:

Direct Stripe + Iyzico, no redirect

Stripe Checkout and Iyzico Checkout Form both wired up — both accept global Visa, Mastercard, and Amex, and Iyzico also unlocks Turkish lira + taksit + e-fatura for buyers in Türkiye. Provider picker at checkout lets the buyer choose. Webhook to Supabase that issues a license, increments the download counter, and sends a Resend confirmation email. The Gumroad redirect is gone. Buyers stay on toolgenx.com from arrive to receipt.

I wrote a longer comparison of the three checkout options for anyone making this decision themselves.

Per-type product page layouts (content-driven uniqueness)

Toolkit-style products and template-style products now get subtly different page layouts. Same React component, different section emphasis driven by a layout field on the product. Toolkit pages lead with workflow, template pages lead with file inventory. The visitor gets a page that matches what they are about to buy.

There are no two products with the same layout fingerprint. Even within "toolkit" or "template", the content forces uniqueness because the products are actually different.

Honesty as a design pattern

Every product page has a "What you do NOT get" block. The homepage has a "This is probably wrong for half of you" section. The About page has a timeline that includes failed projects, not just successful ones.

This is not a marketing gimmick. It is a filter. The right buyer wants a real read on whether the product fits their situation. The wrong buyer needs to be told quickly that it does not, so they leave before they buy and then ask for a refund. Honesty up front costs me some sales and prevents many more refunds.

Global refund flow with consent logs

The refund flow now satisfies the strictest applicable law (EU Consumer Rights Directive Article 16(m)) which means it satisfies every other jurisdiction by default. Dual checkbox consent at checkout. Consent text + IP + user-agent + timestamp logged for 6 years. EU Withdrawal Button in the buyer's account starting 19 June 2026.

This is not optional and the old site did not have it. The new site does.

Content gravity

Four cornerstone blog posts shipped with the rewrite. One hub (this one), three spokes. Every post has a quickAnswer field, 3-5 FAQ items, Article + Speakable + FAQPage schema, and links to the products it naturally references. The blog index is at /blog.

This is the part that takes longest to bear fruit. Indexation is fast (Google + AI engines re-crawl within days). Citation share takes months.

What I would do differently

Four things, in order of regret.

1. Write the cornerstone blog posts first

I built the site, then wrote the posts. Should have been the opposite. The posts force you to articulate who the buyer is and what they are trying to accomplish, which then makes the product copy easier to write because you already have a voice and a framing.

Doing it the other way meant I had to rewrite product copy after the blog posts revealed the voice. Cost me roughly a week of extra editing.

2. Use real images from day one

The new site ships with text-only product cards and a wordmark logo (no image yet). Phase 5 will add real product hero images and a favicon. This is fine for launch but it means I am missing OG image optimization and product card scannability.

Should have either commissioned a designer for a couple of days or generated + curated AI images with a tested prompt library before launch.

3. Build the refund flow before the checkout flow

I built Stripe checkout, then realized I needed the consent logging table, then realized I needed the Withdrawal Button, then refactored both. If I had built the legal evidence schema first — consent_logs, withdrawal_requests, the dual-checkbox UI — the checkout integration would have plugged into it cleanly.

This is a "boring before exciting" pattern that I keep relearning.

4. Cut the locale skeleton further

next-intl is installed and ready for additional locales. I shipped only English, with the routing scaffolded for future TR/AR/ES. In retrospect I should have either committed to TR + EN day one (Turkish-market reality) or stripped i18n entirely until I needed it. The current "scaffolded but unused" state is a maintenance tax for a hypothetical future.

I will likely add TR within the next month, which retroactively justifies the scaffold. But if you are in my position, you should make the call explicitly instead of leaving it ambiguous.

The 90-day plan

The rewrite is the easy part. The next 90 days are about distribution:

  • Weeks 1-4: Ship 1-2 blog posts per week. Same channel (long-form writing on the site, syndicated to Medium and dev.to).
  • Weeks 5-8: First measurable AI citation tracking. Set up monthly checks in ChatGPT, Perplexity, Gemini for our product names.
  • Weeks 9-12: Read the conversion data. If sales are up, double down on what is working. If sales are flat, the answer is not the site, it is the offer.

The rewrite was a prerequisite, not a deliverable. The actual work is dragging the trust signals and content gravity into place over a long time. That is what the next 90 days are for.


Written from the inside of a small shop. The four lessons above are the ones I would tell a friend rebuilding their own site. If you want to dig into the specific technical choices, the solo founder guide and the GEO + SEO short list cover them in depth.

// faq

Frequently asked

Why three weeks and not faster?
Two weeks of code, one week of content. The code is the easy part once you have done it a few times. The content rewrite — getting 19 product descriptions through humanizer and shipping four blog posts — took as long as the entire technical build.
Did the rewrite immediately improve conversion?
I do not know yet. The rewrite shipped two weeks ago. I am writing this so future-me has a reference for what we changed and why. Real conversion data will come in over the next 90 days.
Would you rewrite again from scratch or refactor?
Refactor, but only if the foundation is sound. The old ToolGenX had unfixable foundation problems — Gumroad redirect baked into the buy flow, generic product copy, no GEO surface. None of that is a refactor. A rewrite was the right call.
How do you avoid scope creep on a rewrite?
Write the PRD before touching code. Be specific about what is in scope and what is out. Mine had a "kapsam dışı" (out of scope) section that saved me three times when I was tempted to add a feature mid-build.
What is the one thing you would do differently?
Write the cornerstone blog posts first, then build the site. Doing it the other way meant I had to rewrite product copy after the fact to match a voice I had not yet figured out. Cost me roughly a week of extra editing.

// related products

// related writing

Written by

İsmail Günaydın

Software Engineer · SEO/GEO/AEO Strategist · Digital Entrepreneur

Software engineer and digital entrepreneur with 15+ years building SEO-driven products. Founder of ModernWebSEO and ToolGenX. Focused on developer experience, web performance, and making technical content accessible. Builds customer-generating digital infrastructure through SEO, AEO, and GEO strategies.