Back to the app

How I built this

A product manager's case study

TL;DR: a Hebrew web app that reads a household's smart-meter file and tells them which of 7 Israeli electricity suppliers and 21 plans saves them the most. It runs entirely in the browser, so the file, which contains the customer's name, address and contract number, never leaves their device.

I'm a product manager, not an engineer. I defined the product, made the calls and verified every result; an AI coding agent (Claude Code) wrote most of the code under my direction.

Try it (sample data, one click) →

The problem

Israel's household electricity market opened to competition recently. There are now 7 suppliers offering discounts that depend on when you use power: 20% at night, 18% on weekday afternoons, 7.5% on weekdays only, and so on. Picking the right one requires knowing your own usage pattern, and almost nobody does.

The data already exists. Every smart meter records consumption every 15 minutes, and customers can download a year of it from the Israel Electric Corporation. But it arrives as a CSV of over 30,000 rows that nobody can read.

The competitive gap

The leading comparison site in this space is excellent and far more feature-rich. Its business model is lead generation: according to its own privacy policy, it collects your full name, ID number, phone, email and address, and passes them to suppliers. That's a legitimate model, but it means handing a stranger your identity in exchange for an answer.

I saw room for the opposite promise: get the answer without giving anything away. Not as a policy, but as an architecture.

Key product decisions

1. Privacy by architecture, not by policy

The site is fully static, with no server and no database. The file is parsed in the browser; the identifying header rows are discarded on read, and only date, time and kWh are kept in memory.

Trade-off: no saved results, no lead revenue, and I can't learn from users' data. I accepted that because the promise is the product, and anyone can verify it in the browser's network tab.

2. Said no to PDF bills

The original brief included uploading PDF bills. But a bill only shows a monthly total, and every interesting plan depends on hourly usage. Supporting PDFs would have produced confident-looking wrong answers. Instead, the app explains why it needs the meter file and how to get it.

3. Data integrity over coverage

Plan data turned out to be the real product risk. Public sources contradicted each other: one supplier's day plan was listed at 10–15% in my original notes and 20% in two recent independent sources. I cross-checked, used the two sources that agreed, and stored a source link and check date for every supplier, visible in the app.

4. Model the fine print, because that's where the answer flips

A 7% plan sounds better than a 6% plan, until you notice the 7% only applies Sunday to Thursday. For a household that uses more than about 14% of its power on weekends, 6% every day wins. The engine models real windows: weekday-only discounts, night windows by calendar day, monthly supplier fees, and plans limited to existing customers (shown only if the user says they qualify).

5. One answer, three intents

The results page answers three different questions people actually have:

  • "What's the best deal?": the cheapest plan anywhere, with ₪/year savings.
  • "Can I save without the hassle of switching company?": the best plan at the user's current supplier.
  • "Show me everything": the best plan per company, ranked, expandable to every plan.

Above all three sits one sentence: what you pay today. Every saving is framed against it.

6. Scope I deliberately cut

  • A separate "my usage" tab. Tempting, since the data supports it, but it split the story. I kept the focus on "this is what you spend, this is what you can save", and added only usage insights that are themselves savings (monthly cost, always-on load in ₪/year).
  • A WhatsApp bot. I liked the idea (the file arrives by email on your phone, so forwarding it to a chat is two taps). But it would have required a server and broken the privacy promise. The cheaper test: answer a few people manually on WhatsApp first, and build only if demand is real.
  • Affiliate links. The buttons link to supplier sites with no tracking. This is a learning project, and it keeps the recommendation honest.

How I worked with AI

I treated the AI agent like a strong engineer on my team: I owned the what and the why, challenged its suggestions, and asked it to challenge mine.

What I'd measure

What's next

Stack

Next.js (static export) · TypeScript · Tailwind CSS · Recharts · PapaParse and SheetJS for in-browser parsing · Vitest · hosted on Vercel. Built with Claude Code.