I applied high-frequency data architecture to expose fake e-commerce discounts. Here is how I built the UI.
Hey Indie Hackers đź‘‹,
I usually spend my time architecting data-heavy applications and processing massive datasets (like training XGBoost models for arbitrage bots). But recently, I got fed up with falling for "50% off" e-commerce deals that were artificially inflated just days before.
I realized the only way to beat deceptive marketing is with the same raw, hard data approach used in trading. That’s why I built PriceProven.
The Data Architecture: Tracking and recording daily price changes across a massive catalog of products requires a highly optimized, scalable backend. The core challenge wasn't just scraping; it was structuring the database to log daily historical snapshots efficiently without blowing up server costs or slowing down query times when a user searches for a product's history.
The UI/UX Philosophy (Against the Grain): When it came to the frontend, I deliberately went against the modern trend of overly spacious, minimalist web design.
I built the dashboard with a dark-mode, terminal-style aesthetic. My primary focus was high information density. I stripped out all the unnecessary empty space. When a user looks at PriceProven, I want them to see the entire historical price chart, the confidence metrics, and the data labels at a single, comprehensive glance.
If a product doesn't have enough tracking history, the system explicitly flags it. No fluff, no marketing tricks—just a raw, dense data terminal for smart shoppers.
We are currently in the pre-revenue stage. I'm curious: for those of you building heavy data-logging tools, what database structure do you prefer for massive daily time-series data?
Let me know your thoughts!
The transparency angle comes through clearly across both posts. Curious how people react when the tool tells them there isn't enough history to verify a discount.
Thanks Aryan! Honestly, the reaction has been very positive. Because the dashboard is built to feel like a raw data terminal with high information density, users actually appreciate the blunt honesty. When they see a 'Not Enough Data' flag, it reinforces the idea that we aren't just guessing or throwing fluff at them to keep them engaged. It sets an expectation of absolute transparency and builds a lot of trust right out of the gate.
That’s an interesting trust signal. People accepting “Not Enough Data” rather than expecting an answer says a lot about how the transparency is being perceived. If you’re open to continuing the conversation, what’s the best email to reach you at?
Thanks, Aryan! I appreciate that. I try to keep my inbox light, but I'm happy to continue the conversation right here in the comments. What did you want to discuss?
That’s fair. I was mainly curious about how you’re thinking about the business as it develops, but happy to keep it here.
Awesome! I'm an open book and would love to discuss the business side of things right here.
Right now, since we're in the pre-revenue stage, my absolute focus is on nailing the data architecture and building a core base of users who truly value this raw, high-density transparency approach.
As the business develops, I'm thinking about a freemium model—keeping the core historical tracking and 'Not Enough Data' flags completely free for everyday shoppers, but potentially offering premium features like real-time drop alerts, custom tracking lists, or even an API for power users down the line.
I'd love to hear your take on it! What specific aspects of the business development were you most curious about? Any models you've seen work well for this type of data-heavy tool?
That’s exactly the kind of thing I’d rather discuss properly than unpack in a comment thread. What’s the best email to reach you on?