Why I'm Building Another Tax Program

We didn’t start a software company and go looking for a tax problem. We run a tax firm. We built the software we wanted to use.

That distinction explains more about PrepReturns than a feature list can. The project grew out of Trio Tax, and the starting point was the work: source documents, books, payroll support, shareholder information, tax decisions, review, and the return that has to emerge at the end. I wanted those pieces to belong to one coherent preparation process.

Professional tax software already does extraordinary things. Building even a bounded preparation engine has made me more appreciative of that. A mature platform carries years of tax-law changes, uncommon filing situations, user expectations, and compatibility obligations. It is easy to look at an awkward screen and miss the complicated history behind it.

But understanding the history does not mean accepting every consequence. A preparer can respect what existing software accomplishes and still ask why routine work has to feel so fragmented. That is the question I wanted to explore by building.

The friction lives between the steps

A return does not begin when someone opens an input screen. It begins with evidence that arrived in different forms, at different times, with different levels of reliability. Some of it agrees. Some of it needs explanation. Some of it will be replaced.

Consider an ordinary preparation problem: a financial statement contains an expense total, supporting detail suggests a different classification, and the preparer needs to record a tax treatment that does not simply mirror the books. There are several distinct things to preserve: what the original statement said, what the supporting records showed, what the preparer established, and how the return used that conclusion.

If those things are scattered across an attachment folder, a spreadsheet, a note, and an input field, the work may still get done. But the explanation depends on reconstructing the path. The next reviewer has to find the right files and remember which number was superseded. The software knows the final input without necessarily knowing its story.

I wanted a preparation system that keeps that story closer to the number. The source is evidence. An extracted value is a proposal. Review establishes the fact. A calculation uses the established fact. The resulting workpaper and form should make that progression intelligible.

This sounds like a modest organizational preference. It becomes an architectural decision as soon as a source changes after a return has been prepared. Which facts need review again? Which calculations are stale? Does the old PDF still mean what it meant when it was created? The apparently small workflow question reaches all the way through the system.

I want to review information once

Typing is not the central professional contribution to a return. Judgment is. Re-entering information can be necessary, but it should not become the default simply because the software has separated documents from preparation.

If a supported source has already supplied a proposed fact, I want to review it in context. If it is correct, confirmation should be straightforward. If it is wrong, correction should be possible without pretending that the source was different. If the information is missing, the system should ask for it plainly.

That is the idea behind PrepReturns’ source review and Guided Preparation. It is not a claim that software can understand every document a client might send. The current intake has supported formats and boundaries. Broader ingestion is a direction to develop, not a reason to obscure what works today.

The more important ambition is continuity. Information established during source review should remain available when the preparer reaches the next decision. Guided questions should concentrate attention on what the evidence cannot settle. Direct workpapers and forms should stay within reach, because a professional does not always want to follow an interview in the order a designer imagined.

There is room for guidance and direct access in the same product. A good assistant knows when a question is useful. A good workspace also lets you look around.

Frustration is useful only if it becomes a design question

There are plenty of reasons a tax professional might wish software worked differently: a bug that disrupts a familiar process, a support conversation that cannot reach the technical issue, an integration that is harder or more expensive than it should be, or a feature request whose eventual destination is invisible.

Software evaluation can be frustrating too. A polished sales demonstration shows a route through the product. It does not necessarily show what happens when the evaluator takes a different route, corrects earlier information, or asks a question that requires an engineer rather than a salesperson.

Those are motivations for this project. They are not evidence that every vendor handles every situation badly. Nor would a list of complaints make PrepReturns useful. The productive step is translating frustration into a requirement that can be implemented and challenged.

“I cannot tell why this changed” becomes a requirement for provenance and saved history. “I have to enter this again” becomes a question about shared facts and authority. “I cannot get the information out” becomes an interoperability problem. “The result looks right on screen, but the package does not” becomes an output-integrity requirement.

Once phrased that way, the problem stops being abstract. There is something to build and something to test. That is a much better use of impatience.

Why start with S corporations?

An S-corporation return is a useful proving ground for the kind of system I want. It connects financial statements, tax adjustments, assets, owners, basis, allocations, forms, and review. A credible workflow has to deal with those relationships rather than produce an isolated calculation.

It also offers a meaningful way to bound the first product. PrepReturns starts with conventional S-corporation patterns. That universe can include multiple shareholders, payroll, fixed assets, distributions, shareholder loans, inventory, ordinary rental activity, and other supported operating-business facts. “Conventional” does not mean that a return fits on a napkin.

The boundary matters because every new capability creates obligations elsewhere. Add an owner and output must remain owner-specific. Add an asset transaction and the consequences may reach calculations, supporting forms, workpapers, and next-year history. Add a correction and the system must know which earlier conclusions no longer apply.

I would rather make those connections explicit than present breadth as a collection of checkboxes. The current S-Corp Engine is the concrete expression of that choice. Its capabilities and limitations belong in the same conversation.

Form 1040 comes next. The reusable part is the preparation philosophy: evidence, explicit unknowns, reproducible calculations, history, and professional control. Households and individual tax law deserve their own model. They should not be squeezed into an S-corporation model merely because that is the code we built first.

AI changed what was possible to attempt

For a small tax practice, building a preparation system used to feel like a different category of undertaking from improving an internal spreadsheet. Frontier AI-assisted development changed that calculation enough to make a serious attempt possible.

It did not remove the work. PrepReturns developed through successive Alpha generations, each focused on a new problem. The progression moved from a deterministic core to source intake, a professional workspace, Guided Preparation, source authority, official forms, broader owner and asset support, and richer operating-business coverage.

Research, implementation, tests, fresh review, browser inspection, and PDF inspection all matter. Models can help with each of those activities. They can also misunderstand a requirement, repeat an assumption, or generate code that passes the wrong test. Giving different agents bounded roles is useful precisely because no single response should become the authority for the whole system.

One development lesson is especially revealing. The Alpha 14 work found official-form output whose mappings could be correct while visible text disappeared during PDF page handling. A successful calculation and a plausible mapping were insufficient. Someone still had to inspect the actual artifact the preparer would see.

That is why I separate AI-assisted development from the product’s tax calculations. AI helped build and challenge the software. The calculations themselves are deterministic software using established facts. The professional remains responsible for the preparation decisions. The development story explains that distinction through the actual work.

A finished return should be an explainable result

The outcome I want is not a dashboard full of encouraging indicators. It is a return package whose numbers, workpapers, diagnostics, and forms refer to the same preparation.

A preparer should be able to inspect a result and move backward through its explanation. What facts drove it? Where did they come from? Was anything corrected? Does this package predate the most recent edit? Which owner does this supporting information belong to?

Those questions become more valuable as automation increases. A faster path to an opaque answer is not enough. The point of saving time on mechanical work is to leave more room for judgment and review, with a better record of what happened.

In this project, “finished return” describes preparation and output. It does not announce e-filing, transmission, signatures, or IRS approval. Those are separate capabilities and responsibilities. Being clear about the distinction lets the product story stay focused on the work it actually does.

Building changes the conversation

The first question was whether a particular part of an S-corporation return could work better. As the pieces connected, the question became larger: what should the entire preparation path look like if it starts with the practice’s work?

That is also why PrepReturns belongs beside Trio Ledger, the sibling ledger product for very small businesses. These projects come from related practical concerns. That relationship is an origin story, not a claim that a live integration already exists.

PrepReturns remains private today, with open source as the intended direction. I want professional users to have more ways to inspect, adapt, and connect their tools. There are serious governance and maintenance questions behind that ambition, and building the software has made those questions more concrete.

I am interested in conversations with practitioners, engineers, researchers, and tax-software companies. There is no need to share every design choice to find the experiment useful. The most valuable response may be a sharper question, a difficult case, or a different view of how a workflow should behave.

I am building another tax program because the questions are worth answering in working software. The practice gives the project its problems. The product has to earn its answers. You can explore the workflow and compare notes with us.