A founder in Berlin has a Figma prototype, a letter of intent from a design partner and €500,000 from a pre-seed round. She talks to four development agencies. Three show similar portfolios: fintech apps, marketplaces, SaaS dashboards with polished screenshots. The fourth has a more modest track record, but sends its contract template after the first call and asks whose GitHub organisation the repository should live in. She picks one of the first three, because its case studies look most like her product.
Eight months later the product works, early customers are paying, and a seed fund sends a due diligence questionnaire. One item reads: “Provide the agreements evidencing the company’s ownership of the source code.” The agency contract says the code will be “delivered upon project completion and settlement of all outstanding fees”, and the project has never formally completed. The repository sits in the agency’s organisation. So does the cloud account. Several of the developers were freelancers subcontracted by the agency. The round stalls for weeks, and the agency knows exactly how much leverage it has.
This article is for founders and CEOs choosing an external partner to build their MVP. The thesis may sound contrarian: the best predictor of a good relationship with an MVP development company is not its portfolio but how easy it would be to leave it. A partner who keeps code, accounts and rights on your side from day one cannot hold you with the contract. It has to hold you with the quality of its work. That is the partner you want.
Why does an agency’s portfolio tell you less than you think?
A portfolio shows what a company has built. It does not show the three things that matter most to a startup: who exactly built it, how long it took against plan, and how the engagement ended. Screenshots of a fintech app do not tell you whether the engineers behind it still work there or will be assigned to your project. Nor do they tell you whether the client later moved development in-house smoothly or spent three months reconstructing documentation.
The second problem is selection. Nobody shows the projects that doubled their budget or ended in a dispute. That is natural and not dishonest, but it means the sample is biased by design. Comparing three portfolios, you compare three best pieces of work, not the average you will actually receive.
The third problem is specific to MVPs. A minimum viable product exists to test a hypothesis, not to impress. An agency that excels at polished enterprise apps is not necessarily good at shipping a version half of which will be thrown away after the first user interviews. For a startup, speed of learning beats elegance in the first release, a point we develop in our guide from idea to product-market fit.
So what tells you more than a portfolio? The contract template a vendor sends unprompted. The answer to “where will the repository live?”. Willingness to run a short, paid trial stage. And how the company talks about clients who left. These signals cost a vendor more than nice screenshots, which is exactly why they are more reliable.
What kind of partner does a startup actually need at the MVP stage?
Before comparing companies, decide what kind of engagement you need. “Software development for startups” covers a lot of ground, and for an MVP four models are realistic. Each shifts a different share of responsibility onto the founder.
A freelancer or a small group of freelancers. Cheapest to start and fastest to mobilise. The risk: one person falls ill or takes a better offer and the project stops. Code ownership has to be secured separately with each individual, sometimes across several jurisdictions. Works when a founding team member can assess code and take it over if needed.
An agency delivering a project. The vendor takes responsibility for delivering the product: UX, development, testing, deployment. The founder buys an outcome rather than hours. The risk: the more the vendor “runs” the project, the less knowledge stays in the startup, and the less knowledge you hold, the more expensive it is to leave.
A dedicated team. The vendor provides a stable team working only on your product, while priorities are set by a founder or product owner on the startup side. A middle path: continuity similar to an in-house team, without recruiting. It requires someone in the startup who genuinely manages the backlog.
Staff augmentation. The vendor supplies individual engineers to a team the startup leads. Makes sense when there is already a technical co-founder or CTO and you are short of hands or a specific skill, such as a mobile developer.
The choice turns on one question: is there anyone in the founding team who can judge the quality of code and architecture? If yes, you can buy hours and direct the work yourself. If not, you are also buying technical judgement, and the contract must protect your access to code and knowledge especially firmly, because you will not spot problems in time on your own.
| Model | Who directs the work | Main risk for the founder | When it fits |
|---|---|---|---|
| Freelancer | Founder | Single point of failure, fragmented IP | Technical co-founder in place |
| Agency (project) | Vendor | Knowledge stays with the vendor | No in-house technical skills, clearly defined first stage |
| Dedicated team | Founder or startup PO | Needs active product management | Product will be developed for 6+ months |
| Staff augmentation | Startup CTO | Vendor not accountable for outcomes | CTO in place, missing capacity or skills |
How do you test a vendor before signing for the whole MVP?
The best test is a short, paid stage after which you can walk away without loss. Instead of signing for the entire MVP after three sales calls, buy discovery first: refined scope, architecture, a plan for the first sprints and an estimate. At ARDURA this phase takes one to two weeks and is used to define scope and architecture. We describe what it should produce in our article on the discovery workshop.
Discovery tests both sides. You see how the vendor asks questions, whether it challenges assumptions or just writes them down, and whether the resulting documents make sense to someone outside its team. One thing matters here: the discovery contract must give you rights to its outputs, so you can take them to another vendor if you decide not to continue. A vendor that refuses has just told you something important.
Second rule: talk to the people who will write the code. Sales meetings usually feature senior architects and directors; the team that shows up later is often different. Ask for the names of the planned team members and an hour-long technical conversation with at least one of them. Write into the contract that key people will not change without your consent and that, if a change is unavoidable, the vendor will provide a replacement within a defined period.
Third rule: ask for a reference from a client who left. References from happy, active clients are easy to get. A client who moved development in-house or to another vendor will tell you how the handover went, whether documentation existed and whether the vendor cooperated to the end. If the vendor cannot name a single such client, ask why.
Fourth rule: read the contract template before discussing price. Price is easy to compare, so it will dominate the negotiation if you let it in first. Yet a 15% difference in day rate matters less than the difference between “rights pass on payment of each invoice” and “rights pass on final acceptance”. The rest of this article is essentially a guide to reading that template.
Fixed price or time and materials: which pricing model protects the founder?
Instinct says fixed price. The startup has a limited runway, investors ask what the MVP will cost, and a fixed price looks like a guarantee. In practice, for an MVP a fixed price protects the founder less than it appears to, and this is the second position of this article that many advisers would dispute.
The reason is simple. A fixed price needs a fixed scope, and an MVP’s scope is supposed to change, because the point of an MVP is to learn from user reactions. If after five customer interviews it turns out the reporting module is unnecessary and the critical feature is a spreadsheet import, a fixed-price contract triggers a change request: estimate, negotiation, amendment. Every change costs time and gives the vendor an opportunity to recover losses from other line items.
On top of that, a vendor taking on fixed-price risk with an uncertain scope adds a premium for that risk. That is not a criticism, just rational behaviour. You end up paying for protection against a risk, part of which comes back to you anyway as scope disputes. Both models can end up costing a similar amount, but fixed price also costs flexibility, which is the one thing an MVP needs most.
The alternative is time and materials with controls that give predictability without rigidity:
- a monthly budget cap the vendor cannot exceed without your written approval;
- short sprints (two weeks is our standard), each ending with a working build you can see;
- a weekly report of hours by task and by person;
- a right to terminate on short notice, with no penalties;
- a budget for scope instead of a feature list: you decide how much to spend on the first release and reprioritise within that amount.
Fixed price has its place: a closed, well-described stage such as discovery, an audit of existing code or one integration with a documented API. There the scope is stable and a fixed price genuinely protects both parties. For an order-of-magnitude budget for the whole MVP, try our MVP cost calculator; this article is about controlling cost in the contract, not estimating it.
Should you pay a development agency in equity?
At pre-seed, an offer of “we’ll build your MVP for 10–20% of the company” is tempting. The founder saves cash and the vendor gets a stake in the product’s success. In practice the arrangement usually hurts both sides and should be treated as a last resort.
The first problem is the conflict of roles. A vendor with equity is both supplier and shareholder. As a supplier it should transfer knowledge and help you build your own team. As a shareholder that receives no cash, it has an interest in staying indispensable, because only then does its stake carry weight in decisions. This need not be a conscious strategy; it is simply where the incentives point.
The second problem is the next round. Investors will see on the cap table an entity holding a meaningful stake that does not work in the company full-time and did not put in cash. Some funds will treat this as a red flag; at best they will ask what happens if the vendor stops working on the product. That question is hard to answer if the equity was issued upfront.
The third problem is legal and concerns the code itself. Equity-for-work agreements tend to be drafted around the shares, with IP treated as a given. It is not a given. If the vendor is a shareholder but no valid assignment of the code to the company exists, the code may formally belong to the vendor or to its individual developers.
If equity really is the only way to start, protect yourself with three provisions: the stake is limited and vests as milestones are delivered, the company has a right to repurchase unvested shares when the engagement ends, and IP passes to the company on exactly the same terms as if the vendor were paid in cash. A mix of cash and a small stake is usually healthier than equity alone.
Who owns the MVP’s code, and how do you put that in the contract?
This is the most important section of this article, and the one founders most often postpone. Without properly assigned rights to the code, your company does not own its core asset, and every investor and acquirer will check.
The first trap is assuming that paying for code means owning it. In the United States, the Copyright Act defines a “work made for hire” in two ways: a work prepared by an employee within the scope of employment, or a specially commissioned work falling into one of nine statutory categories (such as a contribution to a collective work, a translation or a compilation), and only where the parties agree in a signed written instrument. Custom software built by an independent contractor generally does not fit those categories cleanly, so you cannot rely on a “work for hire” label alone. Ownership passes through an assignment, and under 17 U.S.C. § 204(a) a transfer of copyright ownership is not valid unless it is in writing and signed by the owner of the rights. Without one, US courts may find at most an implied non-exclusive licence for the commissioning party, as in Effects Associates v. Cohen (9th Cir. 1990). A non-exclusive licence is not ownership, and it is not what a seed investor wants to see.
In the EU, the Software Directive (2009/24/EC) gives employers the economic rights to programs created by employees in the course of their duties, unless otherwise agreed. Contractors are a different matter, and national rules vary. In Germany, copyright itself cannot be transferred during the author’s lifetime (§ 29 UrhG); what you acquire is an exclusive right of use, which must be granted broadly enough to cover modification and sublicensing. In Poland, a popular nearshore destination, an assignment of economic rights must be made in writing on pain of nullity (Art. 53 of the Copyright Act), covers only the fields of exploitation expressly listed (Art. 41(2)), and cannot cover all future works of an author in a blanket way (Art. 41(3)).
That last point matters more than it looks, because in Central and Eastern Europe many developers work as independent contractors (in Poland usually on so-called B2B contracts) rather than employees. If your MVP is written by a contractor working for the agency, the rights arise with that individual, not with the agency. The vendor can only assign to you what it has validly acquired itself. The chain must be unbroken: developer → vendor → your company. Ask for a warranty that the vendor has obtained, from everyone working on the project, rights at least as broad as those it assigns to you, and a right to inspect those agreements during due diligence. We cover the legal background in more depth in our article on intellectual property in IT projects.
When rights pass is the clause that decides your negotiating position in a dispute. The bad version: “rights pass upon final acceptance and payment in full”. If the project never completes, or one invoice is disputed, you own nothing. The good version: “rights in code delivered during each billing period pass upon payment of the invoice for that period”. A dispute about the last month is then a dispute about the last month, not about the whole product. Tying the assignment to identified deliverables per sprint or invoice also helps satisfy legal systems, like Poland’s, that restrict blanket assignments of future works.
Whatever the governing law, a solid assignment clause covers: assignment (or, where assignment is impossible, an exclusive, perpetual, worldwide licence), express permission to modify and create derivative works, a waiver or non-assertion of moral rights where the law allows it, the developer chain warranty, and a further-assurance obligation to sign whatever documents a future investor or acquirer reasonably requires.
What about open source and the components the vendor brings along?
No modern MVP is built from scratch. It consists of frameworks, open-source libraries, cloud services and, often, the vendor’s own internal components: an authentication module, an admin panel template, deployment tooling. Each layer has a different owner and licence, and the contract must distinguish them.
Vendor components (background IP). An agency will not assign you a module it uses for ten other clients, and you should not expect it to. You should expect a licence to those components that is non-exclusive, perpetual, irrevocable, royalty-free (you have already paid for the project), includes the right to modify, and is transferable to an acquirer of your company or to another vendor. Without it, after parting ways you hold code you cannot legally run.
Open-source licences. Most popular licences (MIT, Apache 2.0, BSD) allow free use in commercial products provided attribution is preserved. Copyleft licences are different. Section 13 of the GNU Affero General Public License version 3 requires that users interacting with a modified version over a network be offered its source code. For a SaaS startup this can mean an obligation to publish part of its own code. Not every use of an AGPL library has that effect, but using one should be a deliberate decision, not an accident.
Put three things in the contract: the vendor maintains a list of all third-party components with their licences (in practice a software bill of materials, or SBOM, generated automatically in the pipeline), introduces no copyleft components without your written consent, and hands over the current list with every release. For a team with a decent CI/CD setup this is minutes of work, and it makes due diligence dramatically easier.
AI-generated code. Developers increasingly use coding assistants. The legal status of AI-generated code is not fully settled; the US Copyright Office has taken the position that purely machine-generated material is not protected without sufficient human authorship, and tools may reproduce fragments under licences incompatible with your product. A sensible minimum: the vendor uses such tools only in configurations that do not send your code for model training, and remains responsible for licence compliance of delivered code regardless of how it was produced.
Where should the repository, accounts and keys live from day one?
On your side. This is the simplest and most effective provision in the whole contract, yet it is most often skipped, because at the start of a project it looks like a technical detail. Copyright on paper is worth little if you have no physical access to the code.
Resources that should be registered to the company and administered by someone in the startup, with access granted to the vendor:
- the code repository (a GitHub, GitLab or Bitbucket organisation owned by the company);
- the cloud account (AWS, Azure, Google Cloud), billed to the company’s card or invoice;
- the domain and DNS;
- app store developer accounts (Apple App Store, Google Play), which are particularly painful to transfer later;
- project management and documentation tools (Jira, Linear, Notion);
- secrets and API keys in a secrets manager controlled by the company;
- third-party service accounts: payments, transactional email, analytics, error monitoring.
There is one rule: the vendor gets access, not ownership. You can revoke that access with a click. The vendor cannot revoke yours at all. When the repository is yours from the first commit, source code escrow becomes unnecessary, because there is nothing to deposit: you hold the code and its full history continuously.
A good vendor accepts this without debate, because it changes nothing in its day-to-day work. A vendor arguing that “it’s better if the repo stays with us because our pipelines are configured there” is proposing what is convenient for itself. Pipelines can be configured in your organisation just as easily. We discuss the broader mechanics of dependency in our article on avoiding vendor lock-in.
How do you write the exit before you need it?
Exit clauses are written in good times, because in bad times nobody negotiates sensibly. A startup may want to end the engagement for many reasons, most of them not the vendor’s fault: a pivot, building an in-house team after a round, failing to raise, an acquisition. The contract should treat parting ways as a normal part of a startup’s life cycle.
Notice period. Measured in weeks, not quarters. Three months’ notice on a monthly burn of tens of thousands of euros is a meaningful share of a pre-seed round spent on work you no longer need. At ARDURA the notice period is 30 days, without contractual penalties. Use that as a reference point when comparing offers.
Handover obligation. During the notice period the vendor delivers: complete code with history (a formality if the repo is already yours), architecture and deployment documentation, instructions for running the local environment, a list of access rights to revoke, a list of known defects and technical debt, and a defined number of hours for knowledge-transfer sessions with the new team. Those hours are billed at the normal rate, but cannot be refused.
No exit fees. No “code handover fees”, no “post-termination licence fees”, no “fees for derivative rights”. Payment for rights is included in payment for the work. State this explicitly.
Independence from disputes. Rights to paid-for code and the handover obligation apply regardless of any dispute over remaining invoices. A dispute about the last invoice is settled separately, not by cutting off access to the product.
Non-solicitation. Vendors often include a ban on hiring their engineers. The interest is understandable, but for a startup that wants to bring one or two key people in-house after a round, a rigid ban is a problem. A pre-agreed conversion fee is better than an absolute prohibition.
If you are taking over an MVP from a previous vendor and do not know the state of the code, consider commissioning an independent technical due diligence before deciding. At ARDURA the Code Health Audit starts from EUR 4,500, takes one to two weeks and has a fixed scope; you own the report and can use it whoever continues development.
Which quality and acceptance terms make sense for an MVP?
MVP contracts tend toward two extremes. One: no quality criteria at all, because “it’s only an MVP”. The other: enterprise requirements copied into the contract, with 90% test coverage and acceptance procedures lasting weeks. The first ends with code nobody can extend. The second ends with an MVP that never ships.
The sensible middle is a definition of done attached to the contract. A task is done when the code has been reviewed by a second person, business logic has automated tests, it has been deployed to a test environment by the pipeline rather than by hand, and documentation is updated if the change affects setup or configuration. This is not a luxury. It is the minimum that lets another team take the code over.
Acceptance. Time and materials has no classic final acceptance, but it is worth agreeing a review after each sprint with a short window for objections. Objections not raised in time mean acceptance. That sounds like a concession to the vendor, but in practice it protects both sides from arguing about work from four months ago.
Warranty period. The vendor fixes defects in delivered code free of charge if they are reported within a set period after release, for example three months. The key distinction: a defect is a deviation from the agreed specification or definition of done, not a new feature someone forgot to request. Without that distinction, the warranty becomes a source of disputes.
Replacing people. If working with a particular team member is not going well, you should be able to request a replacement without lengthy justification. At ARDURA we offer a two-week satisfaction guarantee and replace a specialist within five business days. Whoever you work with, write down a concrete deadline, because “promptly” in practice means “when someone becomes available”.
A vendor that understands MVPs will propose a quality bar matched to the stage on its own: high for payments and user data, lower for experimental screens that may disappear after the first test. For more on where “minimum” ends and “product” begins, see our guide what is an MVP in software development.
Which data protection and security terms must not be skipped?
Few MVPs avoid personal data entirely: user sign-ups, email addresses, payment details, sometimes sensitive data. If the vendor has access to production or to copies of data in test environments, it processes personal data on your behalf.
Data processing agreement. If you serve EU users, Article 28 of the GDPR requires processing by a processor to be governed by a binding contract setting out the subject matter, duration, nature and purpose of processing and the parties’ obligations. The vendor may not engage another processor, such as a subcontractor, without your prior specific or general written authorisation, and under general authorisation it must inform you of changes and give you the chance to object. In the US, sector rules such as HIPAA impose comparable contractual requirements (business associate agreements) for health data, and several state privacy laws require written terms with service providers. This is not paperwork for large companies. It is your obligation as the party responsible for the data.
Data in test environments. State that copies of production data do not go into test environments without anonymisation and, if they must for some reason, only with your consent and for a limited time. One sentence in the contract, and one of the most common routes to data leaks in small companies.
Code security. Minimum requirements worth writing down: dependencies with known vulnerabilities are updated within a set time, no secrets in the repository, multi-factor authentication on every account with production access, security incidents reported within 24 hours of detection.
The EU Cyber Resilience Act. Regulation (EU) 2024/2847 entered into force on 10 December 2024. Obligations to report actively exploited vulnerabilities and severe incidents are scheduled to apply from 11 September 2026, and most other requirements from 11 December 2027. It covers products with digital elements placed on the EU market. A pure SaaS service will in many cases fall outside its scope, but a mobile app, installable software or an IoT device may well fall inside it. The obligations sit with the manufacturer, which means your startup, not the vendor. If your product may be in scope, write in now that the vendor delivers an SBOM and supports vulnerability handling during the period in which you will be accountable for it.
What does an MVP development contract checklist look like?
The table below pulls together the provisions discussed above. Use it when reading a vendor’s contract template, before you start negotiating price. The “red flag” column shows wording that should prompt questions.
| Area | What you are looking for | Red flag |
|---|---|---|
| IP assignment | Written, signed assignment (or exclusive licence where assignment is impossible), incl. right to modify | ”Delivery of code” or “licence” with no assignment |
| When rights pass | On payment of each period’s invoice | On final acceptance and payment in full |
| Chain of title | Warranty covering all employees, freelancers and subcontractors | Silence on subcontractors and contractors |
| Vendor components | Perpetual, irrevocable, transferable licence with right to modify | Licence “for the term of the agreement” |
| Open source | Component list with licences (SBOM), consent for copyleft | Nothing at all |
| Repository and accounts | Company-owned from day one, vendor has access | Repo with the vendor, transfer “after the project” |
| Pricing | T&M with monthly cap and weekly report | Fixed price for unstable scope |
| Termination | Weeks of notice, no penalties, pay for time worked | A quarter or more, penalties |
| Handover | Itemised list, deadline, knowledge-transfer hours | ”On terms to be agreed” |
| Team | Key people named, replacement within a set period | No names, “suitably qualified specialists” |
| Quality | Definition of done, defect warranty | No criteria, or enterprise rules unfit for an MVP |
| Personal data | GDPR Art. 28 DPA (and sector equivalents), rules for test data | No DPA |
| Equity for code | Vesting, repurchase right, full IP assignment | Equity issued upfront, IP unresolved |
Not every clause needs to be worded exactly as described here. What matters is that each area is addressed deliberately. Before signing, have the contract reviewed by a lawyer who knows software and IP law in the governing jurisdiction; the fee is a fraction of one month of a development team.
What are the key takeaways before choosing an MVP partner?
Choosing an MVP development company is largely choosing a contract. Portfolio and price show how a vendor presents itself at the start. The contract shows what the relationship will look like when things go differently than planned, and in a startup something always does.
Remember six things. First, judge a vendor by how easy it would be to leave: its contract template, where the repository lives and references from clients who left say more than screenshots. Second, start with short, paid discovery that gives you rights to its outputs before signing for the whole MVP. Third, with unstable scope choose time and materials with a monthly cap and short notice rather than fixed price. Fourth, secure a written IP assignment with an unbroken chain from individual developers and rights passing with each paid invoice. Fifth, register the repository, cloud accounts and app store accounts to the company from day one. Sixth, write the exit clause now, while both sides are still happy.
If you are looking for a partner to build your MVP, see how we approach custom software development, or book a call. Ask us for our contract template before we talk about price, and check it against the table above. Discovery takes one to two weeks and ends with a scope, an architecture and a plan for the first sprints.