What it actually takes to put a site together

By Idea to Traffic Editorial Team · Published August 31, 2026 · Last updated September 27, 2026

Seven sites, and where the time actually went

Across seven sites, built and launched, the build itself behaved roughly as advertised and everything after it did not. Three of five sites returned nothing for every input, live, for two weeks, while every page loaded, every status check came back green and every monitor stayed happy. The data files those tools needed had never deployed, and because unknown paths returned the homepage with a success code instead of an error, the code checking whether the fetch worked never fired.

The rest of the time went the same way. A sending domain sat at "pending" for 12 hours with DNS records that were byte for byte correct and resolving publicly, with no error message at any point. Ad code went live on the first site on August 24 and was still in review on September 7. One site, after being indexed, produced 129 impressions, zero clicks and an average search position of 46.7, which is page five. Revenue across all seven sites to date is zero.

This is for the person who watched the videos and believed them. That was me.

The AI part was not the lie. Generating a working front end in an afternoon is real. It worked, repeatedly, and it is genuinely remarkable. The problem is that the pitch stops there, at the demo, and the demo is maybe a fifth of the job. What follows is the rest of it, in the order it actually happens, with what each part cost in time.

Seven sites, built and launched. Here is the honest version.

0. Before you write a line

Check the name for a trademark. Thirty seconds of searching. It is the cheapest step in the entire process and the most expensive one to skip, because the fix after launch is a new domain, new content, and starting your indexing history over.

Decide the content model honestly. Is this a tool that stays correct once built, or content that needs updating forever? A one time static build cannot compete against sites publishing daily updated pages. Getting this wrong is not a bug you fix later, it is a whole project pointed at the wrong target.

Decide how it makes money before you build. Ads, subscription, or product. Each one changes the architecture. Retrofitting a paywall onto a site designed for ads means rebuilding.

1. The stack, and what you can skip

Hosting on Cloudflare Pages, no cost. A $20 a month host was evaluated and turned out to be unnecessary for static sites. A database only where accounts genuinely exist, which across seven sites was exactly one of them.

2. The build

Six things have to exist from day one, and none of them are the thing you actually want to build: an about page, a contact page, a privacy policy, terms, a human readable sitemap, and a real 404 page. Ad networks check for these. So does anyone deciding whether your site is real.

Any input that changes the answer has to be visible. A pay calculator shipped with the hourly rate hidden behind a collapsed panel. Every visitor computed against a placeholder value and had no idea. It looked perfect.

3. Version control, which belongs here and not at the end

Every guide puts "push to a repository" last. That ordering is the mistake.

Production must never be the only copy of your site. A rebuild that reconstructed two sites from the live pages silently dropped the ads.txt and ad code that had just been added. It was reported as verified and working. A checking script caught it hours later.

Cost: most of a day. Every hour of it traces back to there being no second copy.

Expect friction getting authentication working. On this setup, SSH keys do not function at all, a token can report that it has push access while being unable to push, and commits fail against a signing key that was never created. None of that is in any tutorial.

4. Email, the part nobody mentions

Here is the one that surprised me most. Cloudflare Email Routing receives mail only. It cannot send. It is free, it works well, and it will forward mail to your address all day. It will not send a password reset, a welcome message, or a receipt.

Sending is a completely separate service. That means a second account, a second domain verification, and another set of DNS records.

Cost: 12 hours of waiting. A sending domain sat at "pending" overnight with DNS records that were byte for byte correct and resolving publicly. The fix was deleting the domain and adding it again, after which it verified in under a minute. There was no error message at any point.

One more: if your host offers email address obfuscation, turn it off. It rewrites the address on your contact page into encoded markup. The page looks fine to you and contains no readable address to anything reading the source.

5. Payments, only if you are selling

Do not build the paywall. Rent it. Payments plus accounts plus knowing who has paid is weeks of work and permanent maintenance. Use a payment provider's hosted checkout.

Never store card details anywhere, in any form. Expect small hard limits that are documented nowhere obvious, such as a password hashing ceiling that throws an error above a specific iteration count and costs an afternoon to identify.

Test four things after every single deploy: the paid URL with no account, the page source of a gated page, a real purchase end to end, and a cancellation actually removing access.

6. Verify, and why status checks lie

This is the section I would most want to hand to my earlier self.

Three of five sites returned nothing for every input, live, for two weeks. The tools were completely dead. Every page loaded. Every status check was green. Every monitor was happy. The data files those tools needed had never deployed, and because unknown paths returned the homepage with a success code instead of an error, the code checking whether the fetch worked never fired.

Cost: two weeks of every visitor getting nothing, on sites that had already been reported as working.

A page loading is not a page working. You need two separate checks: does it exist, and does it actually produce a correct answer when a person uses it.

7. Deploying

A deploy replaces your entire site. Not a merge, not a sync. Whatever is in the folder you push becomes the whole site, and anything missing from that folder is deleted. Icons, verification files and ads.txt disappear this way, because those are the files nobody keeps in their working folder.

Attaching a domain does not create the DNS record. Two separate steps, and only one is obvious. All six sites in this network were missing their www address for weeks because the main address worked and nobody thought to check the other one.

8. Ad network approval

You cannot apply until everything above already exists and is live. The policy pages, the working tool, the real ads.txt file, the actual content.

Adding your site to the ad network does not submit it. Adding creates a row. Submitting is a separate step behind a second screen. One site sat idle for a full day looking submitted and was not.

Cost: two weeks and counting. Ad code went live on the first site on August 24. As of September 7 it is still in review. Not an afternoon. Not a weekend.

And it can come back rejected. One site came back "low value content" and had to be rebuilt before resubmission.

9. Being found at all

Publishing a site tells nobody it exists. There is no automatic notification to any search engine. A new domain with no links pointing at it can sit there indefinitely.

You have to register the site with the search engine yourself and submit your sitemap. There is a separate, faster submission protocol that is genuinely useful and that Google does not participate in, so it cannot be your only route.

Cost: two weeks with no indexing path at all, across five sites that were live, verified working and submitted for ad approval the whole time. Approval on a site nobody can find earns nothing.

Then the reality of what indexing gets you. One site, after being indexed: 129 impressions, zero clicks, average search position 46.7. That is page five. Being indexed is not the same as being found, and being found is not the same as being read.

10. The honest arithmetic

Running cost: roughly nothing per month, plus domains at cost. This part of the pitch holds up completely.

Time: weeks of real work, and much of it is waiting on other people's review queues, which no amount of effort speeds up.

Revenue across seven sites to date: zero.

That last number is not a complaint and it is not a reason to quit. It is the number that never appears in the videos, and it is the one you need to plan around. The sites are new, several are still in review, and organic search takes months. All of that is normal. What is not normal is anyone telling you it works differently.

What I would tell someone starting now

Build the thing. That part really is fast now, and it is genuinely fun. Then budget several more weeks for everything above, expect at least one full day lost to something that produces no error message, and check that your tool actually works rather than that your page loads.

None of this is a reason not to do it. It is just the part that comes after the demo ends.

What a working launch still will not guarantee

Working through every step here gets a site built, deployed, indexed and submitted for ad approval. It does not produce traffic or revenue, and it cannot shorten the parts that are other people's review queues, which is where much of the time goes. It also does not stop the individual failures repeating, because most of them are silent and each needs its own check: unknown URLs returning your homepage with a success code, a deploy replacing the whole site and deleting the files nobody keeps in their working folder, a domain attached without its DNS record, and an ad network review that can still come back rejected as low value content.

Questions about launching with AI tools