Free Resource · MVP Planning Toolkit

The MVP Budget Checklist

17 questions every non-technical founder must ask before hiring a developer or signing a contract. Learn them now - or learn them after you've lost ₹10 lakhs.

Free No signup required Built for non-technical founders

Why This Checklist Exists

The most expensive mistake a first-time, non-technical founder makes is not a bad idea - it's a bad developer relationship. Specifically: hiring a developer or agency before they know enough to hold that developer accountable.

Without a technical background, you are in a structurally weak negotiating position. You cannot evaluate the quality of the code being written. You cannot verify that the timeline you were promised is realistic. You cannot tell if the technology choices being made are in your interest or the developer's.

This checklist is designed to change that. These 17 questions do not require technical knowledge to ask. But they require knowledge to answer - and a developer who cannot answer them clearly is a developer you should not hire.

Important: Before you use this checklist, run your idea through StackPick's free MVP estimator to generate a complete technical scope. You will be a much stronger negotiator if you already know the recommended tech stack, the estimated cost range, and the expected timeline before you walk into any developer conversation.

The 17 Questions

Ask every developer or agency all of these. In writing.

Vetting the Team
01

Can you show me a portfolio of similar projects you have built?

Why this matters:

Generic portfolios are useless. You need to see that they have built something with a similar technology stack, user scale, or feature complexity to yours. Ask for live URLs, not screenshots. If they cannot show you a working product, keep looking.

02

Who exactly will be working on my project - full-time employees or contractors?

Why this matters:

Agencies frequently win deals with senior developers and then hand off to junior contractors. Ask for the specific names and experience levels of every person who will touch your code. Insist on meeting them before signing.

03

Can you provide references from at least two recent clients with similar projects?

Why this matters:

Not testimonials on their website - actual names and contact details of clients you can call. Ask the references specifically about deadline adherence, communication quality, and what happened when things went wrong.

Technology Choices
04

What tech stack are you recommending, and why specifically for my project?

Why this matters:

Every technology recommendation should come with a rationale tied to your specific requirements - not to what the developer already knows. If they cannot explain why Next.js over Nuxt, or why PostgreSQL over MongoDB, for your use case, they are recommending what is convenient for them, not optimal for you.

05

How will you handle third-party APIs, services, and licenses - and who pays for them?

Why this matters:

Payment gateways, maps, SMS, email services, and cloud infrastructure are costs that rarely appear in a quote. Ask for a complete list of every third-party service the project requires and who is responsible for procurement and ongoing costs.

Scope and Contract
06

What is explicitly included in your quote - and what is explicitly not included?

Why this matters:

Vague quotes are how agencies create change orders. Get a feature list - not a summary - in writing. If a feature is not listed, it is not included. Read the contract with this lens: assume everything not listed will cost extra.

07

How will you handle scope changes after we start?

Why this matters:

Every project has changes. The question is whether those changes will cost you 10% more or 50% more. A professional team has a written change order process with agreed rates per change. An unprofessional team has verbal agreements and surprise invoices.

08

What are the payment milestones and what exactly triggers each payment?

Why this matters:

Never pay more than 30–40% upfront. Structure payments around objective, verifiable milestones - "login flow live on staging," not "backend complete." Each payment should correspond to working, testable software you can see.

Ownership and IP
09

Do I own 100% of the code and intellectual property from day one?

Why this matters:

Some agencies retain IP ownership until final payment. Others build on frameworks they own and license to you. Get explicit written confirmation that all code, designs, and assets created for your project are your property. If they hesitate, walk away.

10

Will I have access to the code repository throughout the project?

Why this matters:

You should have read access to your GitHub or GitLab repository from day one - not just at handover. This lets you (or an independent developer) verify that work is progressing, check code quality, and protect yourself if the relationship breaks down.

Timeline and Delivery
11

What does your development process look like - how do you manage milestones and communicate progress?

Why this matters:

A professional team has weekly updates, a project management tool you have access to, and clear milestone definitions. "We will update you when things are ready" is not a process - it is a warning sign.

12

What happens if you miss a deadline? What is your escalation process?

Why this matters:

Most contracts have no consequences for missed deadlines. Ask what penalty or remediation applies if delivery slips more than two weeks. A team confident in their process will not object to reasonable penalty clauses.

Quality and Testing
13

Do you write automated tests for the code you deliver?

Why this matters:

Untested code is a ticking clock. Ask specifically about unit tests, integration tests, and end-to-end tests. Ask what percentage of code coverage they target. If they do not test, the code will break at scale and you will pay someone else to fix it.

14

What is your QA process before handover? Who does the testing?

Why this matters:

Developers testing their own code is not QA - it is optimism. Ask whether there is a dedicated QA step, whether testing is done by someone other than the developer who wrote the code, and what a bug found post-handover costs to fix.

Security and Data
15

How do you handle security - specifically authentication, data storage, and OWASP vulnerabilities?

Why this matters:

The most expensive mistakes in early-stage products are security mistakes that get discovered after you have users. Ask about OWASP Top 10, HTTPS enforcement, password hashing standards, and how user data is stored. If they do not know what OWASP is, that is your answer.

Launch and Beyond
16

What does the handover process look like at project end?

Why this matters:

A complete handover includes: source code, deployment credentials, environment variables, documentation, design files, and a walkthrough session. If handover is an afterthought, your new developer will spend weeks reverse-engineering what should have been documented.

17

What ongoing maintenance or support do you offer after launch, and at what cost?

Why this matters:

Every live product needs ongoing maintenance - security patches, dependency updates, bug fixes, and infrastructure monitoring. Know the post-launch support cost before you sign. Some agencies offer retainers; others charge per-request at rates that make the original project look cheap.

Red Flags to Watch For

7 signs you should walk away immediately.

These are not minor concerns. Each of these patterns, in isolation, has cost founders lakhs of rupees and months of wasted time. If you encounter more than two of these in a single conversation, disqualify the team.

No written contract or scope document

If a developer or agency is unwilling to put the scope, timeline, and deliverables in writing, they are protecting themselves at your expense. Never begin work without a signed contract.

Vague timeline ("2–3 months" with no phases)

A professional team can break any project into phases with defined milestones. "2–3 months" with no breakdown means they have not actually scoped the project - they are guessing, and you will absorb the variance.

Requires 50%+ payment upfront

Standard practice is 30–40% upfront at most, with remaining payments tied to milestones. High upfront requirements shift all the risk to you. Once they have the money, your leverage disappears.

Cannot explain their technology choices

If a developer recommends React but cannot explain why over Vue or Svelte for your specific use case, they are recommending what they already know - not what is best for you.

Will not give you repository access until handover

This is a significant red flag. If you cannot see the code being written, you cannot verify progress, quality, or that the project even exists in a usable state.

No QA process or testing mentioned

Developers who do not mention testing are not testing. Untested code shipped to production will have bugs - you will pay someone to fix them at post-launch rates.

Cannot provide references you can actually contact

Testimonials on their website are curated marketing. Real references are people you can call unannounced and ask hard questions. Any developer who cannot provide two live references should be disqualified.

What to Do Before Your First Developer Call

Walk in prepared. Walk out with leverage.

01

Generate your StackPick scope (free, 3 minutes)

Know your recommended tech stack, estimated cost range, phase-by-phase timeline, and key risk flags before you talk to anyone. This gives you a technical baseline to compare every developer's proposal against.

02

Share your scope with every developer you talk to

Send your StackPick scope link before the first call. Ask each developer to review it and respond with their own proposed approach. Developers who push back with specific, reasoned alternatives are the ones worth talking to.

03

Run every candidate through this checklist

Ask all 17 questions of every developer you are considering. Document the answers in writing - by email if possible, not just a call. The way a developer responds to structured questions tells you more about how they work than any portfolio.

04

Compare proposals using your scope as the baseline

With a StackPick scope in hand, you can compare developer proposals against a single reference point. Who is within the estimated range? Who is quoting 3x the estimate, and why? Who is proposing a different stack - and can they justify it?

Free Download

The MVP Budget Checklist

17 questions every non-technical founder must ask before paying a developer anything. Most founders learn these the hard way - after they've already signed a contract.

Preview - first 7 of 17:

  • 01.Can you show me a portfolio of similar projects you've built?
  • 02.What tech stack are you recommending - and why specifically for my project?
  • 03.Who exactly will be working on my project: employees or contractors?
  • 04.What does your handover process look like at the end?
  • 05.Do I own all the code and intellectual property?
  • 06.What's included in your quote and what is explicitly not included?
  • 07.Will I have access to the code repository throughout the project?
  • + 10 more questions covering testing, security, payments, support, and IP ownership...

No spam. No pitch decks. Unsubscribe anytime. We'll also send you the full scope after you run the quiz.

No signup required to use StackPick
Free scope generation, always
Your idea stays private

Ready to negotiate from a position of strength?

Get your complete technical scope - stack, architecture, cost, timeline - in 3 minutes. Free. Then walk into your developer conversations knowing exactly what you should be getting and what it should cost.

Run my free scope →

No signup. No credit card. No sales call.