A production-ready foundation for intelligent accounts payable.

I propose joining Helm as CTO, beginning with a focused three-month engagement. The goal is to build a production-grade MVP, establish the company's technical foundation, and give us both enough time working together to assess the long-term fit.

The initial product should prove Helm's central idea: accounts payable software that does more than move invoices through a workflow. By understanding contracts and invoices together, Helm can identify savings opportunities, show their effect on cash flow, and connect customers with funding that helps them act on those opportunities.

For the first three months, I would lead product and engineering without building a larger engineering team prematurely. At the end of that period, we would review what we have built, what we have learned, and whether we want to continue the relationship long term.

Helm is an accounts payable SaaS platform in the same broad category as Xelix, Ramp, and Medius. Its opportunity is to combine the essential AP workflow with a more valuable layer of financial intelligence.

The key differentiator is Helm's ability to read contracts and invoices together, then surface opportunities a conventional AP system would miss:

The final financing structure and accounting treatment would be developed with the appropriate legal, lending, and accounting guidance.

The first phase is targeted at approximately three months and should produce a production-grade MVP that is credible with early customers, investors, and future hires. The aim is to prove the complete journey:

1. Upload the source documents

   A customer uploads contracts and invoices into a secure, controlled workspace.

2. Understand the commercial terms

   Helm extracts and connects the relevant terms across contracts and invoices.

3. Detect a real opportunity

   AI identifies a genuine optimization and explains its value and cash-flow effect.

4. Present an eligible funding path

   Helm surfaces a funding option backed by an onboarded financial partner.

5. Guide the application

   AI walks the customer through the required information, documents, consent, and application steps, while the financial partner retains responsibility for underwriting and approval.

6. Fund, pay, and measure

   The customer receives and uses real funding to act on the opportunity, with the payment and realized saving tracked through the dashboard.

The phase should also:

• Establish a secure, maintainable technical foundation rather than extend a demo architecture.
• Onboard and integrate at least one financial partner for the initial live funding workflow.
• Identify the features that matter most to an initial market launch.
• Produce a functioning platform for later fundraising and hiring conversations.
• Give us a practical basis for assessing our working relationship.

This is a target, not a promise made before discovery. Delivery will depend on timely product decisions, representative contracts and invoices, partner onboarding, compliance and underwriting requirements, third-party dependencies, and the scope agreed at kickoff.

I would take an AI-first, requirements-led approach. AI now lets a small, experienced team move at a pace that once required a much larger engineering organization — but it does not replace sound architecture, security, or technical judgment.

• Lead product and engineering directly, using AI as the primary implementation layer, with no additional engineering hires.
• Introduce a product designer once early workflows and brand direction are ready for dedicated design work.
• Favor a type-safe, compiled backend suited to financial software, with a modern web frontend and strongly typed interfaces.
• Use managed infrastructure where it reduces operational overhead and keeps time and runway focused on the product.
• Choose technology based on Helm's requirements, maintainability, and security — not personal attachment to a language or framework.

Code is a means of delivering the business, not the product in itself. Rather than writing implementation code line by line, my role is to turn the business requirements into a coherent product and system architecture, define the boundaries and engineering standards, direct AI-generated implementation, review the resulting system, and remain accountable for what we ship.

Mobile applications may become useful after the web experience is established. If the requirements support them, I would favor native Swift for iOS and Kotlin for Android, using the same core API as the web platform.

Hosting: managed infrastructure, deliberately simple

Dominic has raised Render as a potential infrastructure and hosting platform. I agree it is a strong initial target, because it lets us deploy and operate Helm without sinking time into systems administration.

• One Docker container for the web frontend
• One Docker container for backend services
• Managed PostgreSQL for the primary database
• Managed queues and background processing
• Managed networking, certificates, and deployment
• Monitoring and supporting services as required

I have used Kubernetes where infrastructure requirements justified it, including projects needing deeper control over customer-specific domains and DNS resolution. Helm does not currently appear to have those requirements: Kubernetes would likely add cost, complexity, and administration without a corresponding product advantage.

Render should be the preferred starting option, subject to validation against Helm's security, data residency, reliability, and compliance requirements. We can revisit the infrastructure if scale, isolation, regulation, or customer requirements eventually justify a more customized approach.

I would serve as Helm's CTO while working remotely from Toronto and operating through Blueprint Ventures Inc., my Ontario-based company. The first three months would be a business-to-business contractor relationship rather than employment by a U.S. entity.

Role

CTO, responsible for product technology, architecture, engineering, delivery, and the initial technical hiring strategy, with services initially provided through Blueprint Ventures Inc.

Location

Remote from Toronto, with regular collaboration with Dominic.

Availability

Generally asynchronous, with availability for meetings from 9:00 a.m. to 5:00 p.m. Eastern, Monday to Friday, and additional flexibility when the work requires it.

Engagement

Initial independent contractor arrangement between Helm and Blueprint Ventures Inc., Ontario, Canada.

Exclusivity

Non-exclusive during the initial transition, with the intention that Helm becomes my primary long-term professional commitment.

Operating model

Outcome-oriented autonomy, direct communication, frequent product review, and fast decision-making.

Initial team

No engineering hires during the first phase; Lee directs the architecture and AI-assisted delivery, with targeted design support when appropriate.

Evaluation point

A mutual review at the end of the initial three months.

At the outset, I will continue to hold leading roles in several smaller projects. I have an existing commitment to a partner, as well as work already underway across my own internal ventures and their current runways. I intend to honor those commitments and see the agreed work through to completion rather than abandon it when I begin working with Helm.

These are established and bounded obligations. I do not expect them to materially affect my general availability or the three-month plan. I will organize my calendar so Helm has dependable access, timely decisions, and the responsiveness the CTO role requires.

We should review the transition openly at the three-month evaluation point and agree on its timing and structure based on the relationship, product progress, customer traction, and business needs. Throughout the transition, each project will remain operationally separate, with clear boundaries around time, confidential information, intellectual property, and company resources.

Helm should hire for judgment, systems thinking, and business understanding — not allegiance to a programming language.

Helm has already seen the cost of stack-led leadership. A strong prior preference for Go became a source of friction between the former CTO and Dominic, letting the language itself compete with the needs of the product. My approach starts from the opposite direction: the business case defines the requirements, the requirements shape the architecture, and only then do we select the tools.

I have no interest in language "holy wars." No technology should be defended as part of an engineer's identity, and no technical preference should outrank Helm's ability to launch, serve customers, manage financial risk, and adapt quickly.

When we do hire, I would prioritize experienced system architects; generalists who can review the platform across frontend, backend, data, infrastructure, and integrations; engineers who use AI fluently while owning its output; people with sound enterprise judgment; and pragmatic collaborators who can change their minds when requirements or evidence change.

Proposed terms for the Helm × Lee Benson CTO partnership. All amounts in USD.

The initial fee is deliberately below market — approximately one quarter of my previous total compensation at Datadog — to prove the relationship while preserving runway for launch, customer acquisition, and necessary hires.

Cash and equity work alongside one another. Equity provides long-term alignment; it is not a permanent substitute for appropriate cash compensation. The exact cap-table basis, vesting mechanics, departure and change-of-control treatment, and other equity terms would be documented in definitive agreements.

I do not currently have authorization to work in the United States. During the initial phase, Helm would engage Blueprint Ventures Inc., an Ontario corporation, to provide my services remotely from Canada. Blueprint Ventures Inc. would invoice Helm monthly in U.S. dollars.

External costs paid by Helm

The monthly contractor fee covers my time and services. Helm would separately cover the reasonable costs required to develop, operate, and support the software, including:

• Dedicated or fixed office space in Toronto, including a WeWork or comparable workspace where appropriate.
• SaaS subscriptions and third-party services used for product development or company operations.
• AI model usage, credits, and related development tools.
• Cloud infrastructure, data storage, communications, monitoring, security, and related technical services.
• Any additional cost reasonably necessary for development, testing, launch, or ongoing operation.

Where practical, Helm should contract and pay for these services directly. Costs initially paid by Blueprint Ventures Inc. would be reimbursed at cost, without markup, when agreed in advance and supported by receipts or invoices. We should agree on a lightweight approval process and an initial operating budget so necessary purchases do not delay delivery.

The contractor relationship should be documented in a services agreement covering scope, invoicing, taxes, intellectual-property assignment, confidentiality, data handling, and termination. Any future U.S. employment arrangement would be separate and conditional on required work authorization and appropriate legal and tax advice.

The first three months are both a delivery period and a mutual evaluation. By the end of the phase, we should have clear answers to four questions:

1. Can we work together with trust, speed, and direct communication?
2. Does the product create a compelling advantage over conventional AP workflows?
3. Have we built a foundation that can support early customers, fundraising, and future hiring?
4. Do we both want to continue building Helm together for the long term?

If the answer is yes, I would expect to continue as CTO, own the technology function, and grow the team carefully around the needs of the business.

If this proposal aligns with Dominic's vision for Helm, the next step is a working session to confirm:

• The core workflow and success criteria for the first three months.
• The target start date and product-review cadence.
• Access to representative contracts, invoices, and subject-matter expertise.
• The contractor services agreement between Helm and Blueprint Ventures Inc., including the initial monthly fee.
• The equity basis, vesting mechanics, and required legal documentation.
• Intellectual-property ownership, confidentiality, security, and data-handling obligations.
• The hiring triggers and candidate principles for any expansion of the technical team.
• The boundaries around existing commitments and the transition toward Helm as my primary long-term focus.
• The interim cash-compensation level for months four through twelve and the path to market-rate CTO compensation.
• The operating budget and approval process for external development and workspace costs paid by Helm.

This proposal records our current commercial intent and is not a binding agreement. Final terms would be set out in the appropriate contractor services, equity, intellectual-property, and confidentiality documents.