Before You Talk to Any Agency
You have a product vision but not the technical skills to build it yourself. You're about to spend €50K or more on a development agency. And you have no reliable way to evaluate whether they're doing good work or slowly burning your runway.
This is one of the most vulnerable positions a founder can be in.
After 100+ product launches, we've worked with dozens of non-technical founders. Some came to us first. Others came after a failed engagement elsewhere. The difference between these groups usually wasn't luck --- it was preparation.
This guide covers everything you need to know to work effectively with a dev agency, even if you can't read a line of code.
Know What You're Actually Building
This sounds obvious, but most founders skip this step. They have an idea, maybe some sketches, and they want to "talk to a few agencies to figure out scope."
That's backwards.
Before your first agency call, you should be able to answer:
The core question: What is the single most important thing your app does? Not the five things. The one thing. If a user only does one thing in your app, what is it?
The user question: Who are your first 100 users? Not your total addressable market. The actual humans who will download version 1.0. Where do they hang out? How will you reach them?
The success question: What does success look like in six months? Be specific. "Traction" isn't an answer. "500 paying users at €10/month" is an answer.
The constraints question: What's your budget? What's your deadline? Are there compliance requirements (health data, financial services, specific markets)?
You don't need a 50-page PRD. But you need clarity on these four questions. Agencies can help you refine scope, but they can't define your vision for you. The ones who try are usually just telling you what's easiest to build.
Understand What You're Buying
Development agencies sell three things:
Time: Hours of work from developers, designers, and project managers. This is the commodity part. Every agency sells time.
Expertise: Knowledge about what to build and how to build it. This is what separates a strategic partner from a code shop. You're paying for their experience on 100+ projects so you don't repeat mistakes others have made.
Risk reduction: The difference between a junior team and a senior team isn't just speed. It's the likelihood that your project ships on time, works correctly, and can be maintained after launch.
When you evaluate agencies, you're really asking: How much expertise and risk reduction am I getting for this price?
How to Evaluate Agencies
You can't evaluate code quality directly. But you can evaluate the signals that correlate with quality.
Ask About Their Process
A professional agency can explain exactly how they work. Not vague references to "agile" or "sprints," but a concrete answer to: "What happens in week one? Week four? Week eight?"
If they can't walk you through their process in detail, they don't have one. They're making it up as they go.
What to listen for:
Clear phases with specific deliverables at each stage
Regular touchpoints where you see working software (not just slide decks)
A discovery phase before they quote you a price
An explanation of how they handle scope changes
Red flag: They give you a price before understanding your project in depth. Any agency quoting a fixed price after a single call is either padding the estimate heavily or planning to cut corners.
Ask Who Will Actually Work on Your Project
The senior architect you meet in the sales process might not be the person writing your code. This is the classic "bait and switch."
Ask directly: "Will the people in this room be working on my project day-to-day? If not, who will, and can I meet them?"
What to listen for:
Straight answers about team composition
Willingness to introduce you to the actual developers
Senior involvement throughout the project, not just at kickoff
Red flag: Vague answers about "assigning the right team" or "matching resources to your needs." That's agency-speak for "we'll figure it out later."
Ask How They Handle Communication
You're going to have questions. You're going to want updates. How that works matters more than you think.
Questions to ask:
How will we communicate day-to-day? (Slack? Email? Something else?)
How often will I see working builds of my app?
Who is my main point of contact? What's their response time?
What happens if I have an urgent question at 3pm on a Tuesday?
What to listen for:
Direct access to the team, not just a project manager gatekeeper
Regular demos of working software (weekly is standard)
Clear expectations about response times
Red flag: Communication only flows through a single project manager who "shields" the developers from client contact. This creates telephone games and slows everything down.
Ask What Happens When Things Go Wrong
Because things will go wrong. Features take longer than expected. Requirements change. Edge cases emerge. What matters is how the agency handles it.
Questions to ask:
What happens if a feature takes longer than estimated?
How do you handle scope changes mid-project?
Can you tell me about a project that didn't go as planned and how you handled it?
What to listen for:
Honest acknowledgment that surprises happen
A clear process for handling changes (not just "we'll figure it out")
Willingness to discuss past difficulties openly
Red flag: Claims that their process is so good that nothing ever goes wrong. That's not confidence. That's either inexperience or dishonesty.
Check References Properly
Every agency will give you their happiest clients as references. That's fine. But ask the right questions:
Questions for references:
Was there ever a point where you were frustrated with the agency? How did they handle it?
Did the final cost match the original estimate? If not, why?
Would you use them again? Why or why not?
What would you do differently in how you worked with them?
The answers to these questions reveal more than "were they good?" ever will.
Working Effectively During the Project
Your Job as the Non-Technical Founder
You're not going to be reviewing code. But you have responsibilities that directly impact project success.
✦ Be available. The biggest delays in agency projects come from slow client feedback. When they send you a build to review or a question to answer, respond within 24 hours. Ideally faster.
✦ Make decisions. You'll face tradeoffs constantly. "We can include this feature, but it adds two weeks." "These two approaches both work, but one is faster and one is more flexible." Make decisions quickly and live with them. Revisiting decisions repeatedly kills projects.
✦ Trust the process, but verify. You hired experts. Let them do their job. But also stay engaged. Review every build. Ask questions when something doesn't feel right. "I'm not technical, but can you explain why this works this way?" is always a valid question.
✦ Protect scope. You will have new ideas during development. Write them down for version 2. Every feature you add to version 1 pushes back your launch date and increases your risk. The MVP discipline exists for a reason.
What to Expect at Each Phase
Understanding the rhythm of a project helps you know when to engage and what to look for.
✦ Discovery (typically weeks 1-2):
You'll be heavily involved. Lots of calls, lots of questions about your business. This is when the agency learns your vision and translates it into a buildable plan.
Your job: Be available and be honest about constraints. If your budget is €50K, don't pretend it's €100K. If you need to launch before a funding deadline, say so.
✦ Design (typically weeks 3-4):
You'll see wireframes, then high-fidelity mockups, then an interactive prototype. This is when your app becomes real for the first time.
Your job: Give detailed feedback early. Changing a design takes hours. Changing built code takes days or weeks. If something feels wrong in the prototype, say so now.
✦ Development (typically weeks 5-10):
You'll see working builds regularly, typically weekly. Early builds will be rough. That's normal. Features get polished over time.
Your job: Test every build. Not just "does it look right?" but "does it feel right to use?" Try to break things. The bugs you find now are the bugs that won't embarrass you at launch.
✦ QA and Launch (typically weeks 11-12):
The team is hunting bugs, optimizing performance, and preparing for the App Store submission.
Your job: Prepare your marketing, your support channels, and your user onboarding. The agency builds the product; you launch the business.
How to Give Feedback That Actually Helps
Bad feedback: "I don't like the homepage."
Good feedback: "The homepage feels cluttered. I'm not sure where to look first. The main action I want users to take is signing up, but the signup button doesn't stand out."
The difference is specificity. You don't need to propose solutions (that's what you're paying the agency for), but you do need to clearly articulate the problem.
A useful framework:
What did you expect to happen?
What actually happened?
Why is that a problem?
This applies to design feedback, bug reports, and feature discussions. The more specific you are, the faster the team can respond.
The Questions You Should Ask
Non-technical founders often hesitate to ask "dumb" questions. Don't.
"Can you explain this in plain English?" If a developer can't explain a technical decision without jargon, they either don't understand it themselves or they're hiding something. Either way, keep asking until you understand.
"What are we sacrificing to hit this deadline?" There are always tradeoffs. Knowing what they are helps you make informed decisions. Maybe the tradeoff is acceptable. Maybe it isn't. But you should know.
"What would you do differently if we had more time/budget?" This reveals how the agency is prioritizing. It also surfaces options you might not have known existed.
"What's the riskiest part of this project?" Every project has risk. A good agency knows where the risks are and has plans to mitigate them. If they claim there's no risk, they haven't thought hard enough.
"How will I maintain this after launch?" At some point, the initial build ends. What happens next? Can you hire a developer to maintain the code? Will the agency support you? What does that cost?
Protecting Yourself
Ownership and IP
This should be non-negotiable: you own the code, designs, and all intellectual property produced for your project.
Verify this is in your contract. Don't assume. Some agencies retain partial ownership or license their code to you (meaning they can use it for other projects). You want a clear "work for hire" clause that assigns all IP to you.
Get the source code. At the end of the project, you should receive the complete source code, design files, and documentation. Not just access to a hosted version, but the actual files.
Ensure it's documented. Code without documentation is a trap. The next developer who works on your project (whether internal or another agency) needs to understand how it works.
Budget Protection
Fixed price vs. time and materials:
Fixed price means you know exactly what you'll pay. The agency bears the risk of estimation errors. This works well for well-defined projects with clear scope.
Time and materials means you pay for hours worked. You bear the risk of estimation errors, but you also have more flexibility to change direction. This works well for projects with evolving requirements.
Neither is inherently better. What matters is understanding which model you're agreeing to and what risks you're accepting.
Change order process:
Scope will change. Features will be added. What happens when it does?
A good agency will document every scope change, explain the cost and timeline impact, and get your approval before proceeding. This protects both of you.
Payment milestones:
Don't pay 100% upfront. A typical structure is 30% at kickoff, 30% at design approval, 30% at development completion, and 10% at launch. This keeps incentives aligned.
The Most Important Protection: Choosing the Right Partner
Contracts matter. But the best protection is choosing an agency that doesn't need to be protected against.
Look for:
Transparency: They tell you the hard truths, not just what you want to hear.
Ownership: They care about your product's success, not just delivering to spec.
Communication: You always know what's happening and why.
Experience: They've done this before, enough times to know where problems hide.
A good agency will push back on your bad ideas, flag risks before they become problems, and treat your budget like it's their own. That's what partnership actually means.
After Launch
The MVP is live. Now what?
The First 30 Days
The period immediately after launch is when you learn whether your assumptions were right. Pay attention to:
What features do users actually use? (Probably not what you expected.)
Where do users get stuck? (This is where you focus improvements.)
What do users ask for? (This informs your roadmap.)
Share this data with your agency. If you're continuing to work together, this shapes what you build next. If you're transitioning to an internal team, this context is invaluable.
Ongoing Development
You have three options:
Continue with the agency: Typically a retainer model with a set number of hours per week or month. Good for maintaining momentum and consistency.
Transition to an internal team: Use the documentation to onboard your own developers. The agency may offer a transition period to transfer knowledge.
Hybrid approach: Use an internal team for day-to-day maintenance and bring in the agency for larger features or specialized work.
There's no right answer. It depends on your funding, your growth trajectory, and your ability to recruit technical talent.
The Bottom Line
Working with a dev agency as a non-technical founder isn't about becoming technical. It's about knowing what questions to ask, what signals to watch for, and how to contribute effectively without writing code.
The founders who succeed with agencies share a few traits:
They come prepared with clear vision and constraints
They stay engaged without micromanaging
They make decisions quickly and protect scope ruthlessly
They treat the relationship as a partnership, not a vendor transaction
The agency's job is to build your product. Your job is to build your business. When both sides do their job well, the result is a product that ships on time, works correctly, and gives your startup the foundation it needs to grow.
✦ ✦ ✦
Ready to Start?
If you're a non-technical founder with a product vision, we'd like to hear about it. 25 minutes to understand your idea and give you an honest assessment: what's realistic, what it might cost, and whether we're the right fit.
