How we work Engagements

Flexible engagement models.

Every project has different constraints. The engagement structure should reflect that reality, not force both sides into a shape that does not fit.

Engagement models

Three ways to work together.

Fee for service

The default for most engagements. You define the scope, we agree on a price, and engineering starts on a clear timeline. The resulting code and intellectual property belong to you. No warrants, no vesting schedules, no cap table conversations. When the work is done, the relationship ends cleanly unless both sides want to continue.

This model works best when the project has a well defined scope, a known budget, and a team that will own the system after launch. It is also the right starting point when the relationship is new. Most of our engagements begin here and stay here, because simplicity is a feature.

Equity partnership

For a small number of projects each year, we reduce or waive our fee in exchange for a meaningful equity stake. This is not a discount program. It is a deliberate decision to stand closer to the outcome, which means both sides have skin in the game. We look for founders with conviction, a problem that is genuinely interesting, and a realistic path to a product that people will pay for.

When engineering is core to the product's success, equity alignment changes how the team shows up. We stop thinking like a vendor filling a statement of work and start thinking like a partner invested in long term outcomes. Terms are negotiated individually, documented simply, and structured so incentives stay aligned through launch and beyond.

Revenue share

For platforms that generate recurring revenue, the engagement trades part of the fee for a percentage of revenue over an agreed period. This aligns incentives directly with the product's commercial success. The engineering team is motivated to build systems that perform in production, not just pass acceptance testing, because the revenue share only flows when the platform is live and earning.

Revenue share works well when the platform has a clear monetization model, whether that is transaction fees, subscription revenue, or settlement margins. Terms are structured around a defined revenue metric, a percentage, and a duration. Both sides understand exactly what success looks like and how the economics flow.

Hybrid

A combination of fee, equity, and revenue share tailored to the project's constraints. Maybe a reduced monthly fee paired with equity upside. Maybe a standard fee with a revenue share tail that rewards long term performance. Maybe a milestone based structure where the fee adjusts as the project hits commercial targets.

Every hybrid is structured around the specific situation. Limited early capital, uncertain timeline, revenue that is close but not yet flowing. The terms are explained in writing before any paperwork moves, so nothing in the final agreement comes as a surprise.

How to decide

Match the model to the situation.

Fee for service

Works best when

The scope is well defined, budget is allocated, and your team will own the system after launch. You want clean ownership, predictable costs, and no long term entanglements. The relationship is new and both sides want to prove the fit before going deeper.

Equity partnership

Works best when

Engineering is the product. The founding team is strong, the idea has real differentiation, and technical execution is the primary risk. Capital is limited but conviction is high. Both sides want an engineering partner who stays invested in the outcome for years, not weeks.

Revenue share

Works best when

The platform has a clear revenue model and commercial launch is near. Transaction fees, settlement margins, or subscription revenue are already defined. Both sides want the engineering investment tied directly to commercial outcomes.

Hybrid

Works best when

The project sits between a straightforward build and a full equity bet. Maybe cash is constrained early but revenue is close. Maybe the scope is large and a blended structure lets both sides share the risk. Custom terms, one set of incentives.

Tell us what you are building.

Every project starts with a conversation.

FAQs

Do we own the code at the end of the engagement?
Yes. All code and intellectual property belong to you under fee-for-service. There are no warrants, no vesting schedules, and no cap table conversations. When the work is done, the relationship ends cleanly unless both sides want to continue.
How do you price an engagement when the scope is not fully defined yet?
Discovery produces a detailed architecture document and realistic timeline before pricing is finalized. If scope is genuinely uncertain, a time-and-materials structure with weekly transparency keeps costs predictable without forcing premature commitments.
What if our funding situation changes mid-project?
Engagement models can be renegotiated as the project evolves. Most start fee-for-service to prove fit, and the structure can shift to include equity or revenue share if both sides agree. All terms are documented before any change takes effect.
How do we know which engagement model is right for us?
It depends on your stage and constraints. Fee-for-service works for funded teams with defined scope. Equity suits early-stage founders where engineering is the product. Revenue share fits platforms near commercial launch. The first conversation helps clarify which structure makes sense.