How it works
Product partnerships, in plain terms.
Many good software products start with someone who knows a market better than any developer could. I partner with those people to build, launch, and run products together. This page is the whole arrangement, including the parts people usually ask about on the first call.
01
What you end up with
A product in your marketBuilt around a problem your clients already pay to solve, with your name on it.
Your share of what it earnsOr all of it, if you fund the build outright.
Someone who keeps it runningHosting, updates, support escalations, and the long work after launch.
You keep doing what you already do well: selling, onboarding, and talking to customers. I do the rest.
02
What each side brings
Access to buyers: existing clients, an audience, or relationships in the industry.
A clear problem people already pay to solve.
Sustained time for selling, onboarding, and customer conversations.
Commitment I can count: early customers, letters of intent, or capital alongside the work.
Product design, architecture, and full-stack engineering: web, mobile, desktop, embedded, and the distributed systems behind them.
Subscriptions, billing, permissions, and data handling done properly.
Hosting, operations, and maintenance after launch.
Engineering since 1998 on systems that had to work, and the business training to decide what's worth building.
03
Two ways to pay
Smaller fee, shared revenue
A reduced build fee up front and a share of revenue or equity, depending on the product. For people who bring customers more than capital. Shares vest as each side delivers on its milestones, so neither of us is paid for work that didn't happen.
One fee, you own it
You pay for the build and own the product outright. For people who would rather fund the work than share it. I can keep running and maintaining it afterward under a separate agreement, or hand it over with documentation.
Either way, we sign a written agreement before any code: ownership, responsibilities, milestones, and what happens if either of us steps away.
04
How it starts
- Step 1ConversationThe market, the problem, and who is already paying for a worse solution. No charge, no obligation.
- Step 2Validate, togetherTwo to four weeks. We shape the offer together; you bring the buyer conversations; I bring the method and the write-up. A small fixed fee, credited toward the build.
- Step 3BuildA focused first version, shipped finished rather than as a demo. Months, not years.
- Step 4Run it togetherYou lead sales and customers. I lead product and operations.
Validation is the one step only a partner can do, and for the right partner it's the easiest. You already know ten people who have this problem. Together we draft a one-page offer with a price on it and the questions worth asking; you know the buyers and their language, and I know how to run a validation that ends in a decision rather than polite interest. You have the conversations and ask for a commitment: a letter of intent, a pre-order, or a paid pilot. I sit in, take notes, and write up what we learned: who buys, what they'll pay, what the first version has to do, and how many said yes.
You keep the research: who we talked to, what they said, what they'd pay. I'd rather lose a build than build something nobody buys. So would you. Straight builds can skip validation if you'd rather carry that risk yourself; I'll still recommend it.
05
What AI does here, and doesn't
AI now takes much of the mechanical work out of writing software. That is why a first version takes months rather than a year.
It works under direction, and the direction is the job: what to build, what it should cost to run, who may see which data, when it is finished, and who answers when it breaks at two in the morning. Those decisions are the product. They are what twenty-eight years of engineering and a business education are for.
A weekend demo and a product that still works in year three can look alike on day one. They are different things, and the difference shows up once real customers depend on it.
06
If I'm not available
A one-person studio has to answer this before you ask it.
You own the accountsHosting, domain, app-store, and billing accounts are in the partnership's name, not mine.
The code is yours to hand onIt lives in a repository you co-own, with a runbook written for an outside developer.
A named engineer can step inEach agreement names another engineering firm that can take over if I can't.
It's in the agreementIf I can't perform for a set period, you may bring in another developer with full access, and the terms adjust.
Circumstances change on both sides of a partnership. The products are built so that a change on either side doesn't put them at risk, and the agreements say so in writing, in both directions.
07
Questions you may have
- What does "small fee" actually mean?
- A fraction of what the build would cost outright, agreed in writing before we start. The rest of what the build is worth is deferred into the revenue share, so I am paid mostly when you are. Straight builds are priced like any fixed-scope engagement.
- Who owns the product?
- Straight build: you, entirely. Partnership: ownership is written into the agreement, and each side's share vests as it delivers. You are never waiting on a handshake.
- Revenue share or equity?
- Depends on the product. If it's a product line inside your existing business, a revenue share is simpler and we're both paid sooner. If it could become a company of its own, we form one and share the ownership, with each side's stake vesting as it delivers. We decide that together after validation, when we know what we're building.
- Who does the validation?
- Both. We write the one-page offer and the questions together: you know the market, the buyers, and what they'd pay; I know how to structure a validation so it produces a decision. You have the conversations, because they're with people who already know you. I sit in, take notes, and write up what we learned. Two to four weeks, usually ten to fifteen conversations.
- How much of your time does this take?
- Plan on several hours a week for the first year, most of it selling, onboarding, and talking to customers. If you can't give that, a straight build with a handover is the honest choice.
- Why not hire an agency or a freelancer?
- You can, and for some products you should. An agency bills hours and leaves. A freelancer builds what you specify. A partner has to care whether it sells, and is still there in year three.
- Why aren't the partners named?
- They're described by role rather than name. Most prefer it, and the agreements are private. Once we're talking, I'm glad to make introductions.
- What if it doesn't sell?
- Validation exists to find that out before the build, and we stop if the buyers aren't there. After launch, the agreement says what happens if revenue doesn't cover running costs, including how either side can exit.
- Does the studio work with people outside Idaho?
- Yes. The work is remote, and the first conversations happen on a video call.
08
Not a fit
- An idea without access to the people who would buy it
- Partnerships where only one side puts in time or money
- Products that need a large team or long enterprise sales cycles
- Projects that need to be built and handed off with nobody running them
Have a market you know well?
Tell me about it: the industry, who the buyers are, how you reach them, and what they use today. That's enough for a first conversation.