Agency, freelancer or your own developer: who should build your MVP

For a well-defined first version, choose by how much coordination you want to handle: a freelancer if you can direct the work and check deliverables yourself, an agency if you need managed delivery, your own developer if the work continues past launch. If your scope is not yet defined, narrow it before choosing a builder. What goes into version one will shape your budget and timeline more than which model you pick.

What should I sort out before comparing quotes?

Every comparison of agencies, freelancers and in-house hires focuses on price and timeline. Those comparisons become useful after you answer a prior question: what exactly goes into version one?

In one example from practice, a founder brought an agency quote for a two-sided marketplace. The quote priced everything the brief asked for: apps for both sides, in-app chat, ratings, automated matching, payouts and an admin panel. Seven months before the first real transaction. Almost everything on that list assumed the marketplace already worked. The one thing nobody knew was whether buyers and suppliers would actually transact.

The first version was cut to a web flow for buyers, a simple dashboard for suppliers and an off-the-shelf payment provider that splits payouts. The founder’s team matched the first orders by hand. Everything else went on a list called “after 50 orders.” It launched in eight weeks.

The first 50 orders changed what was built next. In-app chat could wait. What suppliers cared about most was getting paid on time. That insight would not have appeared in any brief written before launch.

The technique from that project works for any product. Define the milestone that proves your business works (in that case it was 50 real orders). Go through your feature list and sort each item: “before that milestone” or “after.” The features that survive are your version one.

Which model fits my situation?

Once your first version is defined, the choice is straightforward.

You can break the work into weekly tasks and evaluate what’s delivered. A freelancer is the simplest option: one person, direct communication, no overhead. This works when the MVP is a single application with standard technology and you or someone on your team can tell whether what was built matches what was asked for. If you cannot evaluate the work yourself, you need a technical person alongside you (a fractional CTO or a technical advisor) or a builder who provides that oversight.

You are non-technical and need coordination handled for you. An agency bundles project management, design and development into one engagement. You get a team instead of a single point of failure, and someone on their side manages week-to-week delivery. The tradeoff: decisions go through a project manager, and agencies carry more overhead in their pricing. When evaluating an agency, the same questions apply as with any builder (see below), but ownership and weekly demos matter more because you are further from the code.

You have a working product and ongoing work. Hiring your own developer makes sense when there is a continuous stream of tasks, not a one-time build. If the product is still changing direction, a full-time hire is expensive to unwind. For guidance on evaluating developers, see how to choose a developer or a team.

You are not sure what version one looks like. Before comparing quotes, work with someone whose job is to question the scope: a fractional CTO or a technical advisor. This is the situation from the marketplace example above. The scope, not the builder, was the decision that changed the timeline from seven months to eight weeks. For more on finding the right technical person, see how to find and vet a CTO as a non-technical founder.

Who should own the repo, the cloud and the store accounts?

Regardless of which model you choose, one rule applies from day one: every account belongs to your company.

In another example from practice, a founder had worked with an agency for a year and was happy with them. When asked to look at the product before the next round of features, I found that the code repository, the cloud account, the domain and the app store accounts were all registered to the agency. It had been set up that way early to move fast, which happens often. The founder was paying for the product but did not control any of it.

The founder raised the issue while the relationship was still friendly. Every account moved to the founder’s company, with the agency keeping access as a team member. It took two weeks and no conflict. When the founder later changed teams, the handover took days instead of months.

Before you sign with any builder, confirm these are in your company’s name:

Code repository (your company’s GitHub or GitLab organization)
Cloud account (AWS, GCP, Vercel) billed to your company card, your email as root
Domain registered with your credentials
App store accounts (Apple Developer, Google Play)
Payment provider account (Stripe or equivalent)
Passwords and API keys in a password manager your company owns

If a builder resists transferring any of these, that is a signal.

What should I ask before signing?

Five questions that test whether the builder will help you build the right thing, not just the thing you described.

“What would you cut from this brief to get to first real users faster?” The answer tells you whether the builder is thinking about your product or just estimating the list.
“Whose name will be on the repo, the cloud account and the app store?” The right answer is yours.
“How will I see progress each week?” You want a working demo you can click through, not a status report or a slide deck.
“What happens if we change direction after version one?” The honest answer is that some work gets discarded. Anyone who promises an architecture ready for any pivot is selling certainty that does not exist.
“What is not included, and what will it cost after launch?” Hosting, monitoring, security updates, app store fees and payment provider commissions are real costs after launch. A good builder names them before you sign.

What I’d do in your place

Write down what version one must do, on one page. Use the technique from the marketplace example: define the milestone that proves the business works and sort each feature into “before” or “after.”
Sort out ownership before signing. Repository, cloud, domain, store accounts, payments: all in your company’s name from day one.
If your feature list is still a product vision, not a first version, get it reviewed before picking a builder.
Choose a builder based on your situation (see the framework above) and ask the five questions. The quality of the answers tells you more than the price in the quote.
See working software every week. If a week passes with nothing to click through, something is off, regardless of who is building.

If you want, we can review your situation and agree on a clear next step you can act on.

Free consultation