We say no to about 25% of the projects we're asked to build.
Not because we can't do them. Because they would fail — and failing together is worse than not starting at all.
Here are the four types of projects we turn down.
1. The magic wand expectation
"I need an app that does everything. Built in 2 months. Budget is ₦1.5M."
No.
Why we say no
A production-grade system for a single core workflow starts at ₦3-5M and takes 3-4 months. If the expectation is "Uber quality for WhatsApp price," the project will end with disappointment on both sides. We'd rather lose the project than set you up for failure.
What we say instead: Here is what ₦1.5M can actually build. It's smaller than you want. But it will work. Let's start there and grow.
2. The unclear requirement
"Build me something like [popular app], but for [industry]."
We ask what that means. The answer is usually vague. We dig deeper. It stays vague.
Why we say no
Without clear requirements, there is no way to estimate cost, timeline, or success criteria. The project becomes an open-ended exploration — and those rarely end well. Every day of unclear requirements is a day of wasted money.
What we say instead: Let's spend a week writing a one-page spec together. If we can't describe the product clearly on a single page, we're not ready to build.
3. The race-to-bottom pricing
"Company X quoted ₦800K. Can you match it?"
We can't. More importantly, we won't.
Why we say no
Software built at ₦800K is either (a) an intern's first project, (b) a template with your logo pasted on, or (c) a project that will need rebuilding in 6 months. None of those outcomes serve you. We charge market rates because we deliver working systems that don't need to be rebuilt.
What we say instead: If budget is the primary constraint, we can suggest tools, no-code platforms, or freelancers that fit your range. We'll even help you scope the project so you get the best result for that budget.
4. No owner on the client side
"I'm too busy to be involved. Just build it and show me when it's done."
This is the most dangerous of all.
Why we say no
Every successful software project needs a decision-maker on the client side who: answers questions within 24 hours, reviews designs and gives clear feedback, tests features and reports issues, and makes scope trade-off calls. Without this person, the project drifts. Quality drops. Timelines slip.
What we say instead: Designate one person as the project owner — at least 5 hours per week. If that's impossible, we can't build what you need.
What we say yes to
Our yes criteria
We say yes when: (1) The problem is clearly defined. (2) The budget matches the scope. (3) There is a committed owner on your side. (4) You want a partnership, not a transaction. (5) You're open to honest feedback — even when it's "this feature isn't worth building."
What to look for in a tech partner
- They challenge your assumptions. If a partner agrees with everything you say, they're not thinking deeply enough about your problem.
- They show you their process. Not just their portfolio. How they discover, design, build, test, and deploy matters more than what they've built before.
- They say no. A partner who sets boundaries is a partner who cares about outcomes, not revenue.
- They price transparently. Fixed-price for defined scopes. Hourly for ongoing work. No surprise bills.
- They bet on relationships. The best projects come from repeat clients. Look for a partner who wants to build with you long-term.
Ready for an honest conversation about your project? Book a call. We'll tell you if we're the right fit — and if we're not, we'll tell you that too.