Most software shops will tell you they take every project that walks through the door. That is not a quality decision. It is a math decision: they have payroll on Friday, and a project they cannot deliver well is still revenue.
We have made that math decision before. It taught us why we should not make it again.
What follows is the actual scorecard we run on inbound work. Not a polished version for the website — the version that lives in a Google Doc one of us reads on calls. We are publishing it because the founders we want to work with already think this way, and the ones who do not should know upfront.
1. Who owns the decision on the other side?
The single biggest predictor of whether a project ships well is who is on the other side of the table. If we are scoping with a founder, a CTO, or the operator who personally feels the pain — we move forward fast. If we are scoping with a project coordinator whose job is to send our proposal up the chain for approval, we slow down.
This is not a snobbery thing. Coordinators are doing their job. The problem is that software scoping requires hundreds of small judgment calls, and each one we make with someone who has to phone home for approval costs us a week. After eight weeks, the project is two months late and nobody has shipped a line of code.
So the first thing we ask is: who signs off on tradeoffs? If that person is in the kickoff call, we are interested. If they are not, we ask for them.
2. Is there a real deadline — or just a hopeful one?
"We need this by end of Q3" can mean two completely different things. It can mean: "if we do not have this by end of Q3, we miss the investor meeting / lose the customer / pay a penalty." That is a real deadline. We respect it, we scope around it, and we either commit or we say no.
It can also mean: "end of Q3 sounds about right." That is a hopeful deadline. They are not bad — most timelines start as hopes. The problem is when a hopeful deadline gets treated like a real one halfway through the project, and we end up cutting scope or quality to meet a date that was never structural.
When we hear a date, we ask one question: what happens if it slips two weeks? If the answer is "we are fine, the schedule is internal" — great, we plan for honest. If the answer is "the round closes" — also great, but we scope harder.
3. Does anyone here know what they want?
This sounds insulting and it is not meant to be. Knowing what you want is genuinely difficult, and most clients do not — that is often why they hired us. But there is a difference between "we don't know yet, can you help us figure it out" and "we know exactly what we want, and what we want is everything."
The first is a discovery engagement. We can do that. The second is a red flag, because what they actually want is unbounded scope at fixed price.
Our quick test: ask the founder to describe the minimum their software would do and still be useful. If the answer is a tight three-sentence description, we are working with someone who has thought about it. If the answer is a tour of every feature with no priority order, we are not signing until we have done a paid discovery week.
The clients who can articulate the smallest useful version of their product are the ones who ship. The ones who cannot are the ones who spend a year building the wrong thing.
4. Is the budget in the same universe as the work?
We bring budget up early. Most agencies do not, because the conventional wisdom is that you should sell value before price. The conventional wisdom is wrong.
If a client has $15,000 to spend and the work is honestly $80,000, neither of us is being helpful by getting to proposal stage before we have that conversation. We have wasted three weeks of their search and a week of our scoping time, and the answer was knowable on day one.
So: in the first call, we ask for a budget range. If the answer is "we don't have one yet," we offer the ranges we have seen for comparable scope. If the answer is materially below what the work costs, we say so on the call and offer one of two paths — a smaller scope that fits, or a referral to someone who does fixed-low-cost work and would not be unhappy to take it.
5. Do they treat their last vendor as the problem?
This one is uncomfortable to write. Sometimes the previous vendor was the problem. We have inherited some genuinely bad codebases. But more often, the way someone talks about their last engagement is a tell about how they will talk about ours.
If every previous developer or agency was incompetent, unprofessional, or "didn't understand the vision," we are looking at a pattern. Not always — sometimes people are just unlucky — but often. We ask one neutral question: what would you have done differently in that engagement? If the answer involves no self-reflection at all, we walk away politely.
6. Can we actually do this?
The last filter is the one we run on ourselves, not the client. Software studios get into trouble when they say yes to work outside their lane. We have three lanes — game and interactive media, enterprise software, and strategy — and we are honest with ourselves about the edges of each.
If a project needs an iOS engineer with five years of CoreML experience and we do not have one on the bench, we say so. We can hire, we can subcontract, or we can refer the work out. What we will not do is pretend the work is in our lane when it is not.
Why we are writing this down
The honest reason is that pre-qualifying clients is the single highest-leverage thing a small studio can do. Every hour we spend filtering well at the top of the funnel is five hours we do not spend untangling a bad engagement six months in.
The slightly less honest reason is that we want the founders who already think this way to recognize themselves in this post and send us an email. If you read this and thought "yes, obviously, who would not work this way" — we should probably talk.
A bad engagement does not just cost the project. It costs the next three projects' worth of attention.
— K.