Insights
Field notes &
working papers.
Practical writing about people, AI, and the systems they rely on. For product teams, engineering leaders, and people turning complex information into useful decisions.
30 articles
Numerical engineering
Why did the same calculation give a different answer?
Four input values produce several legitimate quartiles. Work through the arithmetic, numerical tolerances, and version context needed to explain a changed answer.
Platform architecture
What should two products share, and what should stay separate?
Two fictional product teams compare similar records and different commitments, then test whether a shared boundary makes real changes easier to manage.
.NET engineering
Give AI a .NET change you can actually verify
A missing measurement and a measured zero are different. Use that simple distinction to make an AI-assisted .NET change concrete, reviewable, and testable.
Library engineering
From AI-generated C# to a package another team can use
A worked package handoff shows how public API compatibility, package checks, and consumer behavior support different release decisions.
Record linkage
When two records might describe the same subject
Two records look alike. Work through candidate links, conflicting assignments, and the evidence needed before treating them as the same subject.
Agent engineering
Your AI task stopped halfway through. What happens next?
A fictional interrupted research task shows what must survive a restart, why retries need a receiving contract, and how to keep recovery understandable.
Research evaluation
Did the research help, or did the outcome just turn out well?
A worked synthetic scoring example helps distinguish a supported answer, a better forecast, and evidence that a research feature improved a decision.
Product design
Human review needs more than an approve button
A fictional date correction shows what a reviewer needs beyond an approval button, with interface concepts and practical ways to evaluate the work.
Interaction design
What should people see while AI is working?
Design progress around a person’s task: meaningful status, useful controls, a clear return experience, and partial results that explain what remains open.
Genetics & product design
Why more genetic data does not automatically mean better evidence
Why a larger reference dataset can still leave the important question unanswered, with a worked population example and practical choices for scientific software.
Scientific systems
When scientific reference data changes, which results become stale?
An original dependency example shows how to find affected reports, distinguish review from recomputation, and preserve the history of scientific results.
Research architecture
What did the system know at the time?
Work through a synthetic revision timeline to see why current, publicly available, and locally captured research can produce three different answers.
AI engineering
Where AI reasoning ends and system authority begins
A detailed application design for typed proposals, stale approvals, concurrent changes, and the boundary between AI reasoning and an authoritative record.
AI engineering
AI engineering starts with the failure path
The engineering decisions behind useful AI: clear commitments, recoverable failures, meaningful evaluation, and a handoff people can understand.
Product development
A product milestone should finish a user’s job
Shape milestones around what a person can finish, including the handoffs and exceptions that determine whether the product is useful.
Genetics & software
What trustworthy genetics software has to preserve
Reference context, source attribution, and interpretation history make genetic information easier to inspect, exchange, and correct.
Practice notes
What forward-deployed engineering should deliver
What an embedded engineering engagement looks like, where AI helps, and which responsibilities remain with the engineer.
Research engineering notes
A research signal needs a way to be wrong
Lessons from animal-data research: inspect field definitions, measurement coverage, and relationship assumptions before presenting a pattern as a finding.
Architecture notes
Financial research quality lives between the source and the answer
Why retained sources and deterministic calculations are only the beginning of an inspectable AI research workflow.
Field notes
AI-enabled engineering for domain-heavy platforms
AI tooling is genuinely useful in software modernization — but not in the ways most people assume. The value is in compressing the scale-dependent parts of the work: codebase archaeology, test scaffolding, documentation drafting. The judgment-dependent parts still require engineers who understand the domain.
Architecture note
Replacing isolated report pages with a unified analytical workspace
Government platforms often end up with 30+ isolated report pages, each with its own filter setup and no shared context. Consolidating them into a unified workspace requires more than a new frontend. It requires auditing session state, mapping stored procedure parameters sourced from it, and sequencing the migration so hidden dependencies do not surface mid-delivery.
Architecture note
What it takes to design an animal-first genetic testing platform from scratch
New-build platforms carry different architectural risk than modernization work. The constraint is not accumulated debt — it is making foundational decisions that will govern how the platform grows for years. This note covers the design principles behind a new animal genetic testing LIMS built from first principles.
Case study + insight
Turning Operational Data Into a Usable Growth System
When a platform has rich operational data but a CRM that cannot represent the relationships that actually drive growth, the gap shows up in every campaign. This article covers how Protabyte designed a custom HubSpot architecture to close that gap.
Architecture note
Why internal admin workflows matter as much as customer-facing features
Every customer-facing capability creates a corresponding internal requirement. When those requirements are not designed for, they do not disappear. They become the responsibility of whoever is working the support queue that day.
Working paper
Modernizing public health systems without breaking the mission
Public health and federally-affiliated platforms face a distinct category of modernization challenge. The system cannot be rebuilt from scratch, the operational risk of disruption is high, and technical debt has accumulated across every layer. This working paper examines how to structure a modernization program that addresses security, runtime, dependencies, testing, CI/CD, and frontend concerns in a sequence that actually works.
Field guide
What a real modernization assessment looks like
Saying a platform needs modernization is easy. Knowing what that actually means across security posture, runtime model, dependency health, test coverage, CI/CD maturity, configuration architecture, and frontend stack — and knowing how to sequence the work — is the harder problem. This field guide walks through what a rigorous modernization assessment covers, using a public health software platform as the reference context.
Architecture note
Why checkout friction often starts in backend architecture
When a purchase flow underperforms, the instinct is to look at the interface. In many cases the friction is not the result of poor design. It is backend architecture that was never built to support a clean purchase path.
Technical briefing
Designing intelligent document processing for regulated industries
How to architect a document AI pipeline that satisfies insurance, healthcare, and government audit requirements, without sacrificing accuracy, throughput, or operational flexibility.
Architecture note
Technical due diligence: what investors and acquirers actually want to see
A practitioner's perspective on what a rigorous technical due diligence assessment covers, what findings typically surface, and how to prepare a codebase and architecture for external review.
Field notes
When scientific software becomes operational infrastructure
Scientific and research-driven platforms often begin by solving domain problems effectively. Over time they become relied on as operational infrastructure. Modernization in these environments requires more than framework upgrades. It requires architecture discipline, clearer API boundaries, and careful handling of workflow dependencies.
What we write about
Field Notes for Technical Leaders
New articles, frameworks, and working papers.
Request occasional updates from the practice. You can ask us to stop at any time.
Looking for practical guidance now?
If you have a specific challenge you are working through and cannot wait for an article, a direct conversation is the fastest way to get useful input.