The Straightforward 90%

“Straightforward” is a dangerous word around tax professionals. It can sound like a promise that a return will be easy before anyone has looked at the facts. It can also sound like a euphemism for tiny businesses with one owner, no assets, and nothing interesting to report.

Neither meaning is what I intend when I talk about the straightforward 90%.

The phrase describes a design ambition: build exceptionally well for a substantial universe of recognizable preparation patterns, and expand that universe deliberately. It is not a measured claim that PrepReturns currently supports exactly 90% of returns. There is no market-coverage study hiding behind the number.

The useful distinction is between conventional and exceptional structure. A business can be financially substantial and operationally busy while its tax preparation follows familiar relationships. The work still requires judgment. The software does not have to make every preparer navigate every possible exception before reaching those familiar relationships.

Revenue is a poor shortcut for complexity

Imagine a hypothetical service business with $2 million of annual revenue. It has several owners, employees, equipment, distributions, and shareholder financing. The preparation involves reconciling books, reviewing payroll, considering asset history, and producing owner-specific information.

That is meaningful professional work. It is also a recognizable operating-business pattern. The revenue figure tells us little about whether the company has a specialized international filing problem, an unusual ownership arrangement, or a transaction that sits outside a bounded system’s intended scope.

Now imagine a business with much lower revenue and an unusual structural event. Its return could be harder to fit into a narrowly designed product even if its financial statements are short. Size and structural complexity are different dimensions. A useful scope policy should not confuse them.

The same applies to document volume. A large stack of consistent, well-organized records can be easier to prepare from than a small stack containing contradictions and missing history. Preparation effort reflects the quality of evidence as well as the underlying tax situation.

That is why I prefer to describe the intended return universe through patterns and boundaries. Multiple shareholders is a pattern. Owner-level issues outside the corporate engine are a boundary. Supported asset history is a pattern. Missing facts needed to establish a treatment are a reason to stop and resolve the uncertainty. A revenue threshold would not answer those questions.

Breadth has a cost in the ordinary workflow

Established professional platforms support extraordinary breadth. There are good reasons for that. A firm with a diverse client base may need one system to accommodate many uncommon situations. Maintaining those capabilities is substantial work, and they can be indispensable when the unusual case arrives.

But breadth influences the product even when a particular return does not use it. Input structures, navigation, defaults, terminology, and dependencies grow around the situations a system must represent. An ordinary return can inherit some of that complexity through screens and choices that exist for very different returns.

The problem is not that an uncommon feature exists. It is how much of its complexity becomes an everyday cost for everyone else.

Suppose a preparer needs to resolve one supported expense classification. The interface should help establish that fact and show its consequences. If the preparer first has to decode a large taxonomy of unrelated treatments, the software has transferred its organizational burden to the user. Flexibility has value, but so does a clear next step.

Starting with a bounded universe creates room to design around the common preparation path. It lets the system ask more specific questions, define stronger relationships, and make more useful distinctions. It also creates an obligation to identify situations that do not fit. A clean interface is not an excuse to conceal a missing capability.

Conventional returns still contain hard problems

Nothing about this approach makes source authority, basis, or saved history trivial. Those problems occur in ordinary work. They should be foundational rather than deferred until the software becomes “advanced.”

For example, book equity and shareholder tax basis are different concepts. A workflow that compresses both into one convenient balance would be simpler to implement, but it would simplify the wrong thing. A bounded product still needs to preserve the distinctions that matter within its domain.

Likewise, a correction to a source-derived figure needs an explanation even on a one-owner return. An unknown opening fact should remain unknown until resolved. A saved preparation should not quietly change because current inputs have changed. None of those requirements depends on supporting an exotic transaction.

This is where the phrase “straightforward” can be most useful. It challenges us to make familiar work coherent without removing its professional substance. The target is less unnecessary navigation, repeated entry, and reconstruction. The tax judgment stays.

PrepReturns’ synthetic examples illustrate the distinction. Juniper shows the core source-to-return path. Alder adds multiple owners and shareholder-basis work. Cedarline adds inventory, commercial rental activity, investments, a company vehicle, amortization, loan interest, and reimbursements within supported boundaries. These are fictional examples built to exercise software behavior, not claims about client-return volume.

Cedarline is richer than a minimal demonstration, yet it remains a recognizable operating business. That is the territory the product is exploring.

Scope is a contract with the preparer

A scope statement should do more than protect the software’s description. It should help a professional decide whether the system is appropriate for a return and recognize when the facts have moved beyond it.

There are at least three different situations to distinguish. First, the software supports the situation and has the facts it needs. Second, the situation may be supported, but relevant facts or decisions remain unresolved. Third, the situation itself is outside the intended capability.

Treating all three as a generic warning produces poor guidance. The first situation calls for preparation and review. The second calls for specific information or professional judgment. The third calls for a different path. A preparer should not have to infer the difference from whether a button happens to be enabled.

This also changes how we talk about feature support. “Inventory” is not a complete description of an implementation. There are supported inventory patterns and more complex methods or production situations outside the current target. “Vehicles” does not automatically mean every lease, fleet, fringe-benefit, or historical scenario is represented.

The capabilities page provides the positive description. The limitations page provides the corresponding boundaries. Those pages are product information, not an invitation to force a return into the closest available category.

The software should know when to say no. Just as usefully, it should know when the answer is “we need one more established fact.”

Expand by connected capability, not by checkbox

A new feature is not finished when a field appears on a screen. It has to participate in the preparation system.

Take a general example: adding a new category of business activity. The system may need new source facts, review questions, calculation rules, workpapers, official output, owner information, saved-state behavior, and carryforward rules. It also needs to know what happens when the activity is removed or corrected after a package is prepared.

If only the input and calculation are implemented, the feature can look complete in a demonstration while leaving important work outside the software. A preparer may then have to bridge the gaps with manual schedules and remembered conventions. Those bridges can be appropriate when deliberate. They should not be surprises.

The Alpha history made these connections tangible. Official-form rendering introduced a different kind of verification from pure calculation testing. Multiple-owner support introduced output-separation concerns. Richer operating businesses created more dependencies and larger saved histories. Each expansion asked the product to remain coherent under more conditions.

That is why I think qualification belongs beside expansion. The question is not only whether a new example produces the expected number. It is whether the capability fits the evidence model, preserves old behavior, appears correctly in output, and remains understandable to the professional using it.

A bounded system can grow ambitiously. It just has to grow in complete pieces.

The boundary should be visible before commitment

A practitioner evaluating software should not have to buy it to discover its conceptual limits. The intended return universe belongs in public product information, along with enough evidence to make the description meaningful.

That does not require an exhaustive list of every possible tax circumstance on a homepage. It does require clear language about the supported patterns, deeper information for serious evaluation, and examples that show more than the easiest path. A demonstration of a single-owner case cannot establish every claim about multiple-owner behavior.

The same honesty matters when a project is still developing. Alpha 14 is PrepReturns’ generation for human testing and broader operating-business coverage. The phrase describes the work and direction without converting engineering evidence into an unsupported claim that every professional acceptance question has been settled.

This is a useful standard for my own product choices. If a limitation feels uncomfortable to explain, hiding it is unlikely to improve the implementation. Explaining it clearly may reveal a better boundary or identify the next capability worth building.

A design ambition is allowed to be ambitious

There is a temptation to hear “bounded” as “permanently small.” I mean almost the opposite. A coherent foundation makes it possible to expand without losing the preparation philosophy that made the project worth building.

Form 1040 is next, but individual returns will require their own domain model. Household relationships, dependents, wages, investments, deductions, credits, and owner-level consequences are not simply more fields on a corporate object. Reusing principles should not mean forcing unlike domains into the same shape.

The same discipline should govern later integrations and possible open-source contributions. A capability belongs when its facts, authority, calculations, output, and review responsibilities are understood. The number of available screens is a poor substitute for that understanding.

The straightforward 90% is therefore a question we keep asking: how much conventional professional work can become clearer when software is designed around it deliberately? The answer has to come from working cases, visible output, and practitioner review, not from the slogan itself.

I want ordinary returns to receive extraordinary care in the product design. That means respecting their real complexity while removing complexity the preparer should never have had to carry. The product view of the straightforward 90% shows how that ambition shapes PrepReturns today.