Phineas Fritsch

Questions

These are the questions people ask, phrased the way they ask them.

  1. What are you studying?

    Financial actuarial mathematics at UCLA, graduating June 2027. I am enrolled in 178A, Foundations of Actuarial Mathematics, and 179, Advanced Topic in Financial Mathematics, for the quarter starting 24 September, and I sit Exam FM this fall. Most of what is on the rest of this page happened outside class.

  2. Have you passed any actuarial exams?

    No. None. FM is in fall 2026, and until I pass it that is a plan and not a qualification. The coursework behind it is real: 177, Theory of Interest and Applications, which is the FM syllabus almost line for line, and 174E, Mathematics of Finance, both behind me; 178A and 179 start this fall.

  3. What do you want to do?

    Product, actuarial work, or revenue cycle management, which is the finance side of healthcare. What the three have in common is the part I like, which is working out what a number should be and then being the one who answers for it when somebody checks.

  4. What have you built?

    Six things that are running. Course ranking and seat alerts for UCLA students, a call-number-to-shelf finder for the library I work in, a phone version of my unit's staff schedule, a blackjack practice app, a group film picker for my own media server, and a replacement site for my fraternity chapter. That last one runs but the chapter domain still points at the old WordPress.

  5. How much of this did you write?

    Most of the code was written by an AI, and I would say the same in a room. What is mine is the deciding: what to build, what it has to refuse to do, and the design calls I can defend. Why Postgres runs sixty connections and not thirty. Why call numbers sort as decimals. Why a blackjack app is not allowed to mention money, including on its own paywall.

  6. You have no healthcare experience. Why revenue cycle?

    Because the part of it I have seen up close is the part I am already good at. Most of the work is getting messy institutional data into a state you can defend, and knowing that a number being wrong is usually a process being wrong. The closest I have been is five months of front-office work at my family's dental practice in 2023, on Dentrix, which is practice management and billing software: patient data entry and financial record accuracy, not claims and not coding. I have not worked a claim, I have not touched a hospital EHR, and I would be starting close to zero on the domain. The transferable half is real and the healthcare half is barely there.

  7. Does anyone use any of this besides you?

    Some of it. My unit's daily schedule used to arrive as an Excel file every morning, so I put it on a phone screen, and people at my desk open mine now instead of the file. Nobody assigned it and nobody had to be talked into it.

  8. Why did you build them?

    To be lazy. Nobody assigned any of this. The schedule came as a daily spreadsheet and I wanted to stop opening it. The library retired LibMaps and I got tired of hunting for a shelf. The habit predates the code by a few years: I have run a media server since freshman year, badly in a dorm at first, and none of that part was AI-assisted.

  9. What is the hardest decision you have made in one of these?

    Sizing Dibs. It runs on one small server and the obvious number for Postgres is thirty connections. Thirty breaks, and it breaks only while you are deploying: Rails multi-database means one thread can hold four at once, and a deploy runs the old and new containers together, so you cross the limit at the moment you ship and the site goes down rather than the jobs. It is set to sixty, and the reasoning is in the config.

  10. Why should an actuarial employer care that you write software?

    Because most of the work is getting messy data into a state you can defend. Dibs is built on UCLA grade records released under the California Public Records Act — requests organized and paid for by uclagrades.com and forty-odd students, not by me, which Dibs says on its own About page. What I did was take the four responses, 176,290 rows in inconsistent shapes, and get them into a state you could defend. There was an instructor fan-out in them that would have overstated the grade count by about eighty thousand. Finding that was most of the job; the app was the easy part.

  11. Why should a product team care that you are an actuarial major?

    Because I can say how confident I am in a number and where it stops holding, and a lot of a roadmap is that. The other half is that what I do all day already resembles the job. I decide what gets built, split it across several agents at once, review what comes back, and reject the parts that are wrong.

  12. What have you built that did not work?

    A React portfolio in 2025 that is forty-one lines long, has stock clipart in it, and sits in a repository whose name I misspelled. An empty repository called prdfg. A first version of this site that was a 3D planet weighing 903KB, and once it finally painted it said thirty-seven characters. They are all still up.

  13. How do you know when the AI is wrong?

    I assume it is, and I build the thing that can contradict it before I build volume. Agents report success on broken work confidently and in detail, which is the normal case and not the exception. So this site runs a gate before it deploys, pins the sentences that matter so a later rewrite cannot quietly delete them, and reads production back afterwards to check what is live. The status figures on the front page are measurements.

  14. How do I get in touch?

    contact@phineasfritsch.com. If you want to check something on this page before you write, the source for the site is on the working branch — the gate, the pinned sentences and the tests are there rather than on main, which is still the framework scaffold.