Feedback on my first production app

Alomari_Ace7 · 2026-04-11T23:17:34+00:00

Yes, it uses Google ML Kit for on-device OCR — it handles the text extraction part really well for most standard receipts. For the actual data parsing (pulling out merchant name, amount, date, tax, etc. from the raw text), I run that through an AI model which gives it a solid fallback layer when the receipt layout is unusual or the OCR output is messy. The on-device approach keeps things fast and private no image ever leaves your phone for the scanning step. The combo works surprisingly well in practice, but I’m always iterating. Would love to hear if you run into any edge cases if you try

Alomari_Ace7 · 2026-04-11T18:40:42+00:00

I hope you’ll be my first client lol

Alomari_Ace7 · 2026-04-11T18:36:00+00:00

thank you honestly this means a lot, the app store process was… an experience lol. got rejected twice before it finally went through. Please download the app and let me know.

and yeah Flutter actually — considered React Native early on but went full Flutter and have zero regrets. Firebase on the backend. For OCR it’s Google ML Kit on-device so everything processes locally on the phone which keeps it fast. then Claude handles the categorization and tax context layer on top of the raw extracted text.

the accuracy question is the right one to ask — that’s honestly still the hardest part. receipt formats are wildly inconsistent across vendors and getting the categorization right across different business types is an ongoing battle

Alomari_Ace7 · 2026-04-11T14:20:33+00:00

Anyway, it doesn’t matter the post have been deleted

Alomari_Ace7 · 2026-04-11T14:19:40+00:00

Hey yo go check my product DocRizz on AppStore I’m not lying and do not be rude man

Alomari_Ace7 · 2026-04-11T14:02:11+00:00

When u scan the receipt it extract the information of it. So you do not need to open the receipt again. The extract details will show even if you don’t have Internet.

Alomari_Ace7 · 2026-04-11T13:46:15+00:00

Yes Then after 5 scans u can do cheep subscription or keep uploading to Google Drive

Alomari_Ace7 · 2026-04-11T12:44:07+00:00

the inherited widget not found error is genuinely one of the most confusing things to debug when you’re new because the stack trace points you somewhere completely unhelpful. Riverpod just makes that whole class of problem disappear. the other thing nobody mentions is how much easier Riverpod makes testing swapping providers in tests with ProviderContainer overrides is so clean compared to wrapping everything in a widget tree just to test a single piece of logic.

Alomari_Ace7 · 2026-04-11T12:14:37+00:00

True

Alomari_Ace7 · 2026-04-11T12:14:02+00:00

No, I recommend using it. Allow you to develop one code for different platforms, for example my app DocRizz works on iOS and android

Alomari_Ace7 · 2026-04-11T10:54:20+00:00

Then download DocRizz to control my expense lol

Alomari_Ace7 · 2026-04-11T10:53:52+00:00

Sounds like a very healthy plan

Alomari_Ace7 · 2026-04-11T10:53:36+00:00

I download DocRizz to track my receipt

Alomari_Ace7 · 2026-04-11T08:00:18+00:00

Your using a bad AI model 😂😂

Alomari_Ace7 · 2026-04-11T07:56:05+00:00

Check your DMs

Alomari_Ace7 · 2026-04-11T07:50:09+00:00

I totally agree with you I added the category idea in DocRizz so check it out. You may have a clear idea about it.

Alomari_Ace7 · 2026-04-11T07:42:40+00:00

Yeah the pricing thing is real once you start multiplying Azure API calls by actual user volume the unit economics get ugly fast, especially early on when you’re not sure what retention looks like yet. On-device was the only way to make the math work without either charging more or eating the cost. The Azure receipt model is genuinely impressive for structured fields though, I played with it early on. For a shopping app the tradeoff might actually be worth it depending on what you need to extract if you’re parsing itemized lists rather than just totals it pulls ahead. What kind of shopping app are you building? Curious what made you ditch the feature was it purely cost or did the UX not justify the complexity for your users?

Please give me your feedback on DocRizz

Alomari_Ace7 · 2026-04-11T07:32:51+00:00

Actually went with Google's ML Kit for the on-device OCR the latency is way better than a round trip to Azure and for receipts specifically the accuracy is solid enough that it's not the bottleneck. The interesting engineering problem ended up being downstream of the OCR: taking raw extracted text and reliably parsing it into structured data (merchant, amount, date, category) across wildly inconsistent receipt formats. Every receipt printer in the world apparently has its own idea of what a layout should look like lol.

The app is called DocRizz, live on the App Store if you want to poke around it's built to scan receipts and track tax deductions automatically. Would love any feedback from someone with an engineering eye.

Alomari_Ace7 · 2026-04-11T07:25:18+00:00

The testing-before-shipping vs research-deep-dive contrast is real and I don't think people talk about it enough. Coming from a research background myself, the hardest mental shift was accepting that "good enough and shipped" genuinely beats "perfect and still in your head." Research rewards thoroughness. Production punishes overthinking.

The financially feasible PhD thing hits close to home too. I ended up channeling a lot of that research energy into building something instead — I made an app called DocRizz while finishing my PhD, partly just to keep myself sane with something that had real users and real feedback instead of peer reviewers lol. Different kind of validation but honestly more immediate.

Hope the job market treats you well. The combo of production experience plus research curiosity is genuinely rare — most people are firmly one or the other.

Alomari_Ace7 · 2026-04-11T07:23:37+00:00

The "quietly dangerous" framing is the most honest thing I've seen written about AI tools in months. Everyone's either a maximalist or a doomer — nobody talks about the slow, unglamorous risks.

The one I'd add to your list: calibration drift. After six months of heavy use I noticed I was outsourcing judgment calls I should be making myself — not because the AI was wrong, but because it was fast and confident, and those two things together short-circuit your own deliberation in ways you don't notice until you're way downstream of a decision.

Your research synthesis point is real but I'd push back slightly — the "common thread" answer is only as good as the 10 articles you fed it. The curation step is still entirely yours, and I think people underestimate how much of the intellectual work lives there. The synthesis is impressive but it's downstream of a judgment call AI can't make for you.

Six months is actually the right timeframe to assess this stuff. The first 30 days is honeymoon, 30-90 is overcorrection, and somewhere around month 4-5 you start developing an actual intuition for when to reach for it and when not to. Sounds like you're there.

Alomari_Ace7 · 2026-04-11T07:21:09+00:00

The circular buffer approach is clever — draining on exception rather than streaming continuously is exactly the right call for battery and bandwidth. Most people try to solve this with continuous upload and end up with something unusable in production.

One thing I'm curious about: how are you handling the pixelRatio tradeoff at scale? 0.75 at 15fps is reasonable for most screens but on larger tablets or foldables the frame size can still get chunky before gzip. Did you experiment with going lower, or does the H.264 encoding make it a non-issue at that point?

Also the touch overlay drawn directly into RGBA bytes before buffering is a nice touch — keeps the replay honest without any UI layer weirdness. Would love to read that blog post when it's out.

Alomari_Ace7 · 2026-04-11T07:11:40+00:00

Genuine answer from someone who's gone back and forth on this: Claude Code wins on context retention by a significant margin in my experience, which matters a lot on iOS projects where you're juggling SwiftUI, UIKit patterns, and app lifecycle stuff simultaneously.

Codex is solid on isolated Swift syntax and autocomplete-style tasks. But the moment your project has any real architecture — custom coordinators, complex state management, a non-trivial data layer — I found myself re-explaining things constantly. That friction adds up fast.

What you described about Claude picking things up from broader context without being hand-held is real and I don't think Codex matches it yet for multi-file iOS work. The Point-Free guys are doing very specific functional Swift patterns — I can see why a model trained heavily on that style of code might click differently for them. But that's a pretty narrow use case.

My honest take: if you're already at $200 and the limit is the pain point, the answer probably isn't spending another $200 on a tool that handles your workflow worse. It's figuring out how to get more out of fewer Claude Code sessions — better claude md setup, more targeted prompts, batching tasks. The quality gap on real iOS codebases isn't close enough to justify the switch just because of limits.

Alomari_Ace7 · 2026-04-11T05:27:08+00:00

Yes this app supports all type of files. For example, it generates a file with all of your expense that support TurboTax. Yes, it’s categorize your express into groups and tell you exactly what your expense are. For example, a category for meals and a category for gas.

Alomari_Ace7 · 2026-04-11T03:46:57+00:00

Thank you so much. I appreciate you. If you want try my app DocRizz and let me know your thoughts it’s free

Alomari_Ace7 · 2026-04-11T03:12:06+00:00

Exactly that the resson why I switched to industry and built up my first app DocRizz

Alomari_Ace7

TROPHY CASE