Examines what exists against a standard. Returns defects, risk and a prioritized remediation plan with costs and effort attached.
KeevaathTech/Services/Product assessment
LENS · KPA
Product assessment
Eight assessments across product, website and codebase. An audit finds what is wrong. An evaluation answers what to do about it.
Audit compared with evaluation
An audit
An evaluation
Answers one decision. Keep, rebuild, replace or buy. Returns a recommendation with the reasoning and the numbers behind it.
They are different engagements at different prices. If you know you are keeping the thing and want to know what to fix, take an audit. If the question is whether to keep it at all, take an evaluation.
Every assessment covers one of three scopes, being a product, a website or a codebase. The checklist changes. The shape does not.
The eight assessments
Accessibility conformance auditWCAG 2.2 Level AA, tested by keyboard and screen reader, with a draft accessibility statement.
Website auditPerformance, accessibility, search, conversion, code quality and security configuration.
Software auditCodebase health, dependency and version risk, test coverage and maintainability.
Technical due diligenceAn independent read on what you would be buying or funding, with reliance in writing.
Product auditUsage, experience, technical debt, performance, accessibility and security posture.
Product management auditRoadmap, discovery practice, prioritization and delivery cadence. Written as decision support, not as a review of your team.
EvaluationKeep, rebuild, replace or buy, answered with the reasoning and the numbers.
Architecture reviewA second opinion on the structure, before it becomes expensive to change.
What we examine, across all of them
Codebases in Node, Express, React, Next.js and MongoDB, and WordPress and PHP estates somebody else wrote. Performance and caching. Accessibility to WCAG 2.2 Level AA. Technical search validation. Security configuration and SSL. Cross browser and responsive behavior. Dependency and version risk. Test coverage. Maintainability.
Two commitments
We read what is deployed, not what is recorded
Fix reports, documentation and repositories drift from the running system, and the gap between them is where most of the cost in software actually lives. We audit the bytes that are serving. That discipline came out of our own platforms, and the account of how is published.
We do not sell the remediation to sell the audit
Assessments are sold separately from build and maintenance work so that the findings are not shaped by who profits from the fixes. Many clients hand the plan to their own team or their existing agency, and we answer their questions.
Questions we are asked
Which one do we need?
If something is broken and you are keeping it, an audit. If you are deciding whether to keep it, an evaluation. If you are buying or funding it, due diligence. If it is specifically accessibility or a website, take those pages directly. Say what you are deciding on the questionnaire and we will tell you which to buy, including when the answer is a cheaper one.
Do you fix what you find?
We can, under a separate engagement. Selling the audit on its own is deliberate.
Can a third party rely on the report?
For due diligence, yes, agreed in writing beforehand with the reliance parties named. For other assessments we can arrange it on request.
Is maintenance available without an audit?
No. Taking a monthly fee for a codebase nobody has examined serves neither side, so every maintenance engagement begins with a fixed scope audit.
What if the answer is that nothing is wrong?
Then the report says so and names where the problem actually is, which is usually content, measurement or the process for making changes. It happens.
Not sure which one you need?
Say what you are trying to decide on the questionnaire and we will tell you which assessment answers it, including when the answer is a cheaper one than you asked for.