01
The product constraint
A calculator is judged at the exact moment a user enters an expression. Operator precedence, nested parentheses, incomplete input, and invalid states are not edge decoration; they are the product. A generic evaluator would have reduced initial work, but it would also have moved the most important behavior outside the app’s control.
02
The technical center
I built the expression engine as a recursive-descent parser in Kotlin. The grammar separates expression, term, and factor rules so precedence follows the structure of the parser instead of a pile of special cases. The result is a focused engine that I can reason about alongside the interface that feeds it.
03
The product consequence
Owning the parser makes error behavior and input handling product decisions. The app can reject malformed expressions deliberately, keep evaluation rules consistent, and evolve the calculator without waiting on a broad library’s API or carrying features it does not use.
04
What this demonstrates
The interesting work is not that the app contains a calculator screen. I identified the part users must trust and chose to understand and implement that part directly.
The public case focuses on product decisions. Source access depends on the project.
Ask about related work →