If you cannot evaluate the code, you have to evaluate the partner. The good news: most of the signals that predict a successful build are non-technical, and you can read them in two or three conversations and a short paid trial.
Before you talk to anyone
Write a one-page brief. It should cover who the user is, the one problem you are solving, what success looks like in numbers you can measure, your budget range, your deadline and why it exists, and what you already have — designs, a prototype, data, a waiting list. Partners give better answers to a clear brief, and you can only compare proposals if they are answering the same question.
Also decide what you are buying. An MVP to test demand is a different project from a production platform you expect to scale. Say which one you want; a good partner will tell you if your brief actually describes the other.
What to look for
- They push back on your brief. A partner who says yes to everything is a vendor, not a partner. The best teams challenge scope and propose a smaller first version.
- Shipped work, not logos. Ask what they shipped, what it cost, what broke and what they would do differently. Ask to use a live product they built and, if possible, speak to a past client.
- A written scope and a demo cadence. You should see working software every week or two, on a real device or URL, not a big reveal at the end.
- Clear ownership and handover terms. Who holds the code repository, the cloud accounts and the domain? When does the code become yours? A good partner makes itself replaceable on paper — that is how you know you are not locked in.
- A named team. Know who will actually build your product, how much of their time you get, and what happens if someone leaves.
Red flags
- The lowest rate, with no questions asked about your users or business.
- A fixed price for a vague scope. Either the scope will be read narrowly or the price will change later.
- No testing or evaluation plan — especially for AI features, where "it worked in the demo" means little.
- Vague timelines ("about three months") with no milestones.
- Nobody willing to tell you no.
The cheapest quote is frequently the most expensive outcome once you count rework, delay and a second partner fixing the first one's code.
Questions that reveal the truth
| Ask | A good answer sounds like | Warning sign |
|---|---|---|
| "What would you cut from my MVP and why?" | Names specific features and ties each cut to what you need to learn | "We can do all of it" |
| "How will I know it works?" | Acceptance criteria, a test plan, a demo schedule, analytics | "You'll see it at launch" |
| "What happens to the code if we part ways?" | Repository access, documentation, a handover period | Hesitation, or an extra fee to release it |
| "Who is on my project?" | Named people with a stated time allocation | "Our team" |
| "How do you handle scope changes?" | A written change process showing cost and time impact | "We're flexible", with nothing written |
The answers tell you more than any portfolio. Our buy-vs-build framework helps you decide what needs building at all, and the AI MVP cost guide gives you a reference point for budget conversations.
Run a paid trial before the big commitment
Instead of signing a six-month contract on the strength of a pitch, commission a short paid discovery phase: two to four weeks that produce a clickable prototype, a technical plan and a costed backlog. You learn how the team communicates, whether they hit small deadlines and whether their estimates hold up. If it goes badly, you have lost weeks rather than months, and you keep the outputs.
Protect yourself without a technical co-founder
- Create the code hosting account, cloud account, domain and app store accounts in your company's name, then invite the partner in.
- Ask for a short written update every week: what shipped, what is next, what is blocked.
- Pay an independent senior engineer for a few hours to review the proposal and, later, a sample of the code. It is cheap insurance.
- Tie payments to milestones you can see working, not to calendar dates.
- Keep a simple decision log so you remember why scope changed.
A simple scoring method
After your calls, score each partner from 1 to 5 on understanding of your users, willingness to challenge scope, quality of past work, clarity of process, communication and commercial terms. Weight the first two more heavily. Say two partners land close together: pick the one whose team you would rather be in a room with when something goes wrong — because at some point it will.
FAQ
Should I hire a freelancer or a company?
A single freelancer can be excellent for a small, well-defined build, but you carry the risk if they become unavailable. A company costs more per hour and should give you continuity, QA and project management in return. Check that it actually does.
Do I need a technical co-founder before I start?
No, but you need someone you trust to judge technical decisions. That can be an adviser, a fractional CTO or a paid reviewer.
How Velura Labs partners with founders
We start by scoping hard — an AI Strategy & Roadmap session often shrinks the first build — then deliver with web, mobile and product design on a fixed, transparent plan with regular demos. Bespoke code is yours on full payment.
Our clients for this span US tech hubs (San Francisco, Seattle, Austin, New York), European markets (Paris, Milan, Rome), the Middle East (Dubai, Riyadh, Abu Dhabi) and India. Start a conversation from anywhere.