Alexey's Blog

I built a price comparison engine. Almost nobody came.

On 29 September 2024, I made the first commit to what would become Tuta e Meia.

The commit message was:

initial version. gets stuck after 2.5k entries

In hindsight, most of the story was already there. There was a real problem, a working prototype, and an engineering challenge immediately asking to be solved. So I solved it. Then I solved the next one. And the next one.

Two years later, Tuta e Meia could crawl dozens of shops across Portugal and Europe, identify equivalent products, preserve price history, estimate cross-border delivery costs, detect suspicious matches, and publish comparisons for thousands of PC components.

Almost nobody used it.

Today I shut it down.

This is the story of where it started, what it became, why all that technical progress did not turn into a business, and why keeping it alive would now be the wrong decision.

The original idea

Buying computer hardware in Portugal often feels slightly unfair.

The same graphics card, processor, or SSD can have very different prices across shops and countries. Portuguese comparison sites do not always cover specialist retailers. European shops may be cheaper, but then shipping, VAT, stock, warranties, and delivery restrictions complicate the apparent bargain.

The idea behind Tuta e Meia was simple: collect those offers, identify when two shops were selling the same product, and show Portuguese buyers the real alternatives.

The name means something like “a pittance.” It was friendly, memorable, and appropriate for a site that was supposed to save people money.

The first version was just a crawler and a database. It read product pages, extracted prices, and inevitably got stuck. Within days it had Celery workers and RabbitMQ. Then came sitemap discovery, retries, proxies, monitoring, product matching, and a web interface.

The project had momentum because every problem had a visible technical answer.

If a crawler failed, improve the crawler. If two shops named the same product differently, improve the matcher. If a site blocked datacentre traffic, change the networking. If the workers overloaded a machine, improve scheduling and autoscaling.

That loop is deeply satisfying. It also hides a dangerous question: does solving this problem produce something people will actually choose to use?

What it became

Tuta e Meia grew far beyond the small script implied by that first commit.

At shutdown, the production system included a Flask website, PostgreSQL, Redis, RabbitMQ, Celery workers, browser-based crawlers, Kubernetes deployments, autoscaling, scheduled discovery and repricing jobs, monitoring, alerts, image storage, currency conversion, and retailer-specific extraction logic.

The crawler ran through a controlled network path, respected retailer-specific delays and URL rules, and treated each shop as its own operational problem. Some shops exposed clean structured data. Others required browser rendering. Some returned plausible pages while quietly blocking automation. A successful HTTP response was not the same as a trustworthy price.

Product identity became an entire subsystem. Retailer titles are inconsistent, model names are ambiguous, and one suffix can distinguish a different board, memory configuration, or regional variant. The system used EANs, manufacturer part numbers, normalized model data, category rules, and conflict checks to avoid merging products that merely looked similar.

Eventually the project covered 68 active retailers. A measured snapshot in August 2026 contained:

Those numbers are real. They are also a good example of how engineering metrics can feel like business progress when they are not.

I could tell you how many stores were active, how many queues were draining, how many pages were fresh, and how many products crossed a national border. I could not tell you how customers reliably discovered the site.

The seductive theory of “just one more improvement”

For a long time, every weakness appeared to have a nearby fix.

The site needed more shops. We added more shops.

The prices needed to be fresher. We increased repricing and built monitoring.

Cross-border offers needed realistic shipping costs. We added route-aware estimates.

The pages needed stronger product identity. We built stricter matching and audit trails.

The site needed more useful surfaces. We added deals, historical lows, retailer pages, market reports, and category views.

None of those changes was foolish in isolation. Many made the product objectively better. The mistake was allowing them to substitute for distribution evidence.

The premise was that a sufficiently complete and trustworthy comparison site would eventually be found. Search engines would index it. Shoppers would arrive. Affiliate clicks would create a small but steady income.

That is not what happened.

In July 2026, after removing my own verification traffic, the site recorded roughly 183 external page views and 33 external devices. The realistic range was around 20 to 32 genuine sessions per month. Most traffic had no useful referrer. Organic search existed, but barely.

Affiliate monetisation produced one pending transaction worth €0.60.

The infrastructure cost only around €15–€25 per month. That was never the real problem. The expensive resource was attention.

Trust was harder than crawling

There was another uncomfortable truth: even if traffic suddenly arrived, the product was not yet trustworthy enough for strong promises.

A price comparison result is not useful merely because a number was successfully extracted. The page must represent the correct product. The offer must still be in stock. The price must be recent. VAT and shipping must be understood. The retailer must actually deliver to the buyer. A cheaper foreign listing is not a bargain if the checkout tells a different story.

We defined explicit trust gates instead of assuming the data was good because the pipeline was busy.

The freshness audit sampled 200 offers. Only 124 were clear passes. Thirty-nine failed and 37 were unclear. A planned 500-row identity audit was not completed. The delivered-cost checkout audit was also unfinished.

This matters because trust is the product. One falsely merged graphics card can erase the value of many correct comparisons. A bargain that disappears at checkout is worse than no bargain at all.

Adding more retailers increased coverage, but it also increased the surface area for stale prices, blocks, redirects, category leakage, and identity errors. Breadth was not free.

Europe did not rescue the thesis

One possible answer was to expand beyond Portugal.

If Portuguese prices were systematically worse, then Tuta e Meia could become the place that found the same product elsewhere in Europe and calculated whether importing it was worthwhile.

We expanded the retailer set and built the supporting logic. The resulting data was useful, but the sweeping premise did not survive contact with reality.

Portugal was not simply “expensive” while Germany was “cheap.” The best market varied by product. France and Belgium often competed well. Delivery routes changed the result. Many products did not have enough trustworthy cross-border overlap. Some of the most attractive apparent savings still required checkout verification.

There were genuine opportunities, but not the clean, repeatable story the business needed.

Expansion also hit a practical wall. Many of the remaining retailers blocked datacentre IP addresses or used interactive protection. Slower crawling did not fix an IP-reputation problem. More engineering could move the boundary, but it would not create demand.

At that point, adding stores had become a way to continue working without confronting the market.

I tried to find another business inside it

Shutting down was not the first conclusion.

I looked for a smaller business that could reuse the machinery and data.

One idea was a verified sourcing report for Portuguese and Spanish PC builders or repair shops. Another was a catalogue and merchant-feed diagnostic service. The matching and reconciliation technology was relevant, but the proposed customers already had distributor relationships, established tooling, or agencies. Selling the service would require founder-led outreach and repeated manual delivery. That could perhaps become a consultancy, but it was not the unattended product I wanted.

I considered exposing prices through an MCP server so AI agents could discover and query them. The deeper research showed that MCP discovery itself was not a moat. Directories and registries were already emerging, agents did not magically create demand, and unreliable source data would remain unreliable behind a new protocol.

I explored using the Tuta e Meia brand for tiny paid utilities: transaction records, moving-box labels, used-laptop health reports, document analysis, and digital templates. Most were crowded by free substitutes. Others introduced privacy, legal, or support obligations. The only low-cost experiment that survived was a small downloadable hospitality pack sold through an existing marketplace—and even that depended on marketplace discovery that had not been demonstrated.

The repeated lesson was the same: automating delivery is not the same as automating acquisition.

Why I shut it down

Tuta e Meia did not fail because the servers were too expensive. It failed because continued operation had no evidence-based purpose.

Leaving it running would have been emotionally easier. The monthly cash cost was small. The dashboards worked. The crawlers moved. Every week would generate another maintenance task that felt urgent and productive.

But a project can become a machine for manufacturing reasons to maintain the machine.

There was no demonstrated acquisition channel, no meaningful revenue, unfinished trust gates, unresolved data-redistribution questions, and no pivot that met my actual requirement: useful, self-serve, low-maintenance, and capable of earning without constant intervention.

The honest options were to commit to sales and editorial work or stop pretending the system was becoming a passive business.

I chose to stop.

On 2 October 2026, I suspended every scheduled job, paused every autoscaler, and scaled every Prices deployment to zero. The historical database and code remain preserved. The live comparison service does not.

The domain is moving to a static page. No application server, crawler fleet, queues, or Kubernetes workload is required to keep a closing note online.

What I would do differently

If I started again, I would reverse the order of work.

Validate discovery before coverage

I would prove that a repeatable group of people could be reached before expanding from a handful of retailers. Ten accurate shops with an acquisition channel are more valuable than 68 shops waiting to be discovered.

Treat distribution as part of the product

“People will find it through Google” is not a distribution strategy. Neither is “agents will discover the MCP server.” A channel must be observable, testable, and capable of delivering buyers at plausible economics.

Define trust gates before adding data

Identity, freshness, stock, and delivered cost should have had hard publication thresholds from the beginning. More data is only an asset when its reliability is understood.

Separate operational metrics from commercial evidence

Stores, products, prices, workers, tests, and deployments measure activity. Purchases, renewals, referrals, and qualified recurring users measure a business. They are not interchangeable.

Set the stop condition early

The project had many technical milestones and no sufficiently sharp commercial deadline. A good stop condition is not pessimism. It protects time from a system that can always suggest one more improvement.

Prefer the cheapest possible falsification

Before building software, sell the report manually. Before creating a marketplace, list one product where buyers already search. Before operating a crawler fleet, learn whether anyone cares about its output.

Was it a waste?

No.

Tuta e Meia taught me more about distributed work, failure recovery, data quality, product identity, crawler operations, and observability than a deliberately small tutorial project ever could.

It also taught me a more valuable lesson: technical difficulty and commercial value are only loosely related.

The hard parts were genuinely hard. Solving them was real work. The absence of a business does not retroactively make the engineering imaginary.

But learning from a project does not require keeping it alive forever.

Shutting it down is not erasing it. It is accepting the answer it produced.

The name Tuta e Meia will remain. It may eventually become something more playful—the sarcastic home of things that cost anything but a pittance. Or it may simply stay as the marker for an ambitious experiment that ran its course.

For now, the most honest product Tuta e Meia can offer is a static page saying: this was built, this was tested, and this is why it stopped.

<< Previous Post

|

Next Post >>