Shipped: 5 critical bugs fixed on JewelViz this week.
Quick rundown:
Blog image uploads were silently failing (storage policy bug) — fixed
Hero images on the live site were 404ing behind a custom-domain redirect — replaced with proper static assets
Download/share buttons were exporting full-page screenshots instead of clean image files — now pulls the actual image blob
Biggest one: pricing copy across the site said "starts at ₹99, ₹33/photo" — but the actual live plan starts at ₹499. That's a real trust problem I should've caught sooner. Fixed sitewide now: "20 free credits, plans from ₹499 (~₹28/photo)."
Next up: jewelry framing (images were too zoomed out, focus on model not jewelry) and output diversity (same inputs sometimes producing near-identical results).
Still at 0 paying customers — fixing the foundation before pushing harder on growth.
Catching that pricing mismatch is a massive save. A 5x difference between marketing copy (₹99) and the checkout page (₹499) is an immediate trust-killer that causes instant cart abandonment. Fixing that foundation, along with the broken image uploads and 404s, means you finally have a leaky bucket that is fully patched and ready for real traffic.
The technical pivot from full-page screenshots to actual image blob exports drastically improves the product's perceived quality. For an AI image tool, UX polish is everything. If the download feels broken or amateur, users instantly lose faith in the underlying AI generation model.
Solving the jewelry framing issue (zooming in on the product rather than the model) and fixing the output diversity are the exact product tweaks needed to unlock value. When people pay ₹499, they expect high-end, distinct variations, not duplicate poses. Shifting to "20 free credits" is a smart hook to let users feel the value risk-free before hitting that higher price point.
Hi! Thanks for sharing your experience. That's a really valuable suggestion. Right now I was catching these issues manually, but as the product grows, having an automated pre-deployment check for pricing, feature limits, and other user-facing values makes much more sense. I'll definitely add something similar to my workflow. Really appreciate you taking the time to share this.
Pricing copy mismatch is the worst kind of bug because it is silent - the page still loads, the user still converts, and you only find out when someone feels deceived. I run a tools site with around 100 small utilities and that exact class of bug has cost me more trust per occurrence than anything else. I ended up adding a before-deploy grep step where I search the codebase for any number, currency symbol, or hardcoded feature limit and reconcile it against the live config file. Still miss things, but way less often. The image redirect 404 is a great catch too - usually stays buried until a paying user reports it.
You're absolutely right 😅 Every time I think "it's finally ready," another important issue shows up.
The biggest one was definitely the pricing mismatch because it directly affected user trust. Another frustrating one was the download issue where users were downloading the entire page instead of just the generated image. Both were small technically, but had a huge impact on the overall experience.
Thanks for asking!
Debug week hits different — curious what the worst one was? Always find those critical bugs show up right when you think you're done.
That's a great point. I was mainly relying on the upload response, but you're right—successful upload and an accessible file aren't always the same thing. Adding a verification step after upload is a much safer approach. I'll add that to my backlog so the system confirms the file actually exists before moving forward. Really appreciate the practical advice!
the silent upload failure is the one I'd worry about most of the five, not because it's worse but because it's invisible by nature: a storage-policy rejection often still returns 200 from the SDK call, so "upload succeeded" and "the file exists in the bucket" are two different claims. worth adding a cheap post-upload check (HEAD the object, confirm it's actually there) rather than trusting the write call's return value, that's usually how these come back after the fix too.
Exactly. I realised it wasn't just a pricing bug—it was a trust bug. If the first thing a visitor sees doesn't match reality, everything else becomes harder to believe. That's why I decided to fix these issues before focusing on growth. Thanks for highlighting the importance of getting the fundamentals right first.
The pricing copy bug is the real tell here. That's not a technical debt issue, it's a trust signal issue - a visitor sees "starts at ₹99" then discovers the actual floor is ₹499. You just created friction at the decision step, not the implementation step. The fact that you caught this before doubling down on growth is the right sequencing. Most teams push acquisition before resolving these gaps and then wonder why CAC is inefficient.
That's a great question.
For me, "ready" doesn't mean perfect. It means a jeweller should be able to upload a photo, generate a showcase, download it without issues, and feel confident enough to pay for the next one. There are still improvements I want to make, especially around output quality and workflow, but I don't want to wait for perfection. Once the core experience is reliable and honest, I'd rather learn from real users than keep polishing in isolation.
Thanks for asking such a thoughtful question!
You mentioned fixing the foundation before pushing harder on growth.
What are you using as the threshold for “ready” there — a specific level of output quality/reliability, or are you planning to start pushing once these known issues are gone and let real usage expose the rest?
Great question. For me, "ready" doesn't mean perfect—it means the core workflow is reliable enough that a jeweller can upload a photo, generate a showcase, download the correct files, and feel confident that the output is worth paying for.
I also wanted to eliminate trust issues first, like the pricing mismatch, broken downloads, upload failures, and duplicate outputs. Those problems hurt confidence more than they hurt features.
Once those fundamentals are stable, I'll start pushing much harder on growth while continuing to improve based on real customer feedback. I don't think a product like this is ever truly "finished"—real users always expose edge cases you can't discover on your own.