THE REASON TO BUILD
Why another tax program?
Professional tax software is mission-critical infrastructure. Practitioners should be able to understand it, evaluate it, connect it, and help make it better.
On this page
The work came first
PrepReturns grew out of Trio Tax, a working tax practice. We didn’t start a software company and go looking for a tax problem. We encountered the problems while doing the work: gathering evidence, resolving inconsistent information, making tax decisions, reviewing calculations, and assembling a return.
That experience supplied a practical question. What would professional preparation look like if the software treated the whole path as one connected process?
A source should lead to a proposed fact, a review decision, a calculation, a workpaper, and a form. If something changes, the software should help explain the change. If information is missing, it should remain visibly missing. The professional should be able to follow the work without reconstructing it from scattered notes and input screens.
Capability should not require constant complexity
Established tax platforms support extraordinary breadth. Their accumulated knowledge and uncommon capabilities are valuable. That breadth also creates design constraints: navigation, input structures, dependencies, and terminology shaped by decades of different situations.
PrepReturns begins with a deliberate alternative. Concentrate on conventional S-corporation preparation, make the supported workflow coherent, and expand in complete, qualified pieces. Multiple owners, payroll, assets, basis, inventory, and ordinary rental activity can be substantial work while still following recognizable patterns.
The straightforward 90% describes this design ambition. It is not a measured coverage statistic. The product should make its capabilities and boundaries understandable before a professional depends on them.
Quality includes the workflow and the output
A tax professional should not have to discover a preventable regression in the middle of ordinary work. Bugs and unclear quality-control behavior are part of the motivation for building PrepReturns, and they create obligations for this project too.
Testing must reach beyond a correct isolated calculation. Source corrections, saved history, owner-specific information, stale results, diagnostics, and printed forms all affect whether a preparation can be reviewed confidently.
The development work has made those obligations concrete. Direct inspection of Alpha 14 PDFs found a rendering problem despite correct mapping data. Richer examples revealed dependencies that simpler cases did not exercise. Each correction added to the understanding of what needed protection as the product grew.
The development story shows that process. AI-assisted implementation accelerates the work, while tests, fresh review, visible output inspection, and human professional judgment establish whether it is useful.
Technical questions deserve technical answers
Support becomes frustrating when a specific technical problem cannot reach someone who understands the system. A preparer may need to know why a result changed, which saved package is current, or what an export actually contains. A generic response does not resolve those questions.
Software evaluation has a related problem. A controlled demonstration can introduce a product, but it cannot replace preparing and correcting a representative return yourself. A sales demo isn’t a test drive.
PrepReturns should be understandable through real product evidence, explicit scope, architecture explanations, and meaningful technical conversation. This website supplies those public materials. A synthetic hosted showroom remains future work; the site does not offer an invented demo or imply that screenshots replace hands-on evaluation.
A feature request should begin a conversation
Practitioners know where their tools stop helping. A repeated workaround may reveal missing provenance, an awkward review handoff, or information that needs to move between systems. That knowledge deserves more than a form submission with an invisible destination.
No product can implement every request. Scope and engineering dependencies matter. But a clear explanation, a useful integration boundary, or a way to contribute can give the user a path forward even when a feature is not on the main roadmap.
PrepReturns is private today, with open source as the intended direction. The longer-term ambition is software that firms can inspect, adapt, integrate, and improve under a future release and license. Those possibilities are not rights already granted, but they help explain the product choices being made now.
Interoperability belongs in the foundation
Professional information moves among books, documents, workpapers, tax systems, and people. Limited or expensive APIs can make ordinary connections harder than they need to be. Integration should be considered part of useful software design.
Moving numbers alone is not enough. A connection should preserve meaning: period, owner, source, review status, and the difference between a current fact and a historical result. PrepReturns’ separation of evidence, established facts, calculations, and saved output provides a basis for that work. Broader external integrations and documented APIs remain a direction to develop.
We are interested in conversations with practitioners, engineers, researchers, and tax-software companies who see related problems. PrepReturns is an experiment in what happens when a tax practice stops waiting and starts building. Explore the working S-Corp Engine or compare notes with us.
A conversation worth having.
Product, practice, architecture, or a different idea about what comes next.