What Are the Questions I Don’t Know to Ask? 

A Founder’s Guide to the Hidden Decisions in Your Software Build

Knowing what questions to ask your developer before building is one of the clearest advantages a founder can have, and most founders don’t have it because nobody told them what to ask. 

The quote covered the features, and maybe the scope document listed out the screens, but underneath every app, there’s an entire layer of decisions about where it lives, how users get in, how money moves, what gets tracked, and what happens when something goes wrong. 

These decisions get made one way or another, so the REAL question is whether you made them, or whether they made themselves.

This guide covers the six categories founders most commonly miss. For each one, we’ll walk through what to ask, a tell-tale sign you may have a gap, and what it costs when nobody asks anything at all.

Hosting: Who Actually Owns Your App?

Hosting is where your application ‘physically’ lives, aka the servers that run your code, store your data, and serve your product to users. It sounds like infrastructure, which means most founders assume their developer is handling it, and to be clear, they almost always are. The question is whether they’re handling it in a way that works for your specific business, or in a way that’s simply easiest for them.

What to ask:

• Where will our application be hosted, and why did you choose that provider?
• What does our hosting cost at launch, and what does it cost when we have 1,000 users? 10,000?
• What happens if our server goes down at 2am on a weekend? Who is responsible, and how fast can they respond?
• Who owns the hosting account — us or you? What happens if we part ways?
• Is our database in the same region as our users? Does it need to be?
• How hard is it to move hosting later if we outgrow this setup?
• What’s our backup strategy, and how often do backups happen?
  

Tell-tale sign you have a gap:

• If you don’t know whose name is actually on your hosting, database, and domain accounts, you don’t fully own your product.

The consequences if you don’t ask:

Hosting decisions made by default often optimize for developer convenience, not founder interests. That can mean cloud configurations that are cheap to set up but expensive to scale, hosting accounts that live under your agency’s credentials rather than yours, and no clear plan for what happens when something breaks after business hours.

The account ownership question is particularly important. If your application, database, and domain are all registered under your development agency’s accounts, you don’t fully own your product. That’s a negotiating position you don’t want to be in, but there are ways to manage it!

Authentication: Are You Painting Yourself Into a Corner?

Authentication is how your users prove who they are when they log in. It sounds like a solved problem, but the decisions made within that solution have downstream consequences that aren’t always obvious up front.

What to ask:

• Are we building our own authentication system, or using a third-party service? Why?
• Will users be able to log in with Google or Apple? Does our target user expect that?
• How do we handle password resets and account recovery?
• If we need to add enterprise users later, can our auth system support SSO?
• How is user authentication data stored, and how is it protected?
• Do we plan to support MFA, and do our target customers expect it?
• What happens to user sessions if we change our auth provider down the road?

Tell-tale sign you have a gap:

• If your roadmap mentions “enterprise” and your scope doesn’t say “SSO” anywhere, you almost certainly have a risk.
  

The consequences if you don’t ask:

Authentication is one of the most expensive things to rebuild because it touches everything. If you build a custom auth system and later need to support SSO for an enterprise client, you might be looking at weeks of work at exactly the moment you can’t afford the distraction.

The enterprise SSO question tends to catch founders off guard. If your go-to-market includes selling to companies rather than individuals, those companies will almost certainly require SSO. Knowing that upfront means building for it, whereas finding out at the sales call means an unplanned development sprint.

Payments: Are You Building the Wrong Billing Model?

Payment infrastructure is more complex than it looks. Most founders know they need a payment processor, but haven’t thought through the full scope of what their payment flow needs to support.

What to ask:

• What payment processor are we using, and what are their fees?
• Does our product need to support recurring billing? Subscriptions? Usage-based pricing?
• How do we handle edge cases like failed payments, retries, proration, free trials, upgrades, and downgrades?
• What happens when a payment fails? Automatic retry, manual follow-up, account suspension?
• Can we support multiple currencies? Do we need to?
• How do we handle refunds and disputes?
• What does our checkout flow look like on mobile?
• Are we PCI compliant? What does that actually mean for our setup?

Tell-tale sign you have a gap:

• If your pricing model includes subscriptions but no one has mentioned dunning, failed payment handling, or renewal logic, you’re missing work that has to exist somewhere.

The consequences if you don’t ask:

A payment flow built for one-time transactions is a different architecture from one built for subscriptions. If you launch with one-time payments and later want to add a subscription tier, the rebuild is often larger than founders expect because the database schema, billing logic, failed-payment handling, and dunning process all need to be built from scratch.

PCI compliance is in its own category. If you’re handling card data in a way that requires compliance and you’re not (or you’re not sure) that’s a liability question your lawyer needs to weigh in on, not just your developer.

Analytics: Will You Have More Than Anecdotes?

Analytics tells you what’s actually happening in your product. Like, duh. It sounds optional until you realize you can’t make a meaningful decision about your roadmap without it.

What to ask:

• What analytics tools are we using, and what will we actually be able to see?
• Are we tracking user behavior inside the app, or just acquisition metrics?
• How do we know which features get used and which ones don’t?
• Can we segment users by cohort, e.g. new vs. returning, free vs. paid?
• What does our first-week user journey look like, and will we see where people drop off?
• How long does it take for data to become available, and how accurate is it?
• Are we collecting only the data we need, and does our analytics setup respect the privacy laws in our target markets?

Tell-tale sign you have a gap:

• If your analytics plan only mentions page views, signups, and basic funnels, but not whether users complete the core action or come back, you’re flying by vanity metrics.

The consequences if you don’t ask:

Most MVP analytics setups track the easy things: page views, signups, basic funnel steps. They don’t always track the things that tell you whether your product is actually working.

Without that, your first 90 days post-launch become guesswork. You’re making roadmap decisions based on anecdote, and in our experience, founders making good product decisions three months post-launch are the ones who set up behavioral analytics before they launched.

Support Infrastructure: Will Support Eat Your Calendar?

Support infrastructure is how your users get help when something goes wrong. Again, duh. It’s one of the last things founders think about before launch, which is why so many end up managing support from their personal inbox.

What to ask:

• Where will users go if they have a problem or a question?
• Do we need a help center, FAQ, or documentation before launch?
• How will we track and prioritize support requests?
• Who is responsible for responding, and what’s our expected response time?
• What tools do we need? Ticketing system, live chat, email routing?
• What happens if our product goes down? How do users find out, and how are they updated?
• In an incident, who is responsible for communication and what does our playbook look like?

Tell-tale sign you have a gap:

• If your current plan for support is “they’ll just email me,” you don’t have support infrastructure; you have an impending calendar problem.

The consequences if you don’t ask:

Support infrastructure gets built reactively in most early-stage products, which means when users can’t find answers, they email. When emails pile up, someone’s calendar fills with triage. When a founder is running support from their personal inbox, they stop doing everything else.

The status page question is underrated. When something breaks, and eventually something will, users don’t need every technical detail. They need to know you’re aware, you’re working on it, and they’ll be updated. A status page handles that automatically. Without one, the communication falls on whoever happens to be awake.

Compliance: Are You Building on Legal Quicksand?

Compliance is what keeps you on the right side of the laws governing how you collect, store, and use user data. Requirements vary based on where your users are, what kind of data you’re handling, and what industry you’re in.

What to ask:

• Do we need to comply with GDPR? CCPA? Both?
• What personal data are we collecting, and how long are we keeping it?
• Do we have a privacy policy that accurately describes how we handle data?
• If we’re in healthcare, finance, or legal, what additional requirements apply (HIPAA, PCI, SOC 2, others)?
• Are we accessible? Do we need to meet WCAG standards, and does the European Accessibility Act affect us if we have EU users?
• What’s our data deletion process if a user requests it?

Tell-tale sign you have a gap:

• If your sales deck mentions “enterprise” but you’ve never heard the phrase “security questionnaire” or “accessibility requirements” from a prospect, that conversation is coming, and you may not like the timing.

The consequences if you don’t ask:

Compliance gaps are one of the few things that can retroactively threaten a product that’s already working. GDPR fines are calculated as a percentage of revenue. HIPAA violations carry civil and criminal penalties. An enterprise client asking for your security questionnaire when you haven’t thought about compliance is a lost deal.

The accessibility question is increasingly relevant beyond just compliance. The European Accessibility Act now applies to new products in many EU contexts, and enterprise buyers check accessibility before they’ll demo your product in many procurement processes. Building for accessibility from the start is a design constraint. Adding it after is a rebuild.

How Do You Know If Your Scope Covers All of This?

The challenge with these questions is that most scopes are written around features, not infrastructure. A scope document that lists every screen and user story can still completely omit the hosting architecture, the auth strategy, the analytics plan, and the compliance requirements, and technically, it wouldn’t be wrong. It would just be incomplete.

Most founders don’t want to become technical product managers. They just want to know that when they sign a contract, the invisible decisions are being made on purpose, not by default. The work of figuring out what belongs in your scope and what decisions need to be made before development starts is what our Product Architecture Roadmap is designed for.

You walk away with an architecture brief your dev team can quote against, a set of explicit decisions you control, and a prioritized list of risks you’re choosing to accept or mitigate.

Founders who go through the Roadmap before development know what they asked for, and why. Founders who skip it tend to find out what they missed around week 8.

Talk with Amodhi today about our Product Architecture Roadmap

Frequently Asked Questions

How do I know if my current quote covers hosting and infrastructure?

Ask directly: “Does this quote include hosting setup, and what’s the estimated monthly hosting cost?” If the answer is vague or absent, it’s probably not included.

Is it too late to ask these questions if my build is already underway?

Not at all, though earlier is always better. Most of these questions are much easier to address at the architecture stage than after significant code has been written. If you’re mid-build and uncertain, a technical audit can tell you where you stand.

What if my developer gives me answers I don’t understand?

Ask them to translate to business terms. “What does that mean for our cost at scale?” “What does that mean if we want enterprise clients?” If they can’t explain the business implication, that’s useful information too.

Do I need to understand technical details to ask these questions?

No. These questions don’t require technical knowledge to ask. They require business judgment and understanding what outcomes matter to you and what risks you can’t afford.

What’s the difference between these infrastructure questions and my product scope?

Your product scope describes what users can do in your product. Infrastructure describes how the product actually works underneath. Both need to be decided. One of them shows up in most scope documents.

What if I need to change developers or agencies later?

That’s when these questions matter most. If your accounts, architecture decisions, and risk areas are documented and owned by you, switching vendors is an inconvenience. If they’re not, switching vendors can feel like starting over.