Proof of Work

Turning unclear problems into working products — then making the capability repeatable.

I work where business, product, and technology overlap, often before the problem is completely defined.

The first question isn’t necessarily how do we build it? It may be what should we build, what have we actually proven, what does the customer need, what can the technology and data support, what should we preserve, and what deserves the next investment.

I work through those decisions and can go deep enough into architecture, software, data, and AI to prove and build the solution myself.

The examples below show that pattern in practice.

How I work

Patterns first. Projects as evidence.

Different industries and technologies keep producing the same kind of work: establish reality, reduce uncertainty, make the tradeoffs, build enough to learn, and turn what works into something other people can own.

Recurring pattern

Start by establishing reality

Before prescribing a solution, understand what actually exists.

Proof

Product recovery

An existing image-identification product had been through several development attempts. Usage was declining, identification was not sufficiently useful, and headline account numbers did not describe the product’s actual current usage.

I evaluated the product as a whole: usage, subscriptions, existing architecture, previous identification approaches, backend and reference data, and the available machine-learning training data.

The conclusion was not simply that the application needed another implementation. The identification strategy itself needed to change.

That investigation led to a new product and technical approach rather than another layer on the existing solution.

PrincipleDiagnose the product before treating the implementation.

Recurring pattern

Use building to reduce uncertainty

I build quickly when building is the fastest way to learn.

Proof

On-device image classification

The available training data was limited and inconsistent, while the product needed substantially better image identification. Rather than debating what the data might support, I trained and iterated an initial machine-learning model in roughly one day.

That experiment established both what was possible and where a conventional single-model approach would fail. I evolved it into a multi-stage classification pipeline that progressively evaluates useful image characteristics and combines those results with contextual information and an existing reference catalog.

The models run on the device because users may be in the field without network connectivity. Instead of attempting a nearly 2,000-class model without adequate examples, the architecture uses ML to narrow the problem and the existing catalog to resolve and rank specific candidates.

I also designed a feedback mechanism for incorrect results while keeping unverified user feedback separate from trusted training data.

Image → Point? → Characteristics → Context → Catalog Resolver → Ranked Candidates

PrincipleAI architecture should follow the product, users, data, and operating environment—not the other way around.

Recurring pattern

Match the solution to the evidence

The goal is not to maximize development. It is to solve the right problem.

Proof

Expand, don’t rebuild

A customer wanted to extend an existing operational business system to mobile devices and eventually had a much larger commercial-product vision.

I reviewed the architecture, database, authentication, APIs, integrations, deployment, and existing workflows. The conclusion was straightforward: the existing system worked. It did not need to be rebuilt.

I separated the longer-term productization vision from the immediate operational need, defined the appropriate mobile workflows, and created working tablet prototypes so the customer could evaluate actual interactions before production development.

The architecture preserved the customer’s existing backend and developer. New interfaces could be added collaboratively rather than transferring ownership of the entire system to another development team.

PrincipleModernization doesn’t automatically mean replacement. Preserve what’s working and invest where new capability actually creates value.

Recurring pattern

Define the product before committing to the build

Separate the immediate business problem from the eventual vision.

Proof

From broad vision to achievable first product

A customer came in with a large construction-technology vision involving field operations, scheduling intelligence, analytics, AI, multiple platforms, and integration with an established enterprise scheduling system.

The immediate business problem was much narrower: get accurate field progress and delay information back to project schedulers quickly and consistently.

I separated that problem from the eventual platform vision and defined a focused first product around the workflow that needed validation. When available investment changed, I reduced the product rather than pretending the original scope could simply be delivered for less.

Advanced analytics, predictive AI, additional platforms, and broader enterprise capabilities could wait. I also identified the enterprise scheduling integration as the major technical uncertainty, investigated the vendor’s supported integration mechanisms, and moved technical validation forward rather than making an unsupported implementation commitment.

In 2026 I have worked directly across 10+ customer engagements, helping move product definition, feasibility, dependencies, operating considerations, risks, customer responsibilities, and delivery expectations ahead of implementation.

PrincipleWhen constraints change, change the product—not engineering reality.

Recurring pattern

Build products customers can own

A successful product should not require its original developer for every operational decision.

Proof

From legacy application to operable product

An existing consumer application needed major modernization, but its legacy behavior, backend relationships, data, and external dependencies were not completely understood. I reconstructed what the existing application actually did and used that evidence to define the replacement.

Reproducing the screens was not enough. Content that had been embedded in the application was moved into a manageable backend, and I created a web administration system so the customer could manage product content without directly editing the database or depending on a developer.

When the existing international data model proved problematic, I redesigned it and built a controlled migration process with backups, dry runs, verification, reporting, and rollback.

The final migration produced 662 records with zero structural verification problems.

PrincipleAutomation doesn’t mean automating decisions the evidence doesn’t support.

Recurring pattern

Prove it, then make yourself less necessary

The goal is repeatable capability, not permanent dependence on the person who proved it.

Proof

Document analysis and scoring product

A document analysis and scoring problem provided an opportunity to test whether AI could improve analysis while preserving structured evidence and human judgment.

I built the initial working approach in approximately one day, using rapid experimentation to determine whether the concept was useful. Once it was proven, I did not keep ownership of everything.

The approach was structured and transferred to the engineering team for production deployment, nightly processing, search, continued development, and operation using locally hosted LLM infrastructure.

That same pattern appears elsewhere in my work: create a workflow, prove it across several projects, document and refine it, and then transfer it to the people who should own it.

PrincipleUnderstand → prove → structure → transfer → scale.

Recurring pattern

Use the real world as part of product development

A product is not validated because it works on my desk.

Proof

Building and field-testing my own products

Through My OWL Tech, I continue to work hands-on across product definition, architecture, software, data, deployment, and field validation.

My OWL Plan and My OWL Fishing are released for iOS and Android. My OWL RoadTrip is undergoing real-world testing ahead of release. The supporting environmental platform manages approximately 1.6 billion National Weather Service data elements and supports location-specific decision making.

I use the products in the situations for which they were designed. Real trips have exposed assumptions that looked reasonable during development but did not match what actually happened—route changes, skipped stops, timing changes, weather access, user interaction, and the difference between a planned trip and the trip that actually occurred.

Those observations become product changes.

PrincipleA product isn’t validated because it works on my desk. Real use changes products.

Recurring pattern

Turn solutions into repeatable capability

When something works once, ask what should become reusable.

Proof

From one solution to shared capability

That has included creating a Figma-to-starting-code workflow, using it across three projects, and transferring it to an engineering team; creating reusable enterprise mobile components for authentication, authorization, data integration, dashboards, and server-configured interfaces; building shared capabilities across my own product family rather than duplicating them application by application; and building teams and processes that allow initial prototypes to move beyond their original creator.

Earlier in my career, I built an aviation decision-support product family that combined weather ingestion, interpretation, GIS, backend services, and native mobile applications. It reached 34,000+ downloads, and its services operated for years with very few reported issues.

PrincipleThe tools have changed. The pattern hasn’t.

Recurring pattern

Work above the individual project when that is where the problem lives

Product and technology leadership is also about the operating model around the work.

Proof

Defining a technology operating model

In my current professional work, I have also worked above the individual-project level: helping define how a technology organization should assess opportunities, define products, qualify work, build and modernize systems, operate products after launch, develop recurring services, evaluate delivery economics, and create reusable capabilities.

The model connects Market → Qualification → Advisory → Definition → Delivery → Operations → Economics → Business Development.

Technical feasibility, business value, risk, economics, customer readiness, and organizational capability all matter. An assessment that concludes ‘don’t build this yet’ can be a successful outcome.

PrincipleWinning the work doesn’t automatically mean the work should be done.

The common thread

Different industries. Different technologies. Different stages of my career.

The recurring work has been remarkably consistent.

Understand the actual problem.Establish what the evidence really says.Challenge assumptions when necessary.Make the business, product, and technical tradeoffs.Build enough to reduce uncertainty.Ship something that works in the real world.Learn from what happens.Then make the capability repeatable.

I don’t need the problem to arrive already categorized as a business problem, product problem, AI problem, architecture problem, or software problem. Figuring out which of those actually matters is part of the work.

See the work behind the advice.

Whether the next step is a role, an assessment, a product decision, or a build, the starting point is the same: understand what actually matters.

Start a conversation Professional services