Nincol works in the space between a business problem and a development contract, when the most consequential choices are still reversible.
Why Nincol exists
Many costly software failures begin before a line of code is written: unclear scope, optimistic budgets, habitual architecture choices and vendor agreements that are hard to evaluate. Nincol works in that window.
The goal is not a larger project. It is a better decision, supported by evidence and documented well enough for your team to use.
The independence test
A recommendation has to survive someone else building it
That test decides what we take on, how far a scope goes and when we say no. Both halves of it are written down here so you can hold us to them.
What it commits us to
Prices stay published
Starting prices are on the website. You never have to book a call to find out whether we are affordable.
We will advise against work
If the right answer is to build nothing, buy instead of building, or stay with your current vendor, that is the recommendation you receive.
The document is yours
Every engagement ends in a written recommendation you own and can hand to any vendor. It stays useful whoever performs the build.
Reasoning you can challenge
Findings carry business impact, technical evidence, severity rationale and verification status, so you can test the argument rather than trust it.
You speak to the adviser
The person writing the recommendation is the person you talk to. Nothing is handed to an account manager.
What we decline
Testing without authorisation
Security review starts only with written authorisation from the system owner. We do not examine a system on request alone.
Credentials through a form
We never ask for passwords, keys or source code through this website. Sensitive material moves on an agreed channel once scope is confirmed.
Verdicts without review
We do not rate a vendor, product or architecture we have not examined. An unexamined preference is not advice.
Scope that grows quietly
A material change to agreed scope needs your written agreement before any further work is done or billed.
Capability and experience
Advice from people who build the systems
Nincol Consultancy is a technology advisory practice. Engagements are delivered by practising engineers who build and integrate production systems, not by account managers who pass the work on. That is why the advice holds up when your development team starts asking hard questions about it.
You speak directly to the person writing the recommendation, and it remains defensible whether Nincol, your internal team or another vendor does the build.
Delivery leadership
Day-to-day responsibility for a software team: architecture decisions, delivery standards and code quality. The same lens is applied when reviewing how your vendor or team actually works.
API and integration architecture
Design and operation of API gateway platforms using WSO2 API Manager and Identity Server, covering rate limiting, access control and service integration with Apache Camel.
Systems built for this market
Hands-on delivery of M-Pesa payment integration and inventory, banking and logistics systems for Kenyan businesses, so cost and feasibility advice reflects local conditions.
Capability development
More than two hundred developers trained and mentored. This is the foundation of our career advisory and of the team capability reviews we run for clients.
Working knowledge
Java, Spring Boot and microservice architecture
Python, Django and REST API design
React and TypeScript front ends
Docker, Kubernetes, Jenkins and CI/CD pipelines
AWS and cloud deployment strategy
API management, identity and access control
Nincol Consultancy is based in Nairobi, Kenya and works with clients across the region.
What a deliverable looks like
Advisory work is only useful if you can act on it. Every engagement ends in a written document you own and can hand to any vendor. This is how findings are recorded.
Administrative interface reachable from the public internet
Any visitor can reach the login form and attempt credential guessing against accounts with full data access.
Remediation. Restrict by source address at the proxy and require multi-factor authentication for staff.
NC-02high
Customer records returned without authorisation checks
Changing a numeric identifier in the request returns another customer’s order history and phone number.
Remediation. Enforce ownership checks in the query layer rather than in the interface.
NC-03medium
Framework two major versions behind, outside security support
Published vulnerabilities affecting this release will not receive vendor patches.
Remediation. Plan a staged upgrade to the current long-term support release.
An illustrative extract from a Nincol security review, showing how findings are recorded with a severity, a business impact and a remediation step.
Ref
Severity
Finding
NC-01
critical
Administrative interface reachable from the public internet
Any visitor can reach the login form and attempt credential guessing against accounts with full data access.
Remediation. Restrict by source address at the proxy and require multi-factor authentication for staff.
NC-02
high
Customer records returned without authorisation checks
Changing a numeric identifier in the request returns another customer’s order history and phone number.
Remediation. Enforce ownership checks in the query layer rather than in the interface.
NC-03
medium
Framework two major versions behind, outside security support
Published vulnerabilities affecting this release will not receive vendor patches.
Remediation. Plan a staged upgrade to the current long-term support release.
Every finding carries a severity, the business impact behind it and a specific remediation step. No client system is shown; this extract is written for illustration.
The practice in short
Practice
Independent technology advisory
Base
Nairobi, Kenya
Works with
Businesses, founders and technology teams in Kenya and the wider region