Build It Like You Might Kill It

The first version of a news aggregation platform I built cost me about $400 a month to run. It did one main job a day. And for months, Google Search Console showed nothing. Not a single page indexed.

Both problems had the same cause. I had built a prototype like it was a production system.

How I got there

I came out of tutorial hell trying to do things the “industry standard” way. So the architecture looked serious:

• An EC2 server with a cron job that ran once a day and scraped articles into an S3 bucket.
• Each new file in S3 triggered a Lambda function.
• The AI work ran as a chain of separate steps: entity extraction, summarisation, classification, proofreading, zero-shot tagging.
• Results went into MongoDB collections and were published behind CloudFront.

It worked. That is the trap. It worked, so nothing told me it was wrong except the bill.

The problem was not AWS. The problem was that the architecture did not match the workload. I was paying for an always-on server to do a job that ran once a day, and for a pipeline built to scale before there was anything to scale.

My first fix was a patch: stop the server, and use an EventBridge schedule to wake it at a set time each day to run the jobs. That cut the bill, but it made the product worse. A news site is only as fresh as its last scrape, and mine scraped once a day. I had saved money by making the news stale.

The frontend had a version of the same mistake. It was a Vite single-page app: to Google, every page was an empty shell waiting for JavaScript. I only found out when months went by and Search Console still showed nothing indexed.

Two different symptoms, one root cause: I built what looked like serious engineering, not what the product needed.

Start from what it costs when nobody uses it

The burn rate is what changed my thinking. A prototype exists to answer one question: is this worth building? Every dollar it costs before it answers that question is a dollar spent on a guess.

So the question I now ask first is: what does this cost when nobody is using it?

For the platform’s rebuild, that meant:

• Scheduled jobs instead of always-on servers. The scrapers moved to GitHub Actions runners that only exist while a job runs. A job that runs for minutes should not pay for a server that runs all day. And because each run is cheap, the scrapers can run every few minutes instead of once a day.
• Pay-per-use by default. Cloudflare Workers, Pages and cron triggers, and small databases, cost nothing or close to it at low traffic and scale with real use.
• Server-rendered pages. If search traffic matters, the HTML has to exist before JavaScript runs.

The platform did not stay on free tiers. It now runs on a mix of services, each chosen for one job, and AWS still has a role: it sends the newsletters. The difference is that AWS now does a specific job instead of hosting everything by default. But that is a story for another post.

The cheap design was the harder one to build

This is the part I did not expect.

The cheap architecture is not the simple one. Running on small, pay-per-use pieces means breaking the system into parts that each do one thing, handle their own failures and talk to each other cleanly. That takes design patterns, and design patterns take time.

The biggest example was the AI pipeline. Five separate steps became one call per article that returns everything at once: entities, categories, summaries, key points and a headline. Fewer calls, fewer moving parts, far lower cost.

But one call for everything raises a fair question: what happens when part of the answer is wrong? Making that safe took real engineering:

• Check the input before spending a call. Articles that are too short or arrive garbled skip the model and get a plain fallback.
• If the call fails, the article still publishes, with a simple summary and headline. A failed call never blocks the pipeline.
• Check each part of the output, and fix only the part that failed. On about 4% of articles the model copied the original headline instead of writing a new one. Rather than reprocessing the whole article, a small retry asks for just the headline.
• Record which prompt version produced each result, so when quality changes, I can tell what changed it.

If I had written all of that by hand, I would still be writing it.

This is where AI changed my work the most. Not by writing code faster, although it does, but by making the better design affordable to build. Over the past year I stopped writing most of my code myself. What I still do is the part AI cannot decide for me: what to build, what to run it on, and what not to build at all.

The result: the platform now handles about four times the workload of that first version, at roughly six times lower cost per unit of work. And the news is fresh. Some days I see a story on the site before I see it on social media.

That is the part the EventBridge patch got wrong. Cheaper and better were not a trade-off. The patch made it cheaper by making it worse; the redesign made it cheaper and better at the same time.

An idea for less than $100

The real test of this approach is an idea that does not work out.

FraudFox was an experiment: forward a suspicious email to an address, and get a reply with a phishing risk score and the reasons. It is not a toy. It has a rules engine, a DistilBERT model fine-tuned on 565,000 emails, and email in and out.

It cost almost nothing to build and run. Two Cloudflare Workers, free database and email tiers, a model trained in about 12 hours on a free Google Colab GPU and hosted on a free Hugging Face Space. Running it costs somewhere between nothing and $10 a month.

And it taught me that the idea did not have a market. Not because the technology failed, but because of trust. Forwarding your email to an AI service you do not know is a big ask, and when a phishing checker gets it wrong, the mistake lands on the user. A missed phishing email is not a minor bug.

So I never retrained the model. The service still runs, because it costs almost nothing to leave up, but I stopped investing in it. The prototype answered its question for less than a night out. If I had built FraudFox the way I built that first news platform, I would have learned the same lesson for thousands of dollars.

How I prototype now

1. Ask what it costs when nobody uses it. If the answer is more than a few dollars, the architecture is ahead of the product.
2. Match the infrastructure to the workload. A job that runs once a day should not live on a server that runs all day.
3. Make the pages real HTML if people need to find them through search.
4. Let AI write the code, and keep the design decisions. Cheap architectures need more structure, not less, and that is now affordable to build.
5. Decide what would make you stop. FraudFox was worth building because it could answer “does anyone want this?” cheaply.
6. Graduate deliberately. Move a part to bigger infrastructure when real usage demands it, one part at a time.

Code has become cheap. Infrastructure is still expensive, and so is time spent on an idea nobody wants. The skill that matters now is knowing which of those you are paying for.