Building an MVP When You Can't Code: 7 Decisions to Make Before You Hire

You have an idea, some savings, and no idea how to read code. That describes most founders who post an MVP job. This week we read about 50 fresh project briefs on Upwork, and the pattern was hard to miss: marketplaces, small SaaS tools, a trading journal for an online school. Nearly all of them were written by people who run a business and have never opened a code editor.

That's fine. You don't need to code to get a good first version built. You do need to make a few decisions before you talk to a developer, because nobody else can make them for you.

1. Decide what the MVP has to prove

An MVP isn't a small version of the final product. It's the cheapest thing that answers one question: will people use this, and will they pay?

CB Insights went through 431 failed venture-backed startups and found 43% died from poor product-market fit. They built something, and then learned nobody needed it. Money ran out later, as a symptom.

So write the question down. "Will dog groomers in Leeds pay £29 a month to take bookings online?" is a question. "Build a platform for the pet industry" isn't.

2. Know what it usually costs

Prices are all over the place, and that's the first thing to accept.

Published 2026 guides put a simple MVP at $8,000 to $25,000 and 4 to 6 weeks. A SaaS product with accounts and billing lands around $30,000 to $80,000 over 2 to 4 months, and a marketplace at $40,000 to $120,000. No-code builds on Bubble or Webflow run $5,000 to $15,000.

Now compare that with what founders actually offer. The marketplace and SaaS briefs we read with a budget above $3,000 sat between $3,500 and $10,000. Another marketplace brief, posted that morning, already had 398 proposals.

Both numbers are real. The gap between them is scope. A $7,000 marketplace exists, it just doesn't have in-app chat, reviews, payouts to sellers and an admin dashboard on day one.

3. Cut until it hurts

Take a two-sided marketplace. For the first 20 customers you need a way to list an offer, a way to find it, and a way to pay. That's the product.

Everything else can wait or be done by hand. Approving sellers? You, in a spreadsheet. Disputes? Your email. Notifications? One template. A native iPhone app? The website works on a phone.

A useful test: if you removed this feature, would your first 10 users refuse to try the product? If not, it goes on the "later" list. Founders hate this step. It's also where half the budget comes back.

4. Pick the tool for the stage you're in

AI builders like Lovable and Bolt will give you a clickable app in a weekend. For showing an idea to investors or early users, that's a great deal.

They get expensive when real users arrive. We saw several briefs asking a developer to finish a Lovable or Base44 prototype, one of them offering $5,000 to take it to production. Logins, payments and data storage are usually where those prototypes need rework.

A rough rule. If you're still testing whether anyone cares, use the fastest tool you can. If people are already paying or handing you personal data, you want code that a developer owns and can maintain.

5. Write a one-page brief in plain words

You don't need a technical specification. The best brief we read this week said it outright: "No trading knowledge required." The founder had attached a description in plain language instead.

One page covers it:

• who the user is and what problem they have today
• the 3 to 5 things they must be able to do in version one
• what's deliberately left out
• a product you like the look of
• your budget range and the date you need it

Put the budget in. Hiding it doesn't get you a lower price, it gets you ten quotes for ten different products.

6. Keep the keys

This one costs nothing and saves the most pain. The domain, the hosting account, the code repository, the Stripe account and the app store listing should all be registered to you, with the developer invited as a collaborator.

We also read a brief that opened with "our only senior engineer left three months ago, and nobody on the team can safely deploy". Don't be that company in a year.

7. Ask to see it every week

Fixed price suits a first version, because the scope is small and you know your limit. Whatever the contract says, ask for a working link every week. Not a status report. A link you can click on your own phone.

If two weeks pass and there's nothing to click, that's your signal to ask hard questions, while most of the budget is still in your account.

Where to start

Write the one question your MVP has to answer, then the short list from step 5. That page is worth more than any feature list.

If you'd like a second opinion on it, send it to us. We'll tell you what we'd cut, what it would roughly cost to build, and whether you need custom code yet at all.