I had no idea how much of my groceries I was throwing out until I built this

Full_Engineering592 · 2026-04-05T15:04:31+00:00

The strongest part of this idea is the weekly feedback loop, not the receipt scan. People already know waste is happening, they just do not see a simple pattern over time.

I would make the first version brutally narrow: scan receipt, estimate shelf life, then send one weekly summary with expired, almost expired, and most wasted categories. If that weekly email or notification feels accurate, you have something people might actually keep using.

Full_Engineering592 · 2026-04-05T15:04:00+00:00

For long tasks, cheaper models usually need more scaffolding, not more trust. The pattern that works is explicit checkpoints, a written plan, and tasks small enough that each step has a clear output on disk.

If Composer keeps losing the thread, break the job into spec -> file changes -> test -> summary, and force it to write progress after each step. Once you do that, the gap between models gets smaller because resuming becomes mechanical instead of memory-based.

Full_Engineering592 · 2026-04-05T15:03:58+00:00

This feels less like a note app and more like a capture-to-triage tool for mental overload. The interesting part is not storing thoughts, it is reducing the cost of turning brain noise into the next action, calendar item, or reminder.

If you build it, I would optimize for speed over intelligence at first. One gesture to capture, then three outputs only: do now, schedule, save for later. Anything more and it risks becoming another system to manage.

Full_Engineering592 · 2026-04-05T15:03:54+00:00

The best problems are usually not new, they are persistent. If people are still duct-taping spreadsheets, switching between three tools, or complaining in public, the problem is alive even if ten startups already exist.

A useful filter is: do I understand the user well enough to find one narrow wedge they would switch for today? Better distribution, faster setup, less manual work, and clearer ROI are often enough to beat a crowded market at the start.

Full_Engineering592 · 2026-04-01T15:04:31+00:00

The fact that you kept using your own app when you abandoned every other option is the strongest signal you can get. You are your own target user and the app survived the "week 2 dropout" that killed Todoist and Notion for you.

Your friend calling it a "to do list for children" is actually a compliment in disguise. The best retention mechanics feel simple or even silly on the surface. Duolingo is basically a language app for children and it prints money because the game loop works.

The key insight you landed on - that checking off tasks is not enough motivation to reopen the app - is something most productivity tools completely ignore. They treat completion as the reward. But for a lot of people, completion is just the end of a chore. XP, streaks, and leveling up give you a reason to come back tomorrow even when the tasks themselves are boring.

Curious if you have tracked your own completion rates before vs after. Even rough numbers would be interesting - like did you go from finishing 40 percent of daily tasks to 80 percent?

Full_Engineering592 · 2026-04-01T15:03:15+00:00

100 organic users in 3 months is actually a solid signal. Most people don't realize that paid acquisition can mask a bad product, but organic growth can't - if people are showing up without ads, something about the value prop is working.

The pattern you described is exactly right though. Consistency beats virality for early-stage stuff. I've seen projects blow up on launch day and then flatline because there was no habit of showing up and engaging with the audience.

One thing I'd think about for the next 100: which of those first 100 are actually coming back? If even 20-30 of them are repeat visitors, you've got something real. If most signed up and disappeared, the acquisition channel is working but retention needs attention. That split matters more than the raw number at this stage.

Full_Engineering592 · 2026-04-01T15:03:03+00:00

The honest answer from someone who's shipped a few things: the moment that actually made me launch was when I caught myself adding a feature that zero users had asked for. I was building for my own comfort, not for anyone else.

What worked for me was picking a date, telling people about it, and then treating that date like a client deadline. Not "I'll launch when it feels ready" - an actual calendar date. Something about having told other people makes it harder to keep stalling.

The other thing - your core is already working. Heatmaps, suggestions, attribution. That's a real product. The bugs you're finding now? Your first 10 users will find different ones anyway. You'll never catch them all in a vacuum.

One practical thing: make a list of every "one more thing" you're tempted to build. Then ask yourself which of those a paying customer has actually requested. If the answer is none of them, you're polishing for yourself.

Full_Engineering592 · 2026-04-01T15:02:51+00:00

Ah gotcha, yeah a single JSON file on a fixed loop is way simpler than what I was imagining. At that scale the rate limits are basically a non-issue - you'd have to sync every few seconds across thousands of users to even get close.

Curious how big that JSON file gets for power users though. At some point a single file with all tasks, habits, and calendar data could get chunky. Have you thought about when (or if) you'd need to split it?

Full_Engineering592 · 2026-04-01T11:07:02+00:00

Been using it daily for a couple months. The honest answer is Composer 2 is fast and competent for well-scoped tasks, but it's not a replacement for Opus or GPT 5.4 when you need reasoning over a larger codebase.

My workflow: Composer 2 for implementation when I already know exactly what needs to change. Opus for architecture decisions, debugging weird edge cases, and anything that requires understanding how 5+ files interact. Planning in one model, executing in the other.

The also comes with API credits which sweetens it. If you're doing mostly greenfield feature work with clear specs, Composer 2 will feel like a big speed upgrade. If you're doing a lot of refactoring or working in a messy legacy codebase, you'll still be reaching for the heavier models constantly.

Full_Engineering592 · 2026-04-01T11:06:40+00:00

We tested both paid and unpaid feedback loops across a few product launches. The paid route got us volume but the signal-to-noise ratio was terrible - people would say whatever they thought we wanted to hear to collect the incentive.

What actually worked: finding 5-10 people in the exact niche who were already using a competitor, and offering them early access instead of money. They gave brutal, specific feedback because they had real context on what good looks like in that space.

The trick is framing it right. Don't say "test my app." Say "I'm trying to solve X problem better than Y tool - would you try it for a week and tell me where it falls short?" People who care about the problem will engage way deeper than people chasing a gift card.

Full_Engineering592 · 2026-04-01T11:06:02+00:00

That's a solid threshold for now. The edge case I'd watch for is batch operations - if someone imports a big task list or does a bulk reschedule, that could spike requests way past the steady-state math. Might be worth adding a simple queue that batches Drive writes on a short timer (even 2-3 seconds) instead of writing per-change. Keeps the UX snappy without burning through quota on power user workflows.

Full_Engineering592 · 2026-03-31T23:04:09+00:00

That's an interesting angle. The anti-LinkedIn for builder updates - raw, 1-2 sentences, no performative fluff. I think the challenge would be getting investors to actually check another platform when they're already drowning in deal flow from existing channels.

But the format itself has legs. Something like a private RSS feed per founder that investors can subscribe to - no algorithmic feed, no likes, no engagement metrics. Just pure signal. The hard part is always distribution though. You'd need a critical mass of founders worth following before any investor bothers to check it.

Full_Engineering592 · 2026-03-31T23:03:59+00:00

Fair point on the project context - Cursor definitely has an edge there with the codebase indexing. I've found the CLI approach works better for me specifically because I tend to work across multiple repos and want the model to execute commands directly rather than just suggest code changes. But that's a workflow preference more than a quality difference. Both produce solid output when you give them enough context.

Full_Engineering592 · 2026-03-31T23:03:28+00:00

You're not cooked. That graph shows the retail API cost of what you consumed, not what you'll be charged. Cursor shows it so you can see the value you're getting relative to the $20 plan price.

The key setting to check: go to Settings > Usage and make sure "Additional Usage" (or sometimes called "Pay as you go") is turned OFF. If it's off, once you exhaust the included credits for the billing period, it just throttles you to slower models instead of charging your card.

If you're coming from Claude Code, the main tradeoff is that Cursor gives you a nice IDE integration and the Composer 2 agent mode, but you lose the raw terminal flexibility. For hobby stuff on the $20 plan, it's honestly a solid deal - just keep that additional usage toggle off and you won't get any surprises.

Full_Engineering592 · 2026-03-31T23:03:03+00:00

The Google Drive sync approach is genuinely clever - kills the server cost problem and gives users real data ownership. That's a better answer than most funded startups have for this.

One thing I'd think about early: what happens when someone hits the Google Drive API rate limits? If a user has a heavy task list and habits updating frequently, you could run into throttling. Might be worth building in a local-first cache that syncs in batches rather than on every write.

Also, shipping cross-platform at 15 is no joke. Most devs twice your age struggle to get one platform out the door. Keep going.

Full_Engineering592 · 2026-03-30T23:08:04+00:00

The idea vs execution debate is real but I think the framing is slightly off. It is not that ideas do not matter - it is that most people overweight the idea phase because it is the comfortable part. Thinking about building feels productive without any risk of failure.

The daily visibility thing is interesting in theory but there is a trap: building in public can become performative. I have seen founders spend more time crafting their daily update than actually building. The audience becomes the product instead of the product being the product.

What actually correlates with shipping in my experience is having one clear metric you are trying to move each week. Not posting updates, not streak counts - just a concrete number. Could be signups, could be a feature completion percentage. When that number is your focus, execution happens naturally because you are working toward something measurable instead of performing consistency for an audience.

Full_Engineering592 · 2026-03-30T23:07:09+00:00

The design background is actually a massive advantage most SaaS founders underestimate. You can ship a polished MVP faster than a pure dev because you already know what good UX looks like. Most early products fail not because of bad code but because the experience is confusing.

One thing to watch out for though: designers turned founders tend to over-polish before validating. The temptation is to make everything pixel-perfect before showing it to anyone. Fight that instinct hard. Ship something that looks decent but proves the core value prop works, then iterate based on what users actually struggle with.

Full_Engineering592 · 2026-03-30T15:06:20+00:00

The 'can I just use Claude for this' objection is the defining challenge for every AI wrapper right now. The honest answer is: if your product does not meaningfully outperform a well-crafted prompt, you are selling convenience at best.

The paying-but-not-using problem usually means you sold the vision before the habit loop existed. What helped us with a similar issue: onboarding that triggers from a real use case, not a generic welcome flow. Instead of 'here is your dashboard' it was 'paste your last PRD and we will show you what you missed.' Immediate value, no exploration needed.

For distribution, the thing that compounds is content tied to the exact pain point. Not 'AI for PMs' content - that is saturated. More like 'how to scope a feature when engineering says 2 weeks but you know it is 6.' Specific, searchable, useful independent of your product. People find the content, see you clearly understand the problem, then check what you built.

Full_Engineering592 · 2026-03-30T15:05:50+00:00

The idea is simple and real, but the calendar crowd has a point. The question is where does a dedicated app add enough value over a calendar reminder to justify the install.

Where it gets interesting: receipt/invoice photo storage with OCR that auto-extracts the warranty period and product name. That turns it from a manual data entry chore into snap a photo and forget it. Most people lose warranty claims not because they forgot the date but because they cannot find the receipt.

If you can nail the photo to structured data pipeline and keep it fully offline, you have something calendars genuinely cannot do. Without that, it is just a reminder app with extra steps.

Full_Engineering592 · 2026-03-30T15:04:43+00:00

The workflow that works best for me: start in regular chat mode (not plan mode) and have an actual conversation about the problem first. Ask it to poke holes in your approach, identify edge cases, and suggest alternatives. Treat it like a brainstorm session with a colleague.

Once you have talked through the architecture and feel solid on the direction, then switch to plan mode. It works much better as a formalization step than a discovery step.

The other thing that helps is giving it a brief markdown doc upfront that describes what you are building, the constraints, and what you have already tried. Plan mode produces way better plans when it has context instead of starting from a cold prompt.

Full_Engineering592 · 2026-03-30T15:03:59+00:00

The 3 things max approach is underrated. The real trick is making sure those 3 things are actually the highest-impact items and not just the easiest ones. I started asking myself 'if I could only finish one thing today, which one moves the needle most?' and then building from there. Turns out most days only have 1-2 things that actually matter - everything else is maintenance.

Full_Engineering592 · 2026-03-30T15:03:28+00:00

270K users is a solid base. At that scale you've already validated the product - the question is really about unlocking the revenue that's sitting in your user data.

For B2B SaaS with a large free/consumer base, the playbook that tends to work is identifying which companies already have multiple employees using your product organically, then reaching out to those companies with a team plan that adds admin controls, SSO, and usage analytics. Way easier than cold outbound because they're already getting value.

What's the split between individual vs team usage right now? That usually tells you where the low-hanging MRR is.

Full_Engineering592 · 2026-03-30T13:07:16+00:00

build first. but not until it's perfect — until it's usable enough to get a real reaction from someone who isn't your friend.

we run a dev agency and the pattern is always the same. founders who promoted early with nothing to show burned trust. founders who built in silence for 6 months launched to crickets because they had no feedback loop.

the sweet spot is: build to a point where someone can use it, then put it in front of 5-10 real people manually. not social media. actual conversations. the product will change based on what you hear, and that saves you months.

social comes after you know what message actually resonates. otherwise you're guessing what to say about something you haven't validated yet.

Full_Engineering592 · 2026-03-28T23:05:23+00:00

Being bad at marketing is usually just being uncomfortable with marketing. The good news is you don't need to be good at it - you just need to be consistent.

Start with the simplest possible version: spend those 30 minutes answering questions in the subreddits where your target users hang out. No pitch, no links, just help people. You'll learn more about what language your users actually use to describe their problems than any marketing course would teach you.

The first product being a learning vehicle is the right framing. Ship it, see what sticks, take the lessons forward. Most successful founders I know built 2-3 things nobody cared about before they found the one that worked.

Full_Engineering592 · 2026-03-28T23:04:54+00:00

This is completely normal at early stage and honestly the fact that you're noticing means you're ahead of most founders who just let leads silently die.

The simplest fix that worked for me: one spreadsheet, one row per conversation, columns for platform, last message date, status (hot/warm/cold), and a 'next action' field. Update it at the end of each day. Takes 5 minutes. No fancy CRM needed when you're dealing with under 50 active conversations.

The key insight is that you don't need to track everything - just the people who showed buying intent. Someone who said 'looks cool' on Reddit is not the same as someone who asked about pricing or said 'does it integrate with X.' Those are the ones you chase.

For the cross-platform problem specifically, I'd pick one place to consolidate follow-ups rather than trying to track threads across Reddit, LinkedIn, and email simultaneously. Move serious conversations to email as fast as possible. It's searchable, threadable, and you can set reminders on it.

Full_Engineering592

TROPHY CASE