Built to Learn: The Dual-Perspective Accounting Simulator
I built a tool before I knew enough to know if I built it right!
That's not quite as reckless as it sounds (unless we're talking real business applications) — but it's close enough that I think it's worth being honest about, because the experience of building it taught me something that no amount of watching lecture videos would have.
Why I built it instead of just studying
My pre-program self-study method has started off (allegedly) as: build something, then learn from the act of building it. I arrived at this not through any pedagogical theory but through twenty years of working in technology, where the fastest way I ever learned something new was to have a reason to care whether it worked.
Watching Farhat Lectures and Edspira on YouTube (which I'd recommend to anyone trying to build accounting intuition before formal coursework) got me comfortable with the surface layer. Debits and credits started making sense. The matching principle clicked (I think). The three financial statements stopped feeling like three separate documents and started feeling like three views of the same underlying reality.
But I knew from experience that "comfortable with the surface layer" and "actually understand it" are two different things. So I built something.
What it actually is
The Dual-Perspective Simulator is a Streamlit app built in Python. It generates randomized accounting scenarios — inventory purchases, accrued wages, prepaid insurance, credit sales, deferred revenue, and more — and shows the same transaction through two lenses simultaneously.
The first lens I call the Auditor's View: financial accounting as external reporting. Journal entries. Net income timing. The GAAP treatment. What you'd be defending to an auditor or explaining to an investor, essentially.
The second lens I call the CFO's View: managerial accounting as internal decision support. Cash flow timing instead of accrual smoothing. Contribution margin. Whether a cost is sunk or relevant to the next decision. In short: what a CFO actually thinks about when they see the same transaction.
The reason I wanted both views side by side — for every scenario — is that I'm interested in eventually getting into forensic and fraud accounting. Which means I need to learn to see transactions the way multiple different people with different stakes would see them. "This is how it looks externally" isn't enough. I need to understand what the external view is trying to show, and what someone on the inside might have been thinking. Seeing both at once, for every scenario, builds that muscle.
I treated it like a complicated flash card program: guess-before-reveal flow is intentional. You see the scenario, commit to an answer, (e.g. what's today's net income direction? which managerial lens applies here?) and then you see whether you were right. It's for learning, so you should at least have to attempt before you get the answer, right?
Right.
How I actually built it
I want to be straightforward about this: I orchestrated the build using AI rather than writing every line of Python myself. What that looked like in practice was describing what I needed at a high level first — the goals, the outcomes, the architecture — then reviewing output, catching edge cases, and iterating toward something that functioned the way I wanted it to.
Most of the edge cases I was catching weren't bugs in the traditional sense. They were pedagogical decisions.
Do I cover only beginner concepts, or include intermediate ones from the start? Intermediate — I'm already there, sort of. Do I show all metrics for every scenario, or just the one the scenario is designed to teach? Just the relevant one — no distractions. Do I reveal the answer immediately, or make the learner commit first? Commit first. This is for learning.
The architecture that came out of that process is deliberately clean: engine.py is almost purely a scenario container, and app.py is the shell that renders it. That separation was intentional. The engine holds the accounting logic and scenario definitions; the app handles presentation. Which means I can keep adding scenarios to the engine as I encounter concepts I need to drill, without touching the interface.
That's the container I wanted.
What it's not, yet
Ten scenarios is enough to build the tool on, but it's not enough to actually drill concepts into your head at the depth an MBA program requires. That work is ahead of me.
What I don't know yet is which concepts will need the most reinforcement. I haven't sat down with it in actual study mode, under actual course pressure, and discovered where my understanding breaks down. That's the next phase: use it, find the gaps, build scenarios for the gaps. The tool is ahead of my knowledge right now, which is an odd inversion, but probably the right one. Better to have the container ready than to need it and not have it at all!
There's also a longer arc here that I'll leave vague for now: I'm building more than one learning tool, and I'd like them to eventually feel like they belong together. Same visual language, same interaction patterns, same underlying philosophy. Whether that becomes something shareable someday is a question I don't have any answer for.
The thing I'd tell someone before they start
If you're considering building a learning tool instead of just using existing ones — Anki, Khan Academy, whatever — here's the honest case for it:
Building takes you from passive observer to active participant. There's a reason handwriting notes works better than typing them, and a reason typing them works better than just reading. Every step closer to active engagement is a step closer to actual understanding.
But building goes further than either of those. When you build a tool to teach yourself something, you have to reckon with what you don't understand — because the tool won't work if you don't. You can't fake your way through an architecture decision by highlighting the right sentence. You have to know enough to describe what you want, evaluate what you get, and recognize when something is wrong.
I didn't fully understand accrual accounting before I built scenarios for it. But I understood it better after. Not because building taught me the rules — the lectures did that. Because building forced me to care whether I was implementing the rules right.
"Building forces you to reckon with your weak points in a way passive study doesn't. Even if you don't fully understand it yet — build it anyway! You'll be closer to true understanding than you were before you started."
That's the argument. It's not for everyone, but if you grew up putting building blocks together without instruction manuals like I did, it might be worth trying.
The simulator is built with Python and Streamlit. The source is available on request — it's not polished enough to publish yet, but if you're curious about the architecture or want to talk through the approach, get in touch.