Why a Custom Calculator in a Mobile App Lies
A custom calculator in a mobile app almost never lies intentionally — it errs on small details that accumulate. The user adds three line items, recalculates manually, and it doesn't match.
The discrepancy may be only in the last digit, but after that it doesn't matter who is right: trust in the calculation is lost, and support gets a dispute with no way to resolve it.
Under the hood it's usually binary floating-point arithmetic, where 0.1 and 0.2 sum to not exactly 0.3.
On a single operation this is unnoticeable, but on a long estimate of dozens of lines the rounding error accumulates and surfaces in the total — and differently depending on the order of the terms.
The second reason is different formulas on different screens. The calculator in the card, recalculation in the cart, and document export live on their own implementations: somewhere the discount is calculated before tax, somewhere after, somewhere rounding goes up.
The same order produces three different totals, and the user is the first to catch the app doing this.
The third layer is manual input and formula parsing.
Dot or comma as separator, spaces between digit groups, negative values, pasting a number from the clipboard, a custom expression with parentheses: each unhandled case produces a silently incorrect result instead of an input error.
We break down how this is closed by a single calculation layer: decimal arithmetic instead of floating point, one place for rounding rules, shared formulas for all screens, and parsing scenarios covered by tests — so the total matches both on screen and in export.
What a Computation Core Built for the Task Provides
Arithmetic in a calculation app breaks not on addition but at the edges: tax rounding, recalculation when units of measurement change, long operation chains with intermediate saves.
If formulas are duplicated in the interface and in the background, the branches begin to diverge in the least significant digit — and this is the most expensive category of defects, because it does not reproduce for every user.
The computation core solves this architecturally: a single source of formulas that all screens and background jobs call.
We build it as a separate module on Kotlin Multiplatform and connect it to both platforms — editing a coefficient or operation order is done in one place and does not require two independent releases.
Inside is decimal arithmetic with fixed precision, explicit rounding rules at each step, and parsing an expression into a tree: operation order is defined by structure, not by the order of calls in the screen code.
Recalculation speed on long scenarios relies on incremental tree traversal and a cache of intermediate nodes.
When the user changes one field in a chain of dozens of related values, only the dependent branch is recalculated, the rest is taken from cache — the table updates without noticeable delay, and profiling runs on real scenarios, not synthetic ones.
The effect is then counted in support. A single source of formulas removes discrepancies between platforms, so the share of disputed calculations falls, and inquiries shift from "my numbers don't add up" to usage questions.
Support load stops depending on the number of releases: control value sets in automated tests lock in the result, and any deviation is caught before deployment.
Approaches to Implementing Calculation Logic in a Product
Calculation logic can live on the device, on the shared side, or in a hybrid scheme — this choice determines product behavior when the network drops, the speed of formula edits, and where transaction history settles. Below are real options to choose between, along with their weak points.
| Option | When it fits | Limitations |
|---|---|---|
| On-device calculation | Formulas are stable, instant response and full offline operation are needed | A formula edit cannot be shipped without a new app version; behavior on different platforms must be verified separately |
| Shared-side calculation | Rules change often, a single result for all users is needed | Without a network the calculator does not calculate; every step depends on the communication channel; transaction history leaves the device |
| Hybrid scheme | Both properties are needed: fast response and externally managed rules | More complex assembly, requires explicit mechanics for synchronizing results and resolving formula version conflicts |
How We Choose an Option
The fork rests on two questions: how often calculation rules change and whether the product must calculate offline. If formulas are stable and the user's connectivity is not guaranteed, we calculate on the device and update rules along with a release.
If rules are edited constantly and the same answer for everyone is important, we move calculation to the shared side.
We take hybrid when both properties are needed: local calculation for response and offline operation plus shared rules and result synchronization when connectivity appears.
Stages of Developing a Calculation Module
A calculation core breaks not on the interface but on arithmetic: incorrect rounding at an intermediate step produces a discrepancy with the reference that users notice. Therefore we structure the work order so that code is written after an agreed scheme, not in parallel with it.
-
Formula analysis. We collect primary sources: regulatory documents, tables, files used for manual calculation. For each formula, we record inputs and outputs, units of measurement, rounding rules, behavior on division by zero and out-of-range values.
-
Calculation scheme. We build a dependency graph: which quantities are primary, which are computed, where intermediate rounding is allowed. We agree on the scheme in writing — a correction at this stage costs minutes, in a finished app it costs rewriting the core.
-
Implementation. We separate input parsing (locale, separators, exponential notation) from the computation core — it remains a pure stateless function. We calculate exact quantities in decimal arithmetic instead of floating-point numbers.
-
Test sets. We supplement the customer's reference examples with boundary cases: maximums, negative values, zero, repeated operation application, unit changes.
-
Result verification. We run the sets through automated tests with a tolerance for the last digit, and we resolve discrepancies down to zero. We calculate on real data volume, not on three illustrative examples.
-
Module handover. We provide formula documentation, the calculation scheme, test sets in the repository, and a description of rounding rules. We train the team and remain on support — the module evolves without us.
What the Customer's Team Receives After the Work
A finished app without documentation lives until the first formula change: the calculation diverges from business expectations, and no one can find where to edit.
Therefore, as a result of the work, we hand over not a build but a complete working kit — for each artifact it is clear how the result is calculated and who is authorized to change it.
- Source code — a repository with change history and separated layers: input parsing, computation core, display. It builds from a clean branch with one command, without manual edits on the developer's machine.
- Formula description — a mapping table "business rule → formula → requirement source." A dispute about which rate or coefficient is correct is resolved by checking against this document, not by correspondence.
- Data schema — what is calculated and stored on the device, what goes to the server, how saved calculations are versioned. Old records are readable after a format change.
- Access rights — roles for the customer's employees: who changes coefficients, who approves a version release, where signing keys are stored and how they are revoked when a person leaves.
- Update procedure — how to ship a new formula without releasing a new app version: the rule set is checked against reference calculations, rollback is returning the previous set.
- Reference calculations — a selection of boundary cases: zeros, negative values, rounding, fractional separators, operation order. A discrepancy is caught before release, not from a client complaint.
- Environment and build instructions — what tools are needed, how to raise the build pipeline from scratch, and how to release the app to stores from the customer's account.
Practice: Recalculating Estimates in a Construction Service
What It Was
Estimates for sites were calculated in two passes: an engineer measured volumes on site and recorded them in a notebook, and in the office transferred the same line items into 1C and recalculated manually.
The second pass took 40–60 minutes per site and was effectively the only check of the first. Discrepancies surfaced already at the act stage — when procurement volumes and work orders for crews had been signed.
The causes were systemic: different rounding rules on site and in the office, different formulas for coefficients, line items lost during transfer.
According to our measurements, 6–9% of totals per site did not match, and support requests about arithmetic in estimates accounted for about a third of all first-line tickets.
What We Changed
Formulas were moved into a single module: a custom calculator in the mobile app, the office workstation, and export to the accounting system calculate by the same rules and with the same precision.
A draft is calculated on site without connectivity, goes to the server when the network appears, and an automatic reconciliation compares totals line by line and highlights discrepancies before submission — disputed line items are resolved at the site, not in correspondence with the customer.
After implementation, calculation per site takes 8–10 minutes instead of 40–60, and manual recalculation as a separate stage has been removed.
On a control sample of sites, there are zero discrepancies in totals between the draft and the final estimate, and the share of support requests about calculations fell below 2%.
How On-Device Calculation Differs from Server-Side Calculation
If a formula is calculated directly on the device, the result appears at the moment of touch: no request, no waiting for a response, no dependence on channel quality.
In an elevator, in a warehouse, in roaming, the app keeps calculating, and entered intermediate values remain in local storage.
Server-side calculation provides a single source of formulas: reference books and coefficients change without releasing a new version, and calculation history is available from any device.
The price is latency at every step and complete inability to work without a network: the calculator turns into a form waiting for a response.
A separate topic is uniformity. Real numbers diverge in the least significant digit with different operation order, so we keep totals in integer minor units, and fix the rounding rule explicitly and describe it as in IEEE 754. We run reference input sets through both implementations and compare the result to the last digit.
The most expensive thing is supporting two copies of logic: two sources of truth inevitably diverge, and then retroactive recalculation of totals produces different sums in already closed documents.
It is treated with a shared calculation module that is built from one codebase for both platforms, a formula version inside each saved calculation, and migration when it changes.
In practice, the working scheme is hybrid: calculation happens on the device, while the server is responsible for reference data, synchronization, and recalculating history on request.
Then responsiveness and offline operation remain with the user, while formula uniformity is controlled on the service side.
Technical Doubts Before Starting Work
Before starting, an engineering team asks the same questions: how accuracy is ensured, what happens when formulas change, whether calculation can be embedded into an already working app, and how to prove that previous totals have not shifted. Below are answers on the merits.
How accurate will the calculation be?
We calculate in decimal arithmetic with a fixed scale, not in binary floating point: long chains of charges do not accumulate error, and the total matches to the last digit.
The rounding rule is set explicitly — to the smallest unit, half up, or banker's rounding — and is locked in by checks on boundary sums where the discrepancy appears earliest.
What happens when formulas change?
We describe formulas, rate grids, and coefficients declaratively and move them into configuration, not code. A new rule or changed rate is picked up on the next launch — no rebuild and republishing to stores is needed.
We already have our own calculation logic — what should we do?
We preserve its behavior as a reference: before the first line of new code, we compare totals on your examples, and we move the calculation core itself into a separate module behind a stable interface. We do the surrounding integration and transition in parts, without stopping the current app.
How can we verify that previous results have not changed?
At the start, we lock in a set of reference scenarios: rate slices, boundary sums, discounts, currencies. Every build runs it and compares with the saved total — a discrepancy of at least one digit blocks release.
We hand the set over to you along with the documentation, so verification can be repeated by your own team even after handover.
Let's Discuss the Task and Return with an Estimate and Plan
To return with an estimate and work plan, rather than clarifying questions, we need just one email with a description of the task. The more specific the source data on the custom calculator, the fewer assumptions in the estimate and the more realistic the timelines.
- What the calculator calculates: list of formulas, operation order, rounding rules, and accuracy requirements on long computation chains.
- How the user enters data: step-by-step wizard, free expression with syntax parsing, or import of values from a table.
- Platforms and minimum supported OS versions, whether offline operation and transfer of results between devices are needed.
- What already exists: mockups, prototype, formula table, or a previous app version with which compatibility is needed.
- Integrations and reference data: rates, tariffs, external services, exporting the result to a file or sending by email.
- Access: app store accounts, repository, environments, and test data — they can be handed over at the start stage.
- Constraints: deadlines that must be met and the platform that has priority.
Based on this, we will return with a stage-by-stage work plan, timeline estimate, and team composition: who is responsible for the calculation core, who for the interface and build.
If some data is missing, we will flag it separately and propose how to close it before the start — describe the task, and we will return with an estimate and plan.