Building Tractionora: When the Evidence Was Not Enough

A product about evidence has a particular problem during development: incomplete evidence is everywhere.

Some connections are working. Others still need authorisation. Some scans finish with useful results. A more ambitious run can hit a time limit. An analytics source can respond successfully but return no rows. The software still has to decide what to show the person using it.

A reassuring answer is not always a truthful one.

I have been working through this problem while directing Tractionora, a growth product intended to help business owners decide what to change on their websites and what work actually followed. Much of the difficult engineering has been about distinguishing one state from another.

Completed is not the same as useful

A scanner can finish every requested page and still miss something that changes the interpretation. It might not render a script-dependent page. It might fail to obtain one third-party performance result. The data it returns can be correct within its limits and still be insufficient for a recommendation.

For this reason, the development work has treated scanning as a bounded operation. The system should know what it attempted, what it obtained, what failed and what the evidence permits it to conclude.

I would rather display a clear “unavailable” state than invent a zero. Zero is a number. Missing is a condition. Mixing them changes what a business owner believes happened.

The problem with repeating a recommendation

Suppose the same keyword appears in several different findings. One observation may come from search performance, another from the page title, and another from a broader content review.

A naïve interface can turn those into three apparently separate opportunities. The owner receives three cards and may think three actions are needed. Sometimes there really are separate interventions. Often the records need to be reconciled first, with the provenance of each observation kept intact.

That work is not glamorous. It involves identity rules, evidence keys, lifecycle states and decisions about when two records are actually the same. Without it, a busy screen can give the illusion of progress while increasing the owner’s workload.

Approval has to mean something

There is another step I do not want the product to skip. Finding a useful change does not give a system permission to make it.

A proposal should be reviewable in terms a non-specialist can understand: what will change, what will stay the same, the reason for the suggestion and the risk. Publishing or changing a live website is a separate action and needs its own authorisation boundary.

Then verification must be independent of the claim that an action ran. A system should not mark a change as live because a job finished. It should check the resulting website or destination and record what it actually found.

The public Tractionora site describes this intended Find → Approve → Do → Prove journey and labels its detailed examples as illustrative. That is an important distinction while the application continues through staged development and validation.

Why I have resisted a bigger dashboard

Whenever a product faces a difficult design problem, adding a dashboard can feel like progress. Show every check, every confidence level, every chart and every integration, and the screen begins to look sophisticated.

But it pushes the original problem back onto the owner: interpret all this information and tell us what to do.

I want Tractionora to keep the underlying detail available while putting a small number of understandable choices in front of the user. A business owner should be able to start with an answer, inspect the evidence if they choose, and understand what their approval would actually permit.

That takes discipline in the product language as much as in the architecture.

The next standard to earn

There are several steps between a controlled pilot and a commercially dependable growth service. The product needs to demonstrate not only that it can collect evidence and prepare work, but that approved changes are applied correctly where enabled, independently verified, and followed by honest measurement over time.

Those steps cannot be compressed into a successful demo.

The lesson I am carrying forward is straightforward: a trustworthy system needs to say what it knows, what it has done and what it cannot yet prove. If it cannot make those distinctions for itself, it has no business making confident recommendations to an owner.