TL;DR: Most non-technical founders pick a build approach (no-code, freelancer, agency, AI tool, hybrid platform) before they've defined what "done" looks like. The result is rebuilds, rewrites, and bills nobody planned for. This post gives you ten questions to ask yourself — and any vendor — before you commit to a build path. Use it as a checklist on your next call.
If you're a non-technical founder about to build your first web app, the riskiest moment isn't the code. It's the conversation you have before the code. The decisions you make in that conversation — scope, ownership, hosting, what happens when something breaks at 2am — quietly determine whether you're shipping a product or buying a future rewrite.
You don't need to become a developer to make this decision well. You need a checklist. Here it is.
1. Who owns the code, and where does it live?
The first question, always. If your answer is "I'm not sure" or "the platform owns it," stop and resolve that before anything else.
What to ask:
- Will I get a Git repository I own? (Ideally on GitHub, GitLab, or Bitbucket under your account.)
- Can I export everything if I leave?
- Are there any platform-locked components I can't take with me?
No-code platforms often own the runtime — meaning even if you can export "your data," you can't take the workflows, the UI, or the logic. That's a real choice with real trade-offs, but it has to be a choice you made consciously.
2. What's the realistic timeline, broken into milestones?
"Six weeks" is not a timeline. "Auth and onboarding by week 2, Stripe integration by week 4, beta launch by week 6" is a timeline.
What to ask:
- What are the weekly or bi-weekly milestones?
- What's the demo cadence? (You should see something working at least every two weeks.)
- What happens if a milestone slips — who flags it, and how early?
If a vendor can't break the project into milestones with concrete deliverables, they haven't planned the project. They're estimating.
3. How will payments and authentication actually work?
These are the two highest-risk parts of almost every web app. They're also where AI tools and inexperienced developers introduce subtle, expensive bugs.
What to ask:
- Are we using Stripe (or another battle-tested provider)? If something custom — why?
- How are we handling password resets, email verification, session timeouts, and account recovery?
- What happens if a Stripe webhook fails or fires twice? (The correct answer involves the word "idempotent.")
If you don't get specific answers — or if the answer is "the AI handles it" — that's the warning sign.
4. What's actually in scope, and what's "phase 2"?
The biggest source of project pain isn't the work that gets done. It's the work everyone assumed was included.
What to ask:
- Can I see a written feature list with every screen, every user role, every integration?
- For each item, is it phase 1 (in scope, in budget) or phase 2 (later)?
- What's explicitly out of scope?
A mature vendor or platform will have this list. If it's verbal, write it down yourself before you sign anything. The Joel Test is from 2000 and still useful — its core idea, that having explicit specs matters, is even more true now.
5. Where will the app run, and what does that cost monthly?
Hosting feels boring until it shows up as a $400/month surprise.
What to ask:
- What hosting provider — Vercel, AWS, Render, Fly, something else?
- What's the expected monthly cost at launch, at 100 users, at 1,000 users?
- What database, and what's its monthly cost?
- Are there third-party services (email, file storage, search) with their own bills?
A reasonable answer for a small SaaS in 2026 is something like: $0–$30/month at launch, $50–$200/month at 1,000 users. If you're hearing $500+/month before any users exist, ask why.
6. How will I know when something breaks?
Apps break. The only question is whether you find out from your monitoring or from an angry customer email.
What to ask:
- Is Sentry (or equivalent error tracking) wired up from day one?
- Are there uptime checks? Where do alerts go?
- How are logs stored, and for how long?
- If a payment fails silently, how would I find out?
"We'll add monitoring later" is the answer that costs you your first ten paying customers.
7. Who fixes it when something breaks?
Related but different. Monitoring tells you something's wrong. Someone has to actually fix it.
What to ask:
- After launch, who's on the hook for bug fixes?
- Is post-launch support included, hourly, or a separate retainer?
- What's the response time for a critical bug — hours, days, or "next sprint"?
- If my freelancer or agency disappears, what's my Plan B?
Bus factor of one is a real risk. If your entire post-launch support is one person's part-time attention, your app's reliability is one family emergency away from a problem.
8. Can the app evolve, or am I locked into the first version?
Every successful product looks different at month twelve than it did at launch. Your build approach has to support that.
What to ask:
- If I want to add a feature in six months, what's the realistic cost and timeline?
- If I outgrow the platform/vendor, what's the migration path?
- Is there technical debt being accepted now that I'll pay for later? (A good answer names specific trade-offs. A bad answer denies the existence of trade-offs.)
- Are dependencies kept up to date, or am I getting a snapshot of "best practices" as of today?
Approaches like a hybrid AI + human app-building platform are popular partly because they aim to give you a real codebase you can extend later — but the same principle applies whether you're hiring an agency, a freelancer, or using a no-code tool. Always ask: what does month twelve look like?
9. What does the day-to-day actually look like for me?
The non-technical founder's most expensive resource is their own time. If your build approach requires you to translate, manage, and re-explain constantly, the price isn't just the invoice.
What to ask:
- How many hours per week do I need to spend on this?
- What's the communication channel — Slack, email, weekly calls?
- Do I get a project tracker I can see? (Linear, Jira, Notion, GitHub Projects.)
- If I'm busy for two weeks, does the project keep moving?
Some build approaches assume you're a full-time PM. Others assume you're hands-off. Neither is wrong, but you need to know which one you're signing up for.
10. What happens at the moment of first paying customer?
This is the question that surfaces gaps faster than any other. Walk through the actual sequence.
What to ask:
- A customer arrives at the landing page. What loads, how fast?
- They sign up. What email do they get? What does the verify flow look like?
- They pay. Where does the receipt come from? What happens if the card declines?
- They run into a bug. Where does the report go? Who responds?
- They want a refund. What's the process, and who handles it?
If your vendor or platform can't walk you through this end-to-end, the gaps in their answer are the gaps in your future product.
Common pitfalls
- Skipping the questions because the vendor seems professional. Polished sales does not mean polished delivery. Ask anyway.
- Optimizing for the lowest quote. A $5K build that requires $20K of fixes is not a $5K build.
- Believing demos. Every tool's marketing video shows the happy path. Ask to see a production app built end-to-end on the platform — with a real user count.
- Assuming AI tools handle the boring parts. Authentication, billing, error handling, and security are the boring parts. They're also where AI-only builds tend to fail. Make sure a human owns them.
- Not writing answers down. Verbal commitments evaporate. If it matters, it's in writing.
Quick checklist: print this and bring it to the call
| # | Question | What a good answer looks like |
|---|---|---|
| 1 | Who owns the code? | "You do, in your own Git repo." |
| 2 | What's the milestone breakdown? | A weekly or bi-weekly schedule with demos |
| 3 | How are auth and payments handled? | Stripe + battle-tested auth, with idempotent webhooks |
| 4 | What's in scope vs. phase 2? | A written, itemized list |
| 5 | What's monthly hosting cost? | A specific dollar range at three usage tiers |
| 6 | How will I know when it breaks? | Sentry + uptime monitoring + alert routing |
| 7 | Who fixes bugs post-launch? | Named person or team, response-time SLA |
| 8 | What's the path to add features later? | Real codebase, named migration paths |
| 9 | What's my time commitment? | Specific hours/week + communication cadence |
| 10 | Walk me through first paying customer? | End-to-end story with no gaps |
FAQ
Should I just hire an agency and let them handle this?
Agencies can be great if you have $50K+ and need a lot of hand-holding. They tend to be expensive for early-stage MVPs and can be slow to iterate post-launch. The questions in this post apply to agencies just as much as to any other approach — don't assume "agency" means "thorough."
Are AI coding tools good enough for a real product yet?
For prototypes and internal tools, yes. For customer-facing products with real money or sensitive data, AI tools alone usually need a human pass on the parts that matter most — auth, payments, security, deploys. The hybrid approaches that pair AI scaffolding with engineering review are increasingly common for exactly this reason.
What's the realistic budget for a year-one MVP today?
For a B2B SaaS or marketplace MVP with auth, billing, and a basic dashboard: roughly $10K–$25K with AI scaffolding plus targeted engineering, $30K–$80K with a traditional agency. Costs have come down significantly in the last 18 months as AI scaffolding has improved.
Do I need to learn to code to ask these questions well?
No. You need to be able to read the answers critically. If a vendor's response is vague, technical-sounding, or dodges the specifics, that's a signal regardless of your background. Trust your "this doesn't quite add up" instinct.
What if the vendor pushes back on these questions?
A good vendor will welcome them. A great vendor will have most of the answers ready before you ask. A vendor who pushes back — "we don't usually share that" or "trust the process" — is telling you something important about how the project will go.
Final thought
The non-technical founders who succeed on their first build aren't the ones who picked the perfect vendor or the perfect platform. They're the ones who walked into the conversation with a list and didn't sign anything until the answers were specific. None of these questions require technical knowledge. They require the discipline to keep asking until the answers are concrete.
Bring this checklist to your next call. Ask the questions. Write down the answers. The vendor or platform that handles it well is the one worth your money.
Top comments (1)
🙌 Helpful