Amine
5+ years software engineer
5+ years software engineer
5+ years software engineer
5+ years software engineer
5+ years software engineer
Read a proposal for what it excludes, not what it includes. Inclusions are marketing — everybody lists them. Exclusions, assumptions, and change processes are where a proposal reveals whether anyone actually thought about your project.
The clarity of a proposal predicts the clarity of the project. I've never seen that correlation fail in either direction. Part of how to hire a developer for your MVP.
Nobody can scope a project properly in twenty minutes. A number produced that fast is either padded heavily to cover the unknowns, or it's about to become a series of change requests.
The honest version is a range plus a paid discovery phase, or a fixed price with explicitly stated assumptions.
If the proposal only says what's included, you have no idea where its edges are. Every gap becomes a negotiation later, at a moment when you're committed and they know it.
A serious proposal names what's not in the build: design revisions beyond a set number, content, third-party subscriptions, app store fees, post-launch support, hosting costs.
Every estimate rests on assumptions — that the payment provider has a working sandbox, that you'll supply content, that the API you mentioned is documented. Writing them down is how a developer tells you what would change the price.
Unwritten assumptions don't disappear. They resurface as "well, we assumed…" in week five.
"We're flexible, just let us know" is not a process. It means changes get absorbed into the schedule invisibly until the schedule breaks.
You want: changes are estimated, and you decide to add time, remove something else, or defer. Ten minutes of process that converts a silent leak into a visible decision.
Unreasonable, and it removes every incentive that keeps a project moving. Milestone payments tied to reviewable deliverables are standard.
The reverse is also a flag: a developer agreeing to be paid entirely on completion is agreeing to carry all the risk, which good ones won't. If someone accepts that, ask why they need the work that badly.
Nothing is all easy. This usually means they haven't thought about the edge cases, or they have and they're not mentioning them.
Payments, file uploads, notifications, and permissions are the four that are always more work than they sound. A developer who waves all four through hasn't built them recently.
If the entire conversation was about features and technology and nobody asked who this is for or what problem it solves, you're hiring a pair of hands, not a partner.
The strongest developers ask about the problem before the solution, and they try to build less as a result.
The subtle one, and the one that looks like great service.
Most MVPs fail from being too big. A developer who has watched that happen pushes back on your scope before they've been paid anything. Enthusiastic agreement with your entire wish list means you're getting exactly what you asked for — including the parts you shouldn't have asked for.
Good partners say "I wouldn't build that yet." That's not obstruction; it's someone protecting your budget rather than maximising the project. Scoping is the conversation where this shows up.
You don't need to grade the answer. You need to know they can explain their reasoning without hiding behind jargon.
Someone who can't translate their thinking into plain English will be difficult to work with for months. Jargon as an answer is usually jargon as a shield.
Screenshots prove nothing. Ask for URLs you can open, sign up for, and use.
Related: on team projects, ask which parts they personally built. "We built this" can mean they attended standups.
Some client work genuinely can't be shown. All of it, from everyone, always? That's a pattern, not a coincidence.
Someone with nothing showable can still explain a past project's problem, approach, and outcome in detail. If they can't do that either, there's nothing to evaluate.
Written testimonials are unverifiable. Two founders willing to take a call are.
Hesitation here is itself the finding. It doesn't have to be disqualifying for someone genuinely early in their career — but it should change how much you're willing to commit upfront.
This is the one I'd walk away over.
Your repository, cloud accounts, domain, and third-party services should be created under your company from day one, with the developer added as a collaborator. A developer who prefers it the other way round is describing how the relationship ends.
"We host it for you" and "we'll transfer it at the end" are variants of the same thing. Transfers get forgotten, contested, or become impossible when someone stops replying. Who owns the source code has the detail.
If the proposal doesn't say what you receive at the end, ask. The answer should be a concrete list: repo with commit history, deploy instructions, documented environment variables, database schema and migrations, design files, credentials.
"We'll send you the files" is not a handover. The handover checklist is what a real one looks like.
That last item is the tell. A proposal that suggests doing less than you asked for is written by someone who wants the project to succeed more than they want it to be big.
A quote that's higher than the others is not, by itself, a warning sign. A $15,000 build that validates your idea is cheaper than a $7,000 build that has to be redone — and the underpriced version usually gets delivered as something that demos but can't be extended.
If the cheapest quote is dramatically lower, ask that candidate what they're assuming that the others aren't. Sometimes they've found a simpler path. Sometimes they haven't read the spec. The answer tells you which, and it's a better use of the conversation than negotiating the price down.
If you want a proposal read by someone who isn't bidding on it, get in touch.
Four different products, not four prices for the same thing. What each option is actually good at, how each one fails, what an agency's overhead buys you, and where offshore genuinely fits.
Sixteen items, and how to verify each one without being able to read code. The test that proves a handover is real — and why commit history matters more than founders expect.
Shortlisting, comparing proposals, spotting the agency that sells with seniors and delivers with juniors, and getting ownership in writing — the full hiring process, written from the side that receives the brief.