Curiosity became a working habit: look closely, map the terrain, and keep going when the first answer feels too easy.
About Sean Findley
I like hard problems, useful software, and explanations that make sense.
I’m Sean—a software engineer, product-minded builder, and single dad in Reno. I have spent more than a decade turning messy operational problems into software people can actually use. Lately I have been focused on a question I cannot leave alone: how do we make AI genuinely useful without letting it become reckless?
That question became OverLift. The rest of this page is the more human story behind the work: curiosity, persistence, fatherhood, a second-act education, and a habit of building until an idea can be seen and tested.
10+ years building real software
Creator of OverLift
Applied AI · .NET · Azure
Single dad and lifelong explorer
Right now
Turning OverLift from an architecture into a connected family of products you can open, question, and inspect.
Early signal
I was exploring long before I was engineering.
As a kid, I was usually the one asking everyone to walk a little farther. Around age ten, I organized small expeditions into the hills that turned into miles of hiking, fossil beds, hidden structures, and abandoned tunnels. I was not trying to be impressive. I simply wanted to know what was around the next ridge and how all the pieces connected.
That instinct never really left. Software became a different kind of landscape: systems instead of hills, hidden dependencies instead of tunnels, and the same satisfaction when a confusing map finally becomes clear.
Those childhood expeditions were early practice in calm direction, shared risk, and making the journey feel possible for everyone.
Winning Sportsmanship of the Year in Boys & Girls Club softball still matters to me. The best teams are built on trust, not theater.
How I think
I notice patterns, gaps, and the thing that does not quite line up.
Neurodivergence is part of how my mind works. I tend to notice when two parts of a system tell different stories, when a process has more friction than it should, or when the obvious answer is hiding a better one.
That can make me persistent—occasionally stubborn—but it is also why I enjoy problems that are messy but real. Give me competing constraints, unclear ownership, or a system that has grown past its original shape, and I will start looking for the simpler structure underneath it.
01
See the shape
I reduce a complicated system into the few decisions that actually matter.
02
Make it usable
I care about polish when it helps someone understand the product, trust it, and use it with less friction.
03
Stay with the problem
I am comfortable revisiting the same hard edge until the result is genuinely better, not merely different.
What sharpened me
Fatherhood made my priorities much clearer.
I am a single dad to a young daughter who has already been through three open-heart surgeries. Watching her face hard things with courage changed my idea of pressure. It made patience more practical, time more valuable, and care a standard rather than a sentiment.
At work, that shows up as preparation, honesty, and a low tolerance for avoidable chaos. I want the software to be dependable because real people are always downstream from the architecture.
What it means in practice
I care deeply about doing ambitious work without forgetting who has to live with the result.
What I’ve been building lately
A big idea has started turning into a real product family.
OverLift began as a sketch of how intelligent software could explore without becoming the final authority. I did not want it to stay a diagram or a clever phrase, so I kept building. It is now an interactive demonstration, a complete Method page, a searchable glossary, and a growing set of products that test the same idea in different settings.
Along the way, the work has become easier to explain and harder to fake: you can open the applications, change the scenario, inspect the evidence, and follow the result instead of taking the architecture on faith.
The core system
The idea became something you can actually watch.
OverLift now walks through a question, the evidence, the possible paths, the guardrails, and the final proof in one interactive experience.
Interactive proof The flagship storyA logistics problem put the method under pressure.
OverLift Logistics uses a synthetic disruption scenario to make speed, cost, risk, rejected evidence, human approval, and replay easy to see.
Working portfolio demo The learning productSearch is learning to understand the question behind the words.
AzureGlossary has grown from a reference site into a guided learning system with semantic search, diagnostics, and exam-focused paths.
Live product Across the portfolioThe same discipline is being tested in very different worlds.
Saros, Vellucent, Veil, Neon Drift, and the emulator work let me explore research, truth, interpretation, local AI, and real-time performance without turning every product into the same demo.
Active developmentThe idea I am most excited about
OverLift helps AI be imaginative without letting it become careless.
The plain-English version is simple: AI is good at exploring a problem, finding patterns, comparing options, and explaining a recommendation. It is not the right place to keep the final truth, decide who has permission, or quietly rewrite the official record. OverLift keeps those jobs separate.
That separation is what makes the work interesting to me. The experience can still feel intelligent and creative, while the important facts, rules, approvals, and outcomes remain visible and under human control.
The whole idea in one line
Let intelligence explore. Keep truth exact.
The AI may help find the route. It does not get to redraw the map.
What happens, in plain English
Five moves from a real question to a result you can trust.
The deep engineering lives on the Method page. This is the human version.
-
01
Understand the question
Clarify what someone is trying to decide, what matters, and what is off limits.
-
02
Gather what is actually known
Show the current evidence and keep missing or conflicting information visible.
-
03
Compare a few honest options
Explore more than one path and explain the tradeoffs instead of pretending there is no uncertainty.
-
04
Apply the security and authority rules
Check identity, permissions, capability scope, limits, freshness, and approvals before anything consequential is allowed to happen.
-
05
Save what happened and why
Keep the evidence, decision, approval, and outcome together so the result can be checked later.
Go as deep as you like
Start with the story, then open the engineering when you are curious.
The live application lets you watch the behavior. The Method page explains the architecture. The glossary translates the vocabulary. OverLift Logistics gives the idea a concrete business problem.
WHY I BUILT OVERLIFT THIS WAY
Trust is not a personality trait the model can promise.
The engineering has to assume that a model, retrieved document, generated function, or tool proposal can be mistaken or manipulated. Workers, WebAssembly, explicit capabilities, deterministic state, approvals, receipts, and replay make that failure containable and inspectable.
Prefer browser-local, same-origin, or offline processing; disclose only the approved evidence a remote service actually needs.
Use worker and WebAssembly containment, explicit imports, typed tools, deadlines, allowlists, and fail-closed defaults.
Keep identity, permissions, policy, approval, exact execution, verification, receipts, and replay outside probabilistic control.
Education path
I did not take the straight-line route, and I am glad I did not.
I started community college at 28, then found my way to U.C. Berkeley and later UNR. That path was earned later and more deliberately, while building a life and a career rather than following a perfectly timed script.
I have a soft spot for people who keep learning after the easy window has closed. There is a different kind of energy in it. You know why you are there, and you do not take the opportunity for granted.
28
Community college
I started the academic climb as an adult, with more context, urgency, and ownership.
Next
U.C. Berkeley
The path widened and proved that unconventional did not have to mean unserious.
Then
UNR
I kept building the practical base for product thinking, systems work, and business judgment.
Working style
High standards, low drama, and a shared map.
I do my best work with people who can be direct, curious, and generous with what they know. I like the teammate who notices the quiet bug, the engineer who documents the thing nobody wanted to document, and the leader who wants the truth more than applause.
My own style is friendly, candid, and a little stubborn in the useful way. I want the system to work. I want the explanation to be clean. I want the next person to have a better map than I had.
Good engineering leaves behind clearer language, reusable patterns, and fewer mysteries.
I would rather surface a difficult tradeoff early than hide it behind optimism and pay for it later.
Ideas matter, but the satisfying part is turning one into a product another person can actually use.
About this portfolio site
This site is part portfolio, part laboratory.
I built it instead of dropping my work into a template because I wanted the experience to carry the same values as the products: a clear story, real interaction, visible evidence, and the willingness to keep improving after the first version looks finished.
Underneath, it is a .NET and Azure application with live demos, guided product stories, search, diagnostics, publishing tools, and a private workshop that helps me measure what people understand and where the experience still needs another pass. The technology matters, but the point is simple: the work should be openable, understandable, and honest.
The layout, stories, demos, and interactions were shaped around the work instead of squeezing the work into a template.
The strongest pieces can be opened, questioned, and inspected instead of surviving only as screenshots and claims.
Testing and measured behavior help me see what is clear, what is confusing, and where polish is getting in the way.
As the products mature, I fold that progress back into the portfolio rather than hiding it in a changelog nobody will read.
Best fit:
teams building useful AI products, modernizing important software, or tackling a problem that needs both imagination and discipline.