Opalescent
Personal project · Product design · AI-assisted build · Closed beta
Context
I started Opalescent to solve a problem I shared with many other opal enthusiasts: figuring out what a stone is really worth. I already knew opals. I cut and polish them as a hobby and understood the taxonomy. What I didn’t know was whether that problem could become a useful product—or a financially viable one. The project started with research and design, moved into code, and eventually pulled me into running a small business around the product.
Challenge
Opal valuation takes experience, research and judgment. Two stones that look similar at first glance can have very different values depending on body tone, brightness, pattern, play-of-color, origin, size and condition. I wanted to find out whether my domain knowledge could become a useful consumer product, whether AI could make parts of the process more consistent, and whether the niche was large enough to support a viable app.
What I've learned
Design systems matter more when execution speeds up.
Once design can move into code quickly, clear rules become more valuable than piles of polished screens..
AI quality has to be measured.
Ground truth, evals, confidence and corrections changed how I think about designing AI products. A believable answer is not enough.
Judgment is still the scarce input.
Some of the most important decisions were things I chose not to ship: bad optimization, fake data, wrong physical measurements and unsupported certainty.
AI expanded how much of the product I could take on myself. My design and software experience gave me the framework to know what needed to happen next—and whether the result was good enough.
01
Research & product definition
Is this a real problem—and is there enough of a market?
Lionel
Domain expertise · Product definition · Business strategy · Research · Testing
AI partners
ChatGPT · Claude — market research · modeling · structuring · validation
Context
I already knew the domain from cutting and polishing opals. What I didn’t know was whether the problem was big enough to support a product.
Challenge
Turn expert judgment into something structured enough for a consumer experience and an AI grader, while testing whether realistic adoption and pricing could support a business.
Goal
Answer two questions: can this become a useful product, and is the niche still large enough to make building it worthwhile?
Starting with a problem I already understood
I documented the characteristics I already use when looking at a stone and turned that knowledge into explicit product requirements. AI helped me organize the information, challenge assumptions and validate the areas where I wanted additional research.
Testing the business case
I used AI for market research, competitor analysis, pricing exploration and realistic subscription modeling. I deliberately used conservative assumptions rather than a pitch-deck version of the opportunity. The conclusion was encouraging: the market is niche, but there is still enough demand to support a real business if the product earns trust and keeps operating costs under control.
Serious collector
Needs evidence, control and enough detail to challenge the result.
Casual seller
Product requirements
Needs speed, clarity and confidence without learning the entire taxonomy.
Range, confidence, evidence, corrections and guided capture.
02
UX architecture
Structure first. Style second.
Lionel
Product strategy · IA · Flows · Interaction design · Review
AI partners
ChatGPT · Claude Design — screen mapping · exploration · prototyping
Context
The idea was already bigger than “take a picture and get a price.” It needed onboarding, capture, grading, evidence, corrections, collection and account states.
Challenge
Make a complex grading and valuation process understandable to both a serious collector looking for evidence and a casual seller looking for confidence.
Goal
Resolve the information architecture and core flows before making visual design decisions.
Capture became part of the UX
A useful grading pass depends on movement, lighting, multiple views and a physical size reference. The product guides capture instead of treating video as a generic upload step.
Guiding principles
1. Honesty over polish — “the honest eye.”
Never claim more than we know.
2. Trust is earned by showing the evidence.
Disclosed before charged. Never a fabricated count, never a hidden caveat.
03
Brand & design system
Turning a visual direction into a system that could move into code.
Lionel
Creative direction · Brand · Visual design · Design system · QA
AI partners
ChatGPT · Claude Design — exploration · production · system documentation
Context
With the product structure working, I could focus on how Opalescent should look and feel.
Challenge
Opals are visually spectacular. The interface needed to feel credible without turning into rainbow gradients, gem-show decoration or generic AI styling.
Goal
Create a clear brand and standardize it into reusable rules that could carry directly from prototype to production.
The stone is the star
I explored multiple visual directions and kept coming back to the same principle: the interface should recede and let the opal provide the color.
Standardization was the next step
Once the direction was established, I formalized typography, color, spacing, states, confidence treatments and reusable components. Instead of handing off individually styled screens, I could hand off rules.
Quiet surfaces
Warm neutrals keep attention on the stone.
Meaningful color
Reusable rules
Color supports opal data and confidence—not decoration.
Tokens and components carried the prototype into production.
04
Designing for the physical world
The camera needed something real to measure against.
Lionel
Concept · Physical product design · Testing · QA
AI partners
ChatGPT · Claude Design · Claude Code — computer-vision research · geometry · print validation
Context
A phone camera can see color and pattern, but it does not know physical size, lighting conditions or whether its own color interpretation is drifting.
Challenge
Give the grader known references without asking users to buy specialized equipment.
Goal
Create a simple printed calibration tool that improves both measurement and confidence.
The calibration card
The card places neutral tone references, a spectral bar, measurement references and fiduciary markers in the same frame as the stone. It is free to print at home because accuracy is part of the core product.
A digital design that had to survive printing
Print validation caught ruler strokes that were too fine for reliable output. It also exposed a scaling trap: a larger card printed at reduced scale could mimic the smaller geometry. The solution combined clearer print instructions with a geometry check in the grading flow.
05
From prototype to product
The prototype became software people could actually install.
Lionel
Product owner · Design lead · Specification · Review · Testing · QA
AI partners
Claude Code — React Native · backend · APIs · version control · deployment
Context
I had a complete prototype and design system. I did not yet have a production app.
Challenge
Move into a real codebase without losing the decisions already made—and without pretending I had suddenly become a software engineer.
Goal
Create a reliable technical foundation, installable builds and a release process that could support real testing.
The handoff became a product audit
Moving the work into code forced assumptions to become explicit. A documentation audit found contradictions between the product brief, design system and handoff material. We resolved them before pushing further.
Learning enough to direct the work
Claude Code handled implementation and explained unfamiliar concepts as they became relevant. I did not need to write the backend. I needed to understand enough to specify it, question it and know when it was wrong.
The process was allowed to stop the release.
Release candidates went through a formal audit gate. One was killed before upload after the audit caught a stray microphone permission, a double-tap that could double-charge a scan, and copy defects. The next candidate fixed the problems and moved into closed testing.
06
Building the grader
Getting an answer was easy. Knowing whether it was right was the real work.
Lionel
Evaluation · Ground truth · Product decisions · Quality control
AI partners
Claude Code · vision models — implementation · eval tooling · model iteration
Context
An AI system can produce a convincing answer while still being wrong.
Challenge
Make accuracy measurable instead of relying on whether a result looked plausible.
Goal
Build a repeatable evaluation loop around ground truth, measured failures, corrections and confidence.
Ground truth before trust
I documented a reference set of my own stones and used it to evaluate changes to the grader. Models were compared head-to-head rather than selected because one looked better in a few examples.
Failures became product requirements
The grader now refuses unsupported inputs, surfaces reasons when evidence is missing, caps confidence when certainty is not justified, and sends user corrections through a second-model adjudication step before accepted corrections become lessons.
I stopped treating AI quality as a prompt-writing problem and started treating it as a product discipline.
07
From product to business
At some point, the work around the product became a company.
Lionel
Founder · Product strategy · Design · Operations · Release decisions
AI partners
Specialist agents — bookkeeping · brand · marketing · release · QA · field audit · operations
I didn’t start Opalescent thinking of myself as a founder
I was trying to solve a problem I shared with many other opal enthusiasts. But once the app was real, the work around it became real too: pricing, store releases, compliance, marketing, finances and customer feedback. That’s when I started building specialized AI agents to handle those functions and realized I was no longer just building an app. I was operating a small company.
Specialized AI roles became part of the operating model
I created specialist agents for the jobs surrounding the product. Each role had a defined scope, expected evidence and clear handoffs. That let me keep moving without pretending one general-purpose AI assistant could replace every discipline.
Pricing evolved as the economics became clearer.
The product moved away from a single simple subscription assumption toward a model that separates low-cost preview work from the more expensive full result. The principle remained the same: disclose before charging and only charge once a usable result exists.
What it took.
Research
Validate the problem, audience and business case.
Product
Define flows, capture, evidence, confidence and correction behavior.
System
Turn the visual direction into reusable design rules.
Build
Move the product into React Native and a production architecture.
Quality
Use ground truth, evals and release gates instead of intuition alone.
Operate
Pricing, release, compliance, marketing, finances and customer feedback.
Where it is now
A closed-beta product, not a portfolio prototype.
Installable and in closed testing
Opalescent is currently in closed beta. The product includes guided capture, AI-assisted grading, valuation ranges, confidence, supporting evidence and correction loops.
Still intentionally honest about the data
The current valuation phase uses live marketplace asking prices as comparable evidence. I do not present those asking prices as completed-sale market value.
AI expanded how much of the product I could take on myself. My design and software experience gave me the framework to know what needed to happen next.
Want to try it?
If you’re interested in trying Opalescent, enter your email and I’ll add you to the beta and send you the download link.