At first, the idea looked simple: collect offers from multiple stores and show them in one place.

But after working on the project, I realized that deal aggregation is not really a “collect more data” problem. It is mostly a data quality problem.

The easy part: collecting offers

Getting raw offers from different sources is not the hardest part.

Many stores, marketplaces and affiliate networks provide feeds, APIs or structured data. On paper, this looks straightforward:

• fetch offers

• normalize the data

• save them in the database

• show them in the app

But raw deal data is often messy.

The same product can appear in different formats. Some feeds include prices, some do not. Some promotions include images, others only include text. Some links work today and break tomorrow.

That is where the real work starts.

The harder part: filtering bad data

One of the biggest lessons I learned is that more offers do not always make the product better.

If the app shows expired discounts, broken links, unclear promotions or low-quality offers, users lose trust very quickly.

Some examples of problems I had to deal with:

• products that disappear from the original store

• expired promotions still appearing in feeds

• missing images

• unclear promo descriptions

• wrong or incomplete price data

• duplicate offers

• affiliate links that need validation

• different currencies and languages

• stores that provide many rows, but very few useful deals

So instead of focusing only on quantity, I had to focus more on rules like:

• should this offer be public?

• is the discount real?

• does the link still work?

• is the promotion useful for users?

• should this store be shown as product deals, promo-only, or hidden?

Why link validation matters

For a deals app, link quality is critical.

If a user taps a deal and the original store page is broken, the app immediately feels unreliable.

That means the backend cannot just import everything blindly. It needs some level of validation and cleanup.

In my case, I had to think about:

• blocking known broken product URLs

• detecting products that return 404

• avoiding false positives from temporary rate limits

• keeping expired items out of public results

• separating real broken links from temporary server errors

This is a lot less exciting than building UI, but it matters much more for user trust.

Promo codes are different from product deals

Another thing I learned is that promo codes and product deals should not be treated the same way.

A product deal usually needs:

• product title

• image

• old price

• new price

• discount percentage

• product URL

But a promo code or store promotion may only have:

• title

• short description

• code

• start/end date

• store URL

Trying to force both into the same UI can make the product feel messy.

So I separated the experience: product deals are shown as deal cards, while promo codes and store promotions have their own section.

That made the app easier to understand and also helped avoid showing empty or broken image placeholders for promotions that do not have images.

Flutter UI lessons

On the Flutter side, one lesson was that “no data” and “missing data” states are very important.

It is easy to design the perfect card when every field exists. But real data is not like that.

Some offers do not have images. Some stores do not have active promotions. Some filters return fewer results than expected.

So the UI needs to handle:

• loading states

• empty states

• missing images

• long text

• different currencies

• different screen sizes

• slow network responses

For a shopping/deals app, the UI also needs to feel fast. Users do not want to wait too long just to browse offers.

Backend lessons

The backend became more important than I expected.

A simple “get deals” endpoint is not enough when the data comes from many sources.

The backend needs to handle:

• source-specific cleanup

• freshness rules

• filtering

• pagination

• promotion cleanup

• link rules

• store visibility

• API limits

• scheduled sync jobs

One useful decision was to avoid showing everything forever. Deals and promotions need freshness rules, otherwise old data stays visible and makes the product worse.

The main lesson

My biggest takeaway so far:

A deals app is not valuable because it has many offers. It is valuable when users can trust that the offers are useful.

That changed how I think about the product.

Instead of asking “how can I import more deals?”, I now ask:

• how can I improve quality?

• how can I remove bad data faster?

• how can I make the UI honest when data is missing?

• how can I make users trust the app?

What I’m working on next

The next things I want to improve are:

• better deal validation

• better promo code filtering

• more reliable store sources

• better handling for expired offers

• Android release

• clearer onboarding and positioning

This project taught me that building a real product is not only about features. It is also about boring but important details: cleanup, validation, edge cases and trust.

Project website: https://discounthub.uz