What Happens Before We Write Any Code: Our Client Onboarding & MVP Discovery Process
Most app projects don't fail because of bad code. They fail because nobody asked the right questions at the start.
At Etere Studio, we've learned this the hard way. The projects that go smoothly—shipped on time, on budget, with founders who actually use what we build—all share one thing: a thorough discovery process before anyone opens an IDE.
This is what that process looks like, step by step.
The First Call Isn't About Your App
When a founder reaches out, they usually want to talk features. Screens. Tech stack. We get it—you've been thinking about this for months.
But our first call focuses on something else entirely: your business.
We ask questions like:
- What problem are you solving, and for whom?
- How are people solving this problem today without your app?
- What does success look like in 6 months? (Not "a million users." Something measurable.)
- Why now? What's the urgency?
These aren't checkbox questions. The answers shape everything that comes after. If someone's solving the problem fine with a spreadsheet, maybe you don't need an app yet. If there's no urgency, maybe you're not ready to invest.
We've talked founders out of building apps. It happens. Better to figure that out in a 30-minute call than 3 months into development.
The Questions That Prevent Scope Creep
Scope creep kills projects. Not because clients are unreasonable—usually it's because the scope was never clear to begin with.
Our discovery process includes a feature prioritization exercise. It's simple but effective:
- List everything the app could do. Every feature you've imagined.
- Categorize each one: Must-have for launch, Nice-to-have, Future version.
- Challenge the must-haves: For each one, we ask "What happens if we launch without this?"
That last question is where the magic happens. Founders often realize that half their "must-haves" are actually "would-be-nice" features dressed up as essentials.
We had a client who wanted user profiles, social sharing, in-app messaging, and a recommendation algorithm. All "must-haves." After the exercise, we launched with none of those. Just the core value proposition: booking appointments. The app succeeded. Those other features came in version 2, informed by actual user behavior.
Red Flags We Watch For
Not every project is a good fit. We've learned to spot warning signs early:
"We need it by [impossible date]" — Urgency is fine. Impossible timelines mean cutting corners, and we don't do that. If someone needs an MVP in 3 weeks, we're probably not the right partner.
"Just build what I tell you" — We're not a code factory. If a client doesn't want our input on product decisions, we'll clash. Our best work happens when there's real collaboration.
"We'll figure out the details later" — Vagueness is expensive. If someone can't articulate what they're building, they're not ready to build it.
"Our competitor has X, so we need X" — Feature parity isn't a strategy. We push back on this. What makes you different?
Budget secrecy — We get that budgets are sensitive. But if someone won't give us a range, we can't tell them if we're a fit. Transparency goes both ways.
These aren't dealbreakers by themselves. But when we see several together, we have an honest conversation about whether we're the right team.
From First Call to First Commit: The Timeline
Founders always ask how long this takes. Here's our typical timeline:
Week 1: Discovery calls — Usually 2-3 calls. First is exploratory, second digs into specifics, third aligns on scope.
Week 2: Proposal and scope document — We write a detailed scope document. Not a generic template—a specific breakdown of what we'll build, what we won't, and why. This becomes the project bible.
Week 3: Refinement and sign-off — Back and forth on the scope. Questions, clarifications, small adjustments. By the end of this week, everyone's aligned.
Week 4: Project kickoff — Contracts signed, first sprint planned, first commit pushed.
So roughly 3-4 weeks from "Hey, I have an app idea" to actual development. Some clients think that's slow. We think it's insurance. Those 3 weeks prevent months of rework later.
What the Scope Document Actually Contains
Our scope documents aren't vague. Here's what goes in:
- User stories: Not features, but actual user actions. "As a [user], I can [action] so that [outcome]."
- Out of scope: Explicitly listed. This prevents "I thought that was included" conversations.
- Technical decisions: Why Flutter, what backend approach, any third-party services.
- Assumptions: Things we're assuming to be true. If they're not, scope changes.
- Risks: What could go wrong, and how we'll handle it.
- Timeline with milestones: Not just "done in 12 weeks" but what's delivered when.
We share this document in Google Docs. Clients can comment, ask questions, push back. By the time we sign off, there are no surprises hiding.
Why We Do This (Even When Clients Want to Skip It)
Sometimes founders are eager. They've got funding, a deadline, momentum. They want to skip discovery and start building.
We push back. Politely, but firmly.
Here's why: we've seen what happens when you skip this. The project starts fast, then stalls. Requirements change mid-sprint. "Oh, we need this now." Features get cut, then added back. Timelines slip. Budgets balloon. Everyone gets frustrated.
The discovery process isn't overhead. It's the foundation. At Etere Studio, we've found that investing 3-4 weeks upfront saves 3-4 months of chaos later.
And honestly? If a founder doesn't want to invest that time, they might not be ready to build. That's okay. We'd rather wait until they are.
Thinking about building an app and wondering if we're a good fit? We're happy to chat—no commitment, just a conversation. Get in touch