Services

Build the R&D capability the company actually needs.

I help life sciences leaders make better decisions about agentic AI, computational R&D, software, and technical leadership. The common thread is simple: use technology to increase product velocity without creating unnecessary complexity.

R&D AI strategy

Understand where agentic AI can create real scientific or product leverage, where it is just noise, and which investments are worth making now.

Computational leadership hiring

Define the first or next computational/software leadership role, interview candidates, and evaluate whether they can build for the company's actual stage instead of the company they imagine five years from now.

Leader advisory

Support an early computational or software leader as they make decisions about team design, architecture, build-vs-buy, validation, vendors, and what not to build.

Focused prototypes

Build just enough to test a high-value R&D workflow, expose constraints, or learn whether an idea deserves a larger investment.

A critical early decision

Your first computational leader can shape the company for years.

Define the role before the title

Does the company need a bioinformatics scientist, software builder, data leader, platform engineer, product-minded generalist, or some combination? The answer should come from the science and product stage, not a generic job description.

Hire for judgment, not just brilliance

The strongest candidate is not always the person with the most sophisticated architecture. Early life sciences companies need leaders who know when to build, when to buy, when to stay simple, and how to support rapidly changing R&D.

Seed the right operating habits

The first leader sets expectations for testing, data quality, technical debt, vendors, hiring, and how software relates to the scientific product. Those choices compound for years.

Give the leader somewhere to compare notes

Especially for someone earlier in their leadership career, a trusted outside perspective can help them avoid learning every lesson the expensive way.

Build vs. buy

Neither answer is always right.

Do not build for the joy of building

Bespoke software has a long tail: maintenance, staffing, validation, support, and institutional knowledge. Build when it creates differentiated value or genuinely enables the science.

Do not buy before the workflow exists

A large LIMS or enterprise platform can be a terrible fit for an R&D lab whose protocol is still changing every week. The vendor may be good and the timing may still be wrong.

Match the partner to the stage

Early R&D often needs a nimble tool, small vendor, or lightweight internal system that can evolve with the science. Later, stability and standardization matter more.

Optimize for the product

The question is not whether the software is impressive. The question is whether it helps the company make better science, stronger evidence, and faster product decisions.

How I work

Practical judgment, not a technology shopping spree.

I am there to help leadership focus computational talent and AI on the few things that create real scientific and business value, then leave the company with stronger internal capability.

Talk through where you are