How to choose a tech partner for your MVP

To choose a tech partner for your MVP, run a short, paid selection process instead of comparing pitch decks. Write down what the first version must prove. Shortlist two or three teams and ask each the same questions. Check who will own the code and the accounts. Then pay your favorite for one small, real piece of work before you sign anything bigger. The partner who ships that first piece well, tells you what not to build, and leaves everything in your name is usually the right one. As of 2 October 2026, the legal and platform facts below come from the primary sources listed at the end.

This guide is for founders choosing a software development company or development partner to build or finish a first product. That partner might be an agency, a freelancer, a studio or a subscription team, and the product might have started in Lovable, Bolt or a similar AI builder. It is a process, not a ranking. If you want the routes compared on cost and fit, read agency vs freelancer vs in-house first.

What should you decide before talking to anyone?

Three things: what the MVP must prove, what is already built, and what you can spend in the first year. Without them, every proposal looks reasonable and none can be compared.

• The one assumption the first version tests. For example, "small gyms will pay monthly for class booking". Everything that does not test it can wait.
• What exists today: a Figma file, a Lovable prototype, a spreadsheet, or nothing. A working prototype changes the job from building to engineering.
• Your budget for twelve months, not for the first release. Hosting, fixes and the second version all cost money too.
• Who on your side makes product decisions, and how many hours a week they have for it.

If you are not sure what belongs in a first version, read what an MVP is. Then write the answers on one page. You will send that page to every candidate, so their answers are comparable.

What kinds of tech partner are there?

Most options fall into five groups. Each fits a different stage, and the wrong one is expensive mainly because switching later costs time.

A fractional CTO and a technical co-founder are roles, not vendors, so they are defined separately in our glossary. For how a subscription differs from an agency on price and process, see development subscription vs agency.

What questions should you ask a development agency?

Ask the same questions, in writing, to every agency, freelancer or team on the shortlist. The answers matter less than how specific they are.

1. 01Who will actually do the work?Ask for the names and roles of the people on your project, and meet the lead engineer before you sign. Sales and delivery are often different people.
2. 02What would you cut from my first version?A good partner pushes back on scope. A team that agrees to everything is easy to hire and costly to learn from.
3. 03How do changes reach users?Ask how often they release, whether there is a staging copy for testing, and how a release is rolled back if it breaks.
4. 04How do you test?Ask which tests run automatically on every change, and who reviews code before it ships. Ask to see a test report from a current project.
5. 05What happens when scope changes?Ask how a new request is estimated, how fast, and what it does to the price and the date.
6. 06Who owns the code, data and accounts?Ask in whose name the repository, database, hosting, domain and app store accounts will be created. The right answer is yours.
7. 07What happens after launch?Ask who fixes bugs, applies security updates and watches errors once real users arrive, and what that costs.
8. 08Can I speak to a recent client?Ask for one from the last twelve months, and ask that client what went wrong and how the team handled it.

Who owns the code a partner writes for you?

Not automatically you. Under US copyright law, as of 2 October 2026, copyright belongs first to the author of the work (17 U.S.C. 201). Work an employee does as part of the job belongs to the employer. Work by an outside contractor counts as "made for hire" only in nine listed categories, and only if both sides sign a written agreement saying so (17 U.S.C. 101). Software is not named on that list.

So the usual route is an assignment: a written transfer of the rights, signed by the owner. The law requires that for a transfer of copyright ownership (17 U.S.C. 204). Make sure your contract contains one and that it covers code written by subcontractors too. Check when the rights pass to you: as each invoice is paid is safer than only when the whole project ends. This is general information, not legal advice; have a lawyer read the contract.

Ownership of the accounts matters as much as ownership of the rights. Ask for the code repository, the database and the hosting to be created in your own organization from day one, with the partner invited as members. Moving them later is possible but has conditions. GitHub's documentation says a repository transfer needs admin access to the repository, and that its issues, pull requests and wiki move with it. Supabase's documentation says only the owner of the source organization can transfer a project. An active GitHub integration or log drains must be removed first.

What are the red flags?

Most bad partnerships show warning signs before the contract is signed. Watch for these:

• A fixed price and date given before anyone has seen your prototype or asked what the MVP must prove.
• The repository, database or hosting will live in the partner's accounts "for now".
• No staging environment, no automated tests, or "we test manually before launch".
• You cannot meet the engineers, only a salesperson or a project manager.
• Every question gets a yes, and nothing in your scope is challenged.
• No answer to what happens after launch, or support that is priced only once you ask.
• A plan to rewrite your working Lovable prototype from scratch, without a reason tied to what it must prove.

One red flag is not always a dealbreaker. Two or more on the same candidate usually is.

Why pay for a first change before you commit?

Because a small, real piece of work tells you more than any proposal. Pick a change that matters but is small: a sign-up flow, one integration, a set of access rules. Pay the shortlisted favorite to deliver it, in your repository, through their normal process.

Then judge what you got, not what you were promised:

• Did it arrive when they said, and did they tell you early about any delay?
• Is it live, or on a staging copy you can click through, rather than in screenshots?
• Did it come with tests, and do they run on their own?
• Can you read the pull request and understand what changed and why?
• Did they ask good questions, or did they guess?

A first change costs a fraction of the project and protects the rest of it. If the work is good, you continue with evidence. If it is not, you have lost a week, not a quarter. If you built your prototype in Lovable, our guide to hiring a Lovable developer adds what to look for in that case.

How do you compare the finalists?

Score each finalist from 1 to 5 on the same five lines, and weigh the first two most heavily:

1. Evidence: the paid first change, test reports and a recent reference.
2. Ownership: code, data and accounts in your name, with an assignment in the contract.
3. Release process: staging, automated tests, review by a second engineer, rollback.
4. Fit: they understood what the MVP must prove and cut scope to match it.
5. Cost over twelve months, including the work after launch.

Price comes last on purpose. The cheapest quote is often the most expensive project once rework and a second partner are counted.

When is Plutonapps the wrong choice?

We are a development subscription for founders who design in Lovable and need engineers to turn each version into a live product. That is a specific fit, and these cases are better served elsewhere:

• You need a one-off build with a fixed scope and no changes after launch. A fixed-price agency or a strong freelancer fits better.
• Technology is the company's core for years, and you want someone with equity. Look for a technical co-founder.
• You mainly need advice, hiring help or a board-level view. A fractional CTO fits better.
• Your budget for the year is below the cost of any team. Keep building in your AI tool and validate first.

When we are a fit, it looks like Ekko. The founder designed both halves of a waitlist platform in Lovable on our Starter plan. Our engineers built the system underneath in 36 working days. Stress-tested with 25,000 synthetic waitlist entries, it sent zero duplicate rewards. Ekko is pre-launch. Read the Ekko case study.

Starter is $2,999 a month paid annually, or $3,999 month to month; Growth is custom. A month-to-month Starter plan can be cancelled at any time and stops at the end of the current billing month. See pricing. To see where your app stands first, take the free production-readiness check: 19 questions, a score out of 100 and your three biggest risks.

Sources

Each legal and platform fact above comes from one of these pages, checked on 2 October 2026.

• US Code, 17 U.S.C. 201: Ownership of copyright (law.cornell.edu/uscode/text/17/201).
• US Code, 17 U.S.C. 101: Definitions, "work made for hire" (law.cornell.edu/uscode/text/17/101).
• US Code, 17 U.S.C. 204: Execution of transfers of copyright ownership (law.cornell.edu/uscode/text/17/204).
• GitHub documentation: Transferring a repository (docs.github.com).
• Supabase documentation: Project transfers (supabase.com/docs/guides/platform/project-transfer).
• Lovable documentation: GitHub integration (docs.lovable.dev/integrations/github).
• Plutonapps: our pricing page, plan terms and Ekko case study, as published on this site.