One moment / Route transition
The page is being assembled. Navigation remains available while the content catches up.
Product 01 / Dental operations
Oscar.
A dependable Windows desktop product for coordinating cases, financial records, payroll, reporting, licensing, and delivery inside a dental laboratory.
Enter the case dossier
Commercial record is private
Discovery · design · engineering · delivery
.NET · WPF · SQLite
Proprietary system · sensitive records excluded
Case study starts here
01—04
The next chapters inspect the original workflow, the product model, consequential decisions, and the evidence that can be shared responsibly.
01 / Operational context
A dental case moves through people, materials, production stages, payments, and delivery. When those parts live in separate records—or only in someone’s memory—the laboratory loses a shared view of what is happening and who owns the next action.
Before / Product model
A / Fragmented workflow
Case details could be split across paper, conversations, and separate operational notes.
Knowing where work stood depended on asking the person closest to it.
Billing and payroll needed their own reconciliation with the work being produced.
A useful overview had to be reconstructed from several operational sources.
B / Oscar’s product model
The case becomes the common reference for operational and financial activity.
Progress is represented in the product instead of remaining implicit in memory.
Billing and payroll are modeled alongside the work that gives them context.
Operational views can be produced from the same underlying record system.
The comparison documents the product model and intended operational change. No quantitative efficiency claim is made until supporting records can be published.
Workflow model
01 → 05
Oscar treats each stage as part of the same operational story, so the record remains useful from intake through reporting.
The laboratory receives the work and its identifying details.
The job, customer, requirements, and dates gain one reference point.
The current stage and next action become visible to the operation.
Charges and related payroll entries remain connected to the work.
Shared records become an operational and financial overview.
Design constraints
02 / Architecture inspection
02 / SYSTEM VIEW
Oscar keeps the operational record inside a Windows desktop application and uses a narrower external edge for activation and updates. The architecture favors fit, ownership, and recoverability over infrastructure breadth.
01 / Operators
Different responsibilities enter the same product through explicit access boundaries.
02 / Application shell
Work details, deadlines, documents, and production state.
Dentists, technicians, and sales representatives.
Charges, debt, payroll, salary history, and profit views.
Operational and financial summaries from shared records.
03 / Local data
Entity Framework Core connects the application model to a local database.
Import · export · backup · restore
04 / Delivery edge
GitHub API, Octokit, and AutoUpdater.NET support license checks and release delivery.
Decision records
ADR / 001—003
ADR-001
Implemented / platform
Supported by Oscar’s published platform and technology inventory; device distribution is not publicly documented.
ADR-002
Implemented / data
Supported by the documented SQLite, EF Core, database import, export, backup, and restore capabilities.
ADR-003
Implemented / distribution
Supported by the documented activation flow, Octokit/GitHub API integration, and AutoUpdater.NET technology inventory.
03 / Evidence room
03 / ARTIFACT 001
The current public evidence set contains one Oscar dashboard capture. It is useful, but limited. This inspection separates what is directly visible from what still needs a dedicated, privacy-safe artifact.
This artifact proves the visible navigation and dashboard information architecture; it does not prove unmeasured business impact.
A / Visible evidence
The navigation visibly includes cases, technicians, clinics, sales representatives, categories, reports, account, and settings.
Adding a case is available from the global application frame rather than buried inside a secondary view.
Case counts, revenue, completion, profit, debt, and work-type summaries occupy the same operational surface.
The capture supports Oscar’s existence as a designed application with product-specific information architecture.
B / Evidence boundary
A dashboard image cannot prove time saved, cases recovered, adoption, or operational improvement.
The numbers displayed are interface data, not independently verified financial or performance results.
Case detail, validation, empty, error, recovery, permissions, and export states are not visible here.
The image does not prove the sale; that outcome remains owner-verified with its supporting record kept private.
Evidence registry
01 AVAILABLE / 05 REQUIRED
These are the minimum captures needed to document the product rather than merely decorate the case study.
Establish the product shell, navigation scope, primary action, and summary model.
AvailableShow intake, case detail, production state, deadlines, and the transition to completion.
Capture requiredDemonstrate how charges, debt, technician payroll, and salary history connect to work.
Capture requiredShow filters, report structure, and the Excel or PDF export path with safe demo data.
Capture requiredDocument the import, export, backup, and restore controls behind the local-first claim.
Capture requiredDemonstrate the proprietary delivery flow without exposing license, account, repository, or machine identifiers.
Capture required04 / Commercial outcome
04 / OUTCOME RECORD
Recorded outcome
Shipped.Sold.
Oscar was built, deployed, and sold to an operating dental laboratory. That is the supported commercial result; broader operational impact remains unmeasured publicly.
The supporting commercial record exists but is not published.
No time-saving, adoption, case-loss, or financial-improvement number is asserted.
End-to-end ownership
DISCOVERY → SUPPORT
Oscar demonstrates product ownership across the entire path—not only implementation inside a predefined specification.
Six years inside dental laboratories supplied the operational context, vocabulary, handoffs, and constraints.
Translate fragmented case, relationship, financial, payroll, and reporting work into one product model.
Design and engineer the Windows interface, local data layer, access roles, reporting, and recovery paths.
Package a commercial desktop product with activation, updates, deployment, and ongoing support concerns.
What I would change now
RETROSPECTIVE / NOT SHIPPED CLAIMS
These are retrospective improvements informed by the first delivery. They are proposed directions, not features presented as already shipped.
Maintain seeded demonstration scenarios and a release-level capture checklist so workflow, validation, recovery, and permission states can be documented safely as the product evolves.
Move activation and update metadata behind a small, auditable service to reduce GitHub coupling and make license state, release policy, and failure handling easier to inspect.
Make scheduled backups, restore checks, retention rules, and visible recovery status first-class product behavior rather than relying on a manual safety path.
End of dossier / Start of conversation
I’m most useful where domain knowledge, difficult operational states, and product engineering have to meet in one dependable interface.