Red Flags in a Custom Software Developer
Red flags when hiring a custom software developer - vague scope, ownership tricks, unrealistic dates, and other signals Kenyan SMEs should refuse.
KisoByte Solutions · 4 min read
Most failed software projects do not fail because “Java is hard.” They fail because warning signs were ignored while everyone admired the mockups. If you are hiring for a shop system, member portal, or internal tool, learning the red flags in a custom software developer will save more money than shaving a few days off the quote.
Use this as a filter next to the complete guide to custom software for SMEs in Kenya and the practical search process in how to find the right app developer.
Red flag 1 - Scope that will not sit still on paper
If they will not write v1 screens, roles, integrations, and out-of-scope items before a large build invoice, you are buying fog. Verbal scope becomes “you never said that” by week six.
What good looks like: a shared document you both initial, updated when change requests happen.
Red flag 2 - Fixed price + fixed date + undefined features
Three constraints cannot all float freely. Unlimited features with a hard launch date and a frozen price is not confidence - it is a future dispute.
What good looks like: fixed price on a fixed scope, or time-and-materials with a clear burn rate and demo cadence.
Red flag 3 - They keep the keys “for convenience”
Domain, hosting, app store accounts, SMS gateways, or cloud billing remain under their personal account. Convenience for them is lock-in for you.
What good looks like: your organisation owns accounts; they get least-privilege access.
Red flag 4 - No staging, no backups story
They edit live. One bad deploy takes the till or the member portal down on a Monday morning.
What good looks like: staging environment, backup/restore explained in plain language, release checklist.
Red flag 5 - Payments treated as a cartoon
M-Pesa and bank callbacks have timeouts, duplicates, and partial failures. A developer who waves away reconciliation has not run production systems here.
What good looks like: failure states drawn in the scope, admin tools to match payments, test plan in sandbox.
Red flag 6 - Portfolio that cannot map to your complexity
Pretty consumer apps do not prove they can build multi-role admin + audit trails + offline sync. Ask for closest-complexity work, not closest logo.
Red flag 7 - The salesperson is the entire team
Demos are flawless; delivery “resources” appear after deposit. Ask who codes, who designs, who tests - by name - and whether they are already overloaded.
Red flag 8 - Hostility to questions
You ask about handover, tests, or ownership and the room cools. Professionals who build for SMEs expect non-technical owners to ask basic control questions. A structured list is in questions before hiring a web developer - the same spirit applies to apps and systems.
Red flag 9 - “Maintenance is optional”
Software without a support path is a depreciating asset that breaks when phones, APIs, or tax rules change. If post-launch support is mocked as unnecessary, believe them - and leave.
Red flag 10 - Pressure tactics
- 100% payment upfront
- “Price rises Friday”
- Discouraging a second quote
- Refusing references of any kind
Urgency selling is for handbags, not core systems.
A quick scoring checklist
Mark each vendor. Two or more hard fails = walk.
- Written v1 scope exists before major payment
- Accounts (domain, hosting, stores) owned by you
- Staging + backup story is concrete
- Named delivery team, not only sales
- Payment/integration edge cases discussed
- Change-request rules written
- Warranty or hypercare period after go-live
- No mockery of documentation or training
Soft flags (not automatic disqualifiers)
These need scrutiny, not instant rejection:
- Young company with strong senior leads (check references harder)
- Higher price than competitors (may include real testing)
- Preference for their favourite stack (acceptable if handover docs are solid)
- Remote-only team (fine if demos and communication are disciplined)
What to do when you already see a flag mid-project
- Pause new feature requests
- Demand a current scope vs completed vs remaining list
- Move accounts into your ownership immediately
- Require weekly demos with a written decision log
- If trust is broken on ownership or money, get independent advice before pouring more cash
Document everything. Future-you (or a court, or a board) will care.
Kenya-specific tells
Pay attention when a pitch assumes:
- Always-fast fibre at every branch
- Card-first checkout as the main payment story
- Flagship phones only
- English-only admin for Kiswahili-first cashiers without a training plan
Those are not always deal-breakers, but they show weak local empathy. Ask how they will adapt.
Bottom line
Red flags in a custom software developer cluster around unclear scope, locked accounts, fantasy timelines, weak payment thinking, and contempt for questions. Treat them as exits, not decorations. Build your shortlist with how to find the right app developer, sharpen interviews with questions before hiring a web developer, and keep the strategic frame in the custom software guide for Kenyan SMEs.
Ready to scope a build that fits your budget?
Tell us what you sell, who uses the system, and what “done” looks like. We’ll come back with a clear scope, timeline bands, and whether a product or custom build is the smarter path.