DEV Community: Philip

I rewrote my calculators in a second language to test them. It found four wrong numbers.

Philip — Mon, 31 Aug 2026 19:10:41 +0000

I shipped a set of free investing calculators. Each one has a card on the index page showing a worked example: given these inputs, here is the answer.

Last week I found that one of those cards said $2,282 while the calculator underneath it produced $1,160.

Nobody had complained. Every test passed. TypeScript was happy. The number had been wrong for weeks.

Why this kind of bug is invisible

The calculation lives in a React component. The published example lives somewhere else entirely, in a plain manifest file that feeds the index cards.

Those two files have no relationship. Neither imports the other. So when I changed the model to let uninvested cash earn interest, the component's output moved and the manifest quietly did not.

This is not a code bug. The code was correct the whole time. It is a claim bug: the site asserted something that was no longer true, and no type system checks assertions about arithmetic.

I suspect this is extremely common. Most products publish numbers somewhere, in a pricing table, a docs example, a README, a marketing card, and almost nobody has a test that says "the thing we told people is still what the software does."

Why a unit test would not have caught it

The obvious fix is a unit test. But a unit test written against the same implementation only encodes whatever that implementation currently does. If I had asserted that the function returns 1,160, I would have been asserting that the code does what the code does. Useful for catching regressions, useless for catching a wrong published claim.

What I actually needed to check was different: does the number we publish match the number the tool produces? That needs a second, independent implementation, ideally written by someone who read the description rather than the source.

I do not have that someone. So I used a different language as a rough substitute for a different brain.

What I built

A small script in Python that reimplements every calculator from scratch, then compares its results against the figures published on the site.

Three decisions made it worth the afternoon.

It reads the inputs out of the component source. Rather than keeping its own copy of each calculator's default values, the script parses them out of the React files directly. If I change a default, the script picks it up automatically and the expected published figure fails. There is no second copy of the inputs to forget about, which is the failure mode that created the original bug.

It reimplements the maths from the description, not the code. I worked from what each tool is supposed to do rather than translating the TypeScript line by line. Translating would have carried any logical error straight across into the test.

Where a closed form exists, it checks both. The compound interest tool loops month by month. There is also a standard annuity formula that produces the same answer in one step. The script runs both and requires them to agree to nine decimal places. Two different routes arriving at the same number is much stronger evidence than one route agreeing with itself.

What it found

102 checks. Four defects.

The $2,282 that should have been $1,160.

The same card describing the result as "ahead after 11 years" on a setup that runs for 12 months. Two separate errors in one sentence, both invisible because nobody re-reads a card they wrote months ago.

An FAQ on the Coast FIRE calculator claiming that retiring at 55 instead of 65 raises the balance you need at 40 from $276,400 to $762,500. The real figure is $543,700. I had built a correct lookup table of these values and then, two paragraphs later, transcribed the wrong row into prose. $762,500 is the ten-year horizon. Retiring at 55 when you are 40 is fifteen years.

And two worked examples that quietly omitted inputs the tool actually uses. One said "$500 a month for 30 years" while the calculator also starts with $10,000 already invested, which makes the stated result impossible for a reader to reproduce.

The third one is the one that bothers me. It was not stale data or a refactor. I did the arithmetic correctly, wrote the correct numbers into a table, and then quoted the wrong cell in a sentence underneath it.

Extending it past the outputs

Once the script existed, the cheap win was pointing it at every number in the surrounding prose, not just the calculator results.

The dividend reinvestment calculator has an explainer noting that over twenty years the annual income grows 5.9 times, and that this decomposes into the dividend per share growing 3.2 times multiplied by the share count growing 1.85 times. It is a satisfying line. It is also three numbers and a multiplication, every part of which can be wrong independently.

So the script checks all three values, and then separately checks that multiplying the first two actually produces the third. That last check is about the sentence being internally consistent rather than about any single figure being right. If one number drifts, the claim stops holding together and the test fails. No human proofreader catches that on the fortieth read.

What is worth stealing

Test the claims you publish, not only your functions. Any number in marketing copy, a docs example or a card is an assertion your software should be able to verify.

Read the inputs from the source of truth. A test carrying its own copy of the defaults passes happily forever after the defaults change.

Use a genuinely separate implementation for anything with real arithmetic. A different language, a closed form, even a spreadsheet. Checking an implementation against itself only proves it is consistent with itself.

Compare with tolerances rather than exact equality. Floating point plus values displayed rounded means you want a small relative allowance, tight for derived maths and looser for anything shown to the nearest dollar.

The whole thing runs in under a second and is roughly two hundred lines. It has already caught four things that were live on pages real people read.

If you want to see what it is checking, the calculators are all here, free and with no account. But the transferable part is the idea rather than the tools: the numbers you publish are part of your product, and almost nobody tests them.

The SEC gives away every company's financials. Parsing them was the hard part

Philip — Thu, 30 Jul 2026 14:01:54 +0000

I build Intrinsiqq, which computes quality scores, valuations and ten years of financials for around 7,800 listed companies. Every number comes from companies' own filings with the SEC.

People assume the hard part was the finance. It was not. The hard part was that financial filing data is free, structured, machine readable, and constantly, quietly wrong in ways that do not announce themselves.

I want to describe the shape of that problem, because I have not seen it written down anywhere and I would have saved months if someone had.

Why build on filings at all

Most finance sites buy aggregated data from a vendor. I went to the source instead, because filings are free, public, legally usable, and they contain what a company actually told a regulator rather than a vendor's cleaned-up interpretation. It means the numbers on my site reconcile with the annual report, and it is the reason the product can be free at all. I wrote up how the pipeline fits together if you want the overview.

That decision was right. It was also much more expensive than I budgeted for.

The failure mode is silence

This is the thing I want to convey above everything else.

When you consume a normal API and something is wrong, it fails. You get a 500, a schema mismatch, a null where you expected a number, and your monitoring tells you. Filing data does not behave like that. It hands you a number of the correct type, in the correct currency, in the correct shape, sitting in the correct field. And it is wrong.

Nothing throws. Nothing logs. Your tests pass. The page renders. A revenue figure eight billion dollars short of reality looks exactly as convincing as a correct one, because there is no context in which it looks odd unless you already know what the answer should be.

So the entire discipline of the project turned out to be: how do you detect being wrong when nothing tells you that you are?

Fiscal calendars do not agree with anything

Roughly every assumption a developer brings to a date field is wrong here.

Companies do not share a financial year. Some end in December, plenty do not. The year label attached to a filing describes the document, not the numbers inside it, and a single annual report carries several prior years of comparative figures all wearing the same label. Group by the obvious field and you quietly blend three different years into one.

Then there are markers that look like they identify a quarter and actually identify a calendar period, which coincide for some companies and are months apart for others. Two of the largest companies in the world fall on the wrong side of that distinction. If your logic assumes those are the same thing, you misclassify a large fraction of your history and every derived figure inherits it.

Quarters are partly a fiction

Companies file three quarterly reports and then an annual one. There is no fourth quarterly report. The fourth quarter exists only as the difference between the year and the three quarters you have, so anything quarterly has to be reconstructed rather than read.

Reconstruction is where things get interesting, because it is arithmetic on top of data you have already possibly misclassified. Different statements in the same filing also cover different spans: some figures are for the three months just ended, others are cumulative from the start of the year. They sit side by side, look identical structurally, and mean different things. Treat them uniformly and your cash flow figures are inflated by a factor that grows as the year goes on.

There is also a whole category of bugs where a reconstruction runs against incomplete inputs and produces something plausible instead of nothing. Those are the worst ones. A missing value you can catch. A confidently derived wrong value hides.

The same number appears many times and the copies disagree

Any given figure shows up in several filings across several years, and the versions differ, for legitimate reasons. Companies sell divisions and restate history so the comparison is like for like. Companies split their stock and restate per-share figures onto the new basis.

Which means for every duplicate you have to decide which version you want, and the answer is not the same for all kinds of figures. Some of them you want as originally reported. Some of them you want as most recently restated. Pick one rule and apply it across the board, which is the obvious thing to do, and you will be wrong about a large slice of your data while being right about the rest, which makes it very hard to notice.

Every industry breaks your assumptions

I built the first version around a normal operating company: revenue, costs, margins, cash flow, debt.

Then I pointed it at a bank, and there was no revenue, because a bank's revenue is interest and it does not live where revenue lives. Debt is not a risk signal for a bank, it is the raw material. For a property company, the largest expense is a non-cash accounting entry, so the headline profit figure is close to meaningless and the cash figure is what matters. An insurer works differently again.

The lesson generalised well past parsing. A single scoring framework applied to every industry produces confident nonsense, so we route several sectors to their own scorecards. I wrote about how we picked the metrics and why some industries get different rules.

Broad categories sweep in things you did not want

My favourite bug, in hindsight.

Where a specific figure was missing, I fell back to a broader category, which felt like sensible defensive design. Then a payroll processing company showed several billion dollars of investments it did not own, because the broad category included money the company merely holds on behalf of its clients. The correct figure was zero. Nothing looked wrong. It was a perfectly reasonable-looking balance sheet for a company with a five-billion-dollar hole in it.

The general lesson: a fallback that is broader than the thing you are looking for is not a safety net, it is a slow leak. Better to show nothing than to show something adjacent.

What I would do differently

Build the verification harness before the parser. Almost every problem above was found by a person looking at a page and thinking "that cannot be right", not by a test. The only real defence against silent wrongness is checking computed output against totals the filing already states. Does the balance sheet balance? Do the parts sum to the whole? That is unglamorous and it would have caught most of this years earlier.

Treat "no data" as a legitimate answer. A lot of my early bugs came from an instinct to always produce a number. Some companies genuinely have no debt. Some figures genuinely are not reported. Guessing to avoid a blank is how you turn a gap into a lie.

Write down why, publicly. We publish a methodology page covering how each figure is computed, and a process for correcting errors when someone finds one. Partly that is a trust obligation for anything financial. Mostly it is that being forced to explain a calculation in plain language is what exposed several of these bugs, because a rule you cannot justify out loud is usually wrong.

If you want to see the output, Microsoft's financials are built from filings through everything described here.

If you are working on something similar and hitting a category of weirdness I have not mentioned, I would genuinely like to hear about it. I am fairly sure I have not found the last one.

Why we score company quality the way we do (and why REITs and banks get different rules)

Philip — Mon, 15 Jun 2026 14:09:54 +0000

"Quality" is a vague word. Every investor agrees a quality company is good, and nobody agrees on how to measure it. When we built a free stock analyzer, we had to turn that vague word into a number between 0 and 100, which meant making real decisions about which metrics actually capture quality and which ones just look smart on a dashboard.

Here is how we landed on the metrics we use, and the reasoning behind each.

Eight metrics, four questions

We did not want a soup of thirty ratios. More metrics feels rigorous but dilutes the signal: every weak metric you add drags the strong ones toward noise. So we forced ourselves down to four questions a quality investor actually asks, with two metrics each:

Is it cheap enough? Price to earnings, and price to free cash flow.
Is it growing? Revenue growth, and free cash flow growth.
Is it well run? Operating margin trend, and return on invested capital.
Is it financially sound? Share dilution, and net debt.

Each metric earns its place by answering something the others do not.

Why these specific eight

Valuation: earnings and cash flow. Price to earnings is the obvious one, but earnings can be massaged with accounting choices. So we pair it with price to free cash flow, which is much harder to fake, free cash flow is what is actually left after the business spends what it needs to. A company that looks cheap on earnings but expensive on cash flow is waving a flag, which is why we weight the cash-flow measure more heavily.

Growth: revenue and cash. Revenue growth shows demand. Free cash flow growth shows that the growth is turning into real money rather than just bookings. One without the other is a warning: fast revenue growth with no cash generation is how a lot of stories end badly.

Quality of the business: margins and returns. We deliberately look at the margin trend, not the absolute level. A 40 percent margin tells you about the past; a margin that is expanding tells you the business is getting stronger right now. And return on invested capital is the single best "is this actually a good business" number we know: it asks whether the company earns more than its cost of capital. A business that does not clear that bar is destroying value no matter how fast it grows.

Financial soundness: dilution and debt. Share dilution is the quiet killer of returns. A company can grow revenue ten percent a year and still erode your stake by quietly printing shares, so we reward buybacks and penalize heavy issuance. For debt, the key decision was to measure net debt relative to free cash flow, not in absolute dollars. A large debt number is terrifying for a small company and trivial for one generating enormous cash flow. What matters is whether the company can comfortably service it.

Why REITs get different rules

This is where most simple scoring breaks, and where we had to build a separate scorecard. A real estate investment trust looks terrible through a normal lens, and that is the lens's fault, not the company's. REITs own buildings, and accounting forces them to record huge depreciation charges every year as if their properties are steadily becoming worthless. In reality, well-located real estate often appreciates. That depreciation crushes reported earnings, so a price to earnings ratio on a REIT is close to meaningless.

The industry solved this long ago with a measure called Funds From Operations, which adds that non-cash depreciation back to get a truer picture of what the REIT actually earns. So our REIT scorecard throws out price to earnings and uses price to Funds From Operations instead. We also swap in the metrics that actually matter for a landlord business: dividend coverage, because REITs are income vehicles legally required to pay most of their income out, so the real question is whether they can sustain the dividend, and leverage measures like debt to earnings and interest coverage, because real estate is a debt-heavy business by nature. Forcing a healthy REIT through a standard scorecard would wrongly mark it as garbage.

Why banks get different rules too

Banks break the standard scorecard for a different reason: for a bank, debt is not a liability to minimize, it is the raw material of the business. A bank takes in deposits, which are debt, and lends them out. Penalizing a bank for having a lot of debt misunderstands what a bank is. Banks also do not have an operating margin in the normal sense.

So the bank scorecard swaps in the measures lenders are actually judged on: price to book value instead of price to cash flow, because banks are valued on the assets on their balance sheet; return on equity instead of return on invested capital; book value per share growth, the cleanest sign a bank is compounding; and capital adequacy, which asks whether the bank holds enough equity to absorb losses without collapsing. That last one is the metric regulators themselves watch most closely, for good reason.

The principle underneath all of it

The lesson we kept relearning is that a quality score is only as good as its willingness to admit that "quality" means different things in different sectors. A single one-size scorecard is easy to build and quietly produces nonsense the moment it meets a bank or a REIT. The harder, more honest version recognizes that the right question for a software company is not the right question for a landlord or a lender.

If you want to see it in action, you can view a live quality score with the full per-metric breakdown for any of 8,000 plus US stocks, read the full methodology including the exact thresholds we use, or see how we turn SEC filings into the underlying data.

I would genuinely love to hear which metrics you would weight differently. The thresholds are the part we still debate the most.

How We Turn SEC Filings Into Free Stock Analysis

Philip — Wed, 03 Jun 2026 18:43:32 +0000

Every number on Intrinsiqq comes from one place: companies' own filings with the U.S. Securities and Exchange Commission. That sounds simple, but turning raw SEC XBRL data into clean quality scores, DCF valuations, and 10 years of financials for 8,000+ stocks is genuinely messy work. Here is how the pipeline works, and the parts that are harder than they look.

Why SEC EDGAR

Most finance sites buy aggregated data from third-party vendors. SEC EDGAR is the primary source underneath much of that data: it is free, public, and legally usable, and it contains exactly what companies reported to regulators, not consensus estimates or vendor adjustments. Building directly on it means the numbers you see match the 10-K and 10-Q, and it is why the analysis can stay free.

The pipeline, end to end

Pull the filings. We read each company's structured financial data from the EDGAR XBRL CompanyFacts API, focused on the us-gaap taxonomy.
Map the concepts. Each metric (revenue, free cash flow, debt, shares) is resolved through a chain of candidate XBRL tags, because companies do not all tag the same concept the same way.
Assemble trailing-twelve-month figures. Quarterly filings are stitched into a rolling 12-month window so the numbers are current, not a year stale.
Compute the analysis. From clean financials we derive the quality score, the DCF valuation, dividend safety, and the ratios.

Why XBRL is messier than it looks

The reason "just read the SEC data" is harder than it sounds:

Challenge	Why it is hard	How we handle it
Tag switching	The same concept gets a different XBRL tag over time	A prioritized fallback chain of tags per metric
Deriving Q4	Q4 only appears inside the annual 10-K, not as a quarter	Subtract Q1 + Q2 + Q3 from the annual total
Year-to-date cash flow	10-Q cash flow is cumulative YTD, not the quarter	YTD math so quarters are not double-counted
Duration vs instant	Flows vs point-in-time balance-sheet values	Sum flows over 4 quarters; take the latest for balances
EPS	Summing quarterly EPS mixes different share counts	TTM net income divided by the latest share count
Foreign + fiscal years	20-F filers, non-USD currencies, non-calendar years	Currency fallbacks and filing-type handling

None of this is glamorous. But it is the difference between numbers that match the filings and numbers that quietly drift from them. We chose to do the unglamorous part so the output is trustworthy.

From clean data to a verdict

Once the financials are clean, the analysis is deterministic and fully documented. The quality score is a weighted composite of eight fundamental checks; the DCF is a two-stage discounted cash flow you can adjust yourself; the dividend score weighs safety and growth. The same clean, TTM-assembled data also drives a fundamental charting tool, so any metric (or its historical valuation multiple) can be plotted over a decade and broken down by business segment. Every figure traces back to a specific filing, and the full methodology is public.

See the output on a real stock: analyze AAPL free →
Quality score, DCF fair value, and 10 years of SEC-sourced financials. Free, no account.

Why build it this way

Building on the primary source is more work than licensing a feed, but it is what lets Intrinsiqq be free, transparent, and auditable. You can check any number against the original filing, and we can show our work on the methodology page. For a tool meant to help people make real decisions, that traceability is the whole point.

Sources

Originally published at intrinsiqq.com.