12 questions to answer before you build a custom app

The average custom app project starts with a Figma mockup or a feature list. It rarely starts with the questions that actually determine whether the project will succeed.

I've seen $200K software budgets disappear on products that nobody used after launch. Not because the code was bad - the code was fine. The problem was baked in before the first meeting: the real user was never interviewed, the integration requirements were discovered in week 10, or the person who commissioned the project didn't have the organizational authority to make staff actually use it.

These are not technical problems. They're planning problems. And they're all answerable before you spend a dollar on development.

Here are the 12 questions that catch them.

Problem validation (Questions 1-3)

These feel obvious. They're not. Skip them and everything downstream is built on assumptions.

1. What exact problem does this solve?

Not "we need an app." Not "we want to digitize our process." What specific friction is painful enough that people will change their behavior to fix it?

The test: can you describe the problem in one sentence without using the word "efficiency"? "Our sales team spends 3 hours per week manually copying data from email into our CRM, which causes 15-20 data entry errors per week and delays invoicing by 2-3 days" is a problem worth building for. "We want to improve our sales process efficiency" is not.

The more specific the problem, the smaller and cheaper the solution. Specificity is a money-saving exercise.

2. How often does this problem occur, and how much does it cost?

A problem that happens once a month is not a good candidate for a custom app. A problem that happens 200 times a day - and each occurrence costs 3 minutes of staff time or carries error risk - is.

Calculate the annual cost of the problem before you estimate the cost of the solution. If the problem costs $30K/year in staff time and errors, a $150K app that takes 5 years to pay back isn't a good investment. If the problem costs $500K/year, a $150K app pays back in 4 months.

Most teams can't answer this question. That should concern you. If you don't know what the problem costs, you can't make a rational investment decision.

3. Who experiences this problem, and have you actually talked to them?

"Our operations team" or "our customers" are not answers. Name two or three specific people who feel this pain today. Go talk to them - 30 minutes each. Ask them to walk you through their current process. Ask what they hate about it. Ask what they've tried to fix it. Ask what good would look like.

The things you discover in those conversations will change your feature list more than any whiteboarding session. Guaranteed.

If you've already talked to users and can summarize their 3 main complaints in plain language, you're ready to move forward. If you haven't, do this before anything else.

Build vs. buy (Questions 4-5)

The default assumption in most organizations is "build." The honest answer is often "buy."

4. Does existing software already solve this?

Before scoping a custom build, spend 2 hours in the market. Search "[your problem] software" and "[your industry] software." Try the top 3 free trials.

If a tool like Zapier, Airtable, HubSpot, Notion, or a vertical SaaS product does 80% of what you need at $500-$2,000/month, the question becomes: is that remaining 20% worth $100K-$300K to build?

Often the answer is no. The 20% gap is usually an edge case or a nice-to-have. You can often work around it with a small process change, not a custom build.

If the answer is genuinely yes - the 20% gap is a core workflow, a competitive differentiator, or a compliance requirement - then you've justified the build. But you've answered the question with evidence, not instinct.

5. Is this a core differentiator or a supporting function?

Here's the framework: if you described this software to a prospect and they said "that's why I'd choose you over a competitor," it's a differentiator. Build it.

If you described it to a prospect and they said "sure, I'd expect any vendor to handle that," it's a supporting function. Buy it (or use a commodity tool).

Customer-facing AI features, proprietary data processing pipelines, custom matching algorithms, industry-specific workflows - these are differentiators. Accounting, HR management, basic CRM, email marketing - these are not.

The rule: don't build commodity software. Your competitors have the same commodity problems and they've already found tools that solve them. Your differentiation should come from what you build, not from reinventing tools that already exist.

MVP scope (Questions 6-8)

Scope creep is the most predictable cause of delayed, over-budget projects. These questions create a shared definition of "done" before you start.

6. What is the smallest version that solves the core problem?

An MVP is not a version 1.0 with some features removed. It's a different kind of product - one whose purpose is to test whether you've correctly understood the problem.

A good MVP test: list every feature in your current brief. Now cross out anything that isn't required for the core user journey to work end-to-end. What's left is your MVP.

Most teams resist this because stakeholders equate "launch" with "complete." Change the framing: the MVP isn't what you're proud to launch. It's what you launch to learn enough to build what you're proud of. Airbnb launched with no instant booking. Instagram launched with no DMs. Amazon launched with books only.

What's your books-only version?

7. Who is the primary user of this MVP?

"Everyone" is not an answer. "Our warehouse managers" is an answer. "Our sales ops team" is an answer.

Pick one user type for the MVP. Build for them exclusively. Build the most important workflows for that user type perfectly, then expand.

Building for multiple user types at once multiplies scope. A marketplace with two user types is not twice the work - it's three times the work (user type A, user type B, and the interaction between them). Sequence the builds.

8. What features are explicitly out of scope for the MVP?

Write a "not building" list. This isn't defeatism - it's project management.

"Phase 1 scope: booking flow, availability calendar, payment processing, email confirmation. Not in scope: in-app messaging, reviews, mobile app, multi-language support."

The "not building" list protects you when stakeholders inevitably want to add features during development. You don't have a conversation about whether to add the feature - you have a conversation about whether to move it from "Phase 2" to "Phase 1" and what that does to the timeline and budget.

Team and success (Questions 9-12)

These questions determine whether the app is useful six months after launch - or dead.

9. Who owns and maintains this after launch?

Apps don't maintain themselves. After launch, someone needs to:

• Monitor for bugs and fix them
• Update dependencies and security patches
• Add features as the business evolves
• Train new staff on the system
• Handle integrations when third-party systems change

If the answer is "the agency that built it," that's a vendor dependency, not a plan. If the answer is "we'll figure it out," that's how you end up with a $100K app that runs on a 5-year-old dependency nobody can update because the original developer is unreachable.

Name a specific person internally who will own this product. If no such person exists, either hire one or scope the project for maintainability (off-the-shelf platforms, well-documented code, minimal custom infrastructure).

10. What does success look like in 90 days?

Not "users find it useful." Not "it works." A specific, measurable outcome.

"90 days after launch: 100% of our warehouse team is creating pick tickets in the app instead of on paper" is measurable. "The app is processing 500 orders per week with fewer than 2 data entry errors per day" is measurable. "We've reduced invoice processing time from 4 days to same-day for 80% of invoices" is measurable.

If you can't name a 90-day success metric, you don't have enough clarity on the problem to start building.

Success metrics also give you a decision trigger: if you're at 90 days and you haven't hit the metric, you need to know why and whether to continue investing. Without a metric, you have no decision point - you just keep spending.

11. What data will this collect, and who owns it?

This question becomes critical the moment you consider changing vendors, moving to a different platform, or if the vendor relationship ends.

Before you sign, confirm:

• Can you export all your data at any time, in a machine-readable format?
• What happens to your data if you cancel the service?
• Who owns the data - you or the vendor?
• Where is the data stored (US, EU, specific region requirements)?

For sensitive industries - healthcare (HIPAA), finance (SOX, PCI DSS), legal (attorney-client privilege), education (FERPA) - data residency and ownership aren't just contract terms, they're regulatory requirements. See our data compliance guide for specifics by industry.

12. What happens if this doesn't work?

This sounds defeatist. It's not. It's the most practical question on this list.

If the app launches and adoption is low, what's the exit plan? If the vendor shuts down, how do you get your data out? If the development partner disappears mid-project, do you own the code?

Answers to look for:

• Code ownership: You should own the code repository and all IP from day one
• Data portability: Full data export available at any time, documented format
• Escrow: For mission-critical projects, source code escrow (a third party holds the code, releases it if the vendor defaults)
• Pilot before commit: If possible, start with a pilot project or a 12-week fixed-scope engagement before committing to a long-term contract

The reason most development projects don't have an exit plan is that everyone assumes success. Budget for failure and you'll spend a lot less on it.

Using this checklist in practice

These 12 questions fit into a 2-hour working session with your decision-making team. Have the person who identified the problem present. Have a technical stakeholder (or your development partner) present. Work through each question out loud and document the answers.

If you can't answer questions 1-3 with confidence, you're not ready to scope the technical solution. Do user interviews first.

If you can't answer questions 6-8, do a half-day scope workshop with your development partner to define the MVP explicitly before signing anything.

If you can't answer questions 9-12, you're planning to build something you're not planning to own. Reconsider the investment.

For a starting point on real cost ranges, see our custom software development cost guide and MVP development cost breakdown. For the build vs. buy question as it applies specifically to AI features, see build vs. buy AI.

If you've worked through these questions and are ready to talk scope, our team at 1Raft gives you a real number in one call. No surprises, no hourly billing.