What I Look For Before Taking On a Client Project

When I started freelancing, I said yes to almost everything. Someone needed a website? Sure. A mobile app with no clear requirements? Let’s do it. A project with a budget that barely covered the hosting costs? I’ll make it work.

That approach taught me a lot, mostly about what not to do. These days, I’m selective about the projects I take on. Not because I’m too good for anything, but because saying yes to the wrong project means doing a bad job for the client and burning myself out in the process.

Here’s what I evaluate before committing.

Clear Scope

This is the single most important factor. If a client can’t articulate what they want built — even roughly — that’s a red flag. I don’t need a pixel-perfect spec, but I need enough clarity to scope the work and give a realistic quote.

“I need a web app that lets my customers place orders and my staff manage inventory” is a workable starting point. “I need an app, it should do everything” is not.

When the scope is fuzzy, I’ll suggest a paid discovery phase to define it. If the client isn’t willing to invest in that, we’re probably not a good fit.

Realistic Timeline

“Can you build this in two weeks?” depends entirely on what “this” is. I’ve delivered functional MVPs in two weeks. I’ve also had projects that genuinely needed three months.

The red flag isn’t a tight timeline — it’s a timeline that doesn’t match the scope. If someone wants a full-featured platform with integrations, admin panels, and mobile support in a month, the math doesn’t work. Rushing a project leads to shortcuts, bugs, and a result nobody’s happy with.

I’d rather be honest about timelines upfront than deliver something half-baked on an arbitrary deadline.

Good Communication

The best client relationships I’ve had were with people who responded to messages within a reasonable timeframe, gave clear feedback, and made decisions without weeks of deliberation.

I don’t need daily calls — in fact, I prefer async communication for most things. But I do need a client who’s engaged. If I send a staging link and don’t hear back for two weeks, the project stalls. If decisions require approval from five people who are never available at the same time, everything slows to a crawl.

During the initial conversations, I pay attention to how quickly and clearly the client communicates. It’s usually a reliable predictor of how the project will go.

Technical Fit

I work primarily with TypeScript, Node.js, PostgreSQL, and React. I deploy with Docker and Caddy on VPS infrastructure. This stack covers a lot of ground, but it doesn’t cover everything.

If a project requires native iOS development, machine learning pipelines, or heavy embedded systems work, I’m not the right person for it. I’d rather refer the client to someone who specializes in that area than take on something I’ll struggle with.

I also consider the maintenance angle. If I build something, can the client find someone to maintain it after handoff? Using well-known tools and standard patterns matters more than using the newest framework.

Budget Alignment

I quote fixed prices, and those prices reflect the quality and reliability I deliver. I’m not the cheapest option, and I don’t try to be.

When a client’s budget is significantly below what the project requires, I’ll be upfront about it. Sometimes we can reduce scope to fit the budget. Other times, the gap is too wide, and I’ll recommend they look at other options — an agency with junior developers, a no-code platform, or a phased approach where they start with a smaller investment.

What I won’t do is take a project at a price that forces me to cut corners. That’s bad for the client and bad for my reputation.

Mutual Respect

This is harder to measure but easy to feel. Does the client treat this as a collaboration or a transaction? Do they value my input, or do they just want a code monkey who executes orders?

The best projects are ones where the client trusts my technical judgment and I trust their domain knowledge. When that dynamic is right, the work is better and the process is smoother.

Warning signs include: dictating specific technical implementations without understanding the tradeoffs, treating estimates as commitments to be negotiated down, or dismissing concerns I raise about the approach.

Saying No Is Part of the Job

Turning down work feels counterintuitive, especially when you’re freelancing and income isn’t guaranteed. But every bad project I’ve said yes to has cost me more than the revenue it generated — in stress, in time that could have gone to better projects, and sometimes in reputation if the result wasn’t up to my standard.

Being selective means the projects I do take on get my full attention and best work. Clients notice that. It’s why most of my work comes from referrals and repeat clients.

If a project checks all the boxes above, I’m in. If it doesn’t, I’ll be honest about why and point the client in a better direction. That honesty has gotten me more work in the long run than saying yes to everything ever did.

---

Think we might be a good fit? I’m available for freelance work. Get in touch — I typically respond within 24 hours.