How to Assess a Web Software Company's Technical Capability: An Evidence Checklist

A web software company's technical capability cannot be judged by the number of projects in its portfolio, the technologies it says it uses, or a polished presentation alone. What matters is how the company discovers your requirements, explains its technical decisions, manages security and testing, prepares a controlled release, and hands over a system that the client or another authorised team can maintain.

Do not stop at asking, “Which technologies do you use?” For every material part of the project, ask for three things together:

1. A project-specific answer
2. A document, process, test, or example that supports the answer
3. A clear boundary and named owner for the deliverable

The seven-gate checklist in this guide does not rank companies by size or favour one technology stack. It helps you distinguish a general promise from technical capability that can be examined before you sign a contract.

What Does Technical Capability Mean?

Technical capability is not the ability to use the newest tool or design the most complex possible architecture. It is the ability to choose a solution that fits the requirement; make security, performance, data, integration, continuity, and maintenance responsibilities visible; test and release the system in a controlled way; and hand it over so that another competent team can operate it.

A simple corporate website should not require the same architecture and testing depth as a web application with multiple user roles, specialised data flows, and critical integrations. Unnecessary complexity can create as much risk as inadequate preparation.

The NIST Secure Software Development Framework describes a common language that software producers and acquirers can use when discussing secure development. It also explains that practices should be prioritised and adapted around business needs, risk tolerance, and available resources. From this perspective, capability is not a memorised list of tools. It is the ability to justify and evidence decisions that fit the project's actual risk.

Give Every Candidate the Same Requirements Before You Compare Them

You cannot compare technical approaches fairly if each company has received a different description of the requirement. One supplier may have priced only the public pages, another may have included multilingual content and integrations, while a third may also have accounted for data migration and content entry.

Give every candidate the same project summary. It should cover the business objective, user groups, core workflows, current content and data, integrations, expected usage, security requirements, target date, and handover expectations. If these inputs have not yet been documented, begin with the website requirements document guide.

For each technical gate, record one of four statuses:

• Evidenced: The answer is specific to the project and supported by a document, process, test, or deliverable.
• Partly evidenced: The approach is reasonable, but the scope, owner, or output remains unclear.
• Unclear: There is a general promise without a verifiable explanation.
• Not applicable: The item is unnecessary for this project, and the reason has been explained.

“Not applicable” does not automatically indicate weak capability. A company should be able to explain why a service is unnecessary instead of adding cost and complexity that do not benefit the project.

Gate 1: Technical Discovery and Architecture Decisions

Technology should not be selected before the underlying requirement is understood. A capable company looks beyond a list of screens. It needs to understand who will use the system, where data originates and moves, which failures would be critical to the business, and how the project may change over time.

Depending on project scope, Kumsal Ajans's technical discovery considers:

• The business problem and the measures of success
• User groups, roles, permissions, and approval mechanisms
• Existing websites, software, databases, and data that must be preserved
• ERP, CRM, accounting, payment, shipping, email, SMS, and other API connections
• Expected visitor, user, transaction, and data volume, including peak periods
• Requirements for multiple languages, companies, dealers, branches, or mobile applications
• Internal security policies and obligations that affect the project
• Hosting, domains, current technologies, backups, and continuity expectations
• Growth plans, target dates, budget range, and decision owners

Evidence you can request

• A discovery questionnaire or meeting output
• A user-role and permission matrix
• An integration and data-flow inventory
• A record of scope, assumptions, and technical risks
• A high-level system or component diagram
• Non-functional requirements for performance, security, and continuity

Not every project needs all of these documents at the same level of detail. The company should explain why each output is or is not needed and identify which items will be delivered under the contract.

Red flags

• Confirming the technology or a fixed price before asking about workflows and existing data
• Naming integrations without explaining data direction, error handling, or ownership
• Promising performance or scale before expected usage is understood
• Failing to record assumptions and out-of-scope work

Gate 2: Secure Development and Access Control

“We develop secure software” is not evidence by itself. Security should be visible in project-specific decisions: how roles are separated, user input is validated, secrets are managed, dependencies are maintained, access is controlled, and relevant events are recorded.

The OWASP Application Security Verification Standard provides a basis for testing technical security controls in web applications and defining secure-development requirements. OWASP also identifies procurement and contracts as a use case for specifying verification requirements. This does not mean that every project must implement every requirement in the standard. It means that the appropriate verification scope should be selected and written down according to the application's functions and risk.

Kumsal Ajans defines the security model by considering the nature of the data, user volume, integrations, and sector-specific requirements. Depending on the project, the scope may include role-based access, separation of development, test, and production environments, TLS, form and file validation, application-layer controls, restricted administrative access, logging, backups, and update monitoring. If independent penetration testing or an advanced security assessment is required, it is defined separately.

Questions to ask

• How will user roles and least-privilege access be implemented?
• Where will API keys, database credentials, and other secrets be managed?
• Who will have access to development, test, and production environments?
• How will user input, file uploads, and critical transactions be validated?
• How will packages and server components be monitored and updated?
• Which events will be recorded for security and operational investigation?
• If independent security testing is required, who defines and owns its scope?

The OWASP Secrets Management Cheat Sheet addresses least-privilege access to secrets, lifecycle stages such as creation, rotation and revocation, audit records, and tested restoration procedures. Instead of accepting “we store credentials securely,” ask how access, storage, transfer, rotation, and handover will work.

Evidence you can request

• Project-specific security requirements or a control checklist
• A role and permission matrix
• An environment and access ownership list
• A dependency and update approach
• Security test scope and acceptance criteria
• A controlled method for handing over sensitive access

Red flags

• Claims such as “100% secure” or “impossible to breach”
• No clear record of who holds production access
• Treating API keys and passwords in source code as normal practice
• Naming a security test without explaining its scope, method, or owner

Gate 3: Code, Change, and Dependency Management

The existence of source code does not, by itself, prove that a project is maintainable. You also need to know which version is running in production, how changes are traced, how third-party components are managed, and what another developer would need to run the project.

OWASP SAMM is a technology- and process-agnostic model for improving the secure software lifecycle in a risk-driven and measurable way. Its recognition that there is no single recipe for every organisation supports a more useful evaluation: examine the maturity and traceability of decisions instead of awarding points for a particular tool alone.

Questions to ask

• Where will the source code be stored, and will its change history be retained?
• How will the production release be matched to a repository version?
• Who reviews code, and at which stage?
• How are important open-source, licensed, and third-party components recorded?
• How is the impact of a critical update assessed?
• What information would a new authorised team need to install the project?

Evidence you can request

• An example repository structure with confidential details removed
• A sample release note or change record
• Installation and environment requirements
• An inventory of important components and licences
• An explanation of the code-review or change-approval process

Companies do not have to use the same repository, branching, or release method. What needs to be demonstrated is that changes are traceable and the agreed project assets can be handed over.

Red flags

• Nobody can identify where the current production code is stored
• The scope of the source-code handover is unclear
• Third-party components and licences disappear inside a broad statement that “all code belongs to the client”
• Rebuilding the project in another environment depends entirely on verbal knowledge

Gate 4: Test Environment and Client Acceptance

A page working on a developer's computer does not mean that the project has passed acceptance testing. Roles, forms, integrations, responsive behaviour, failure states, and real business scenarios need to be considered through appropriate tests.

Kumsal Ajans does not develop directly on the live system. Where the project structure permits, development, testing, and production environments are separated. After internal testing, the client reviews agreed scenarios in an environment that does not affect production users or data. In-scope defects and omissions are addressed before final release preparation.

Questions to ask

• Which functions, roles, devices, and integrations will be tested?
• Who will prepare, run, and approve the test scenarios?
• Where will client acceptance take place, and against which criteria?
• Where will defects be recorded, and how will re-testing be documented?
• If test data includes real personal or commercial data, how will it be protected?

Evidence you can request

• A sample test scenario or acceptance checklist
• A separate test environment and controlled access method
• A defect and omission record
• Client acceptance criteria or sign-off
• Integration scenarios covering both success and failure conditions

Red flags

• Development and client review occur only in production
• “Everything will be tested” is promised without a written test scope
• Client acceptance is reduced to a visual inspection of pages
• Integration failures and service interruptions are never discussed

Gate 5: Release, Backup, and Rollback

Going live involves more than copying files to a server. Database changes, domains, TLS, email services, integration credentials, timing, backups, and the decision to roll back must be planned together.

When an existing system is involved, Kumsal Ajans takes file and database backups before migration. The approved release is deployed during the planned window, and critical pages, forms, user actions, and integrations are checked again in production. If a critical problem occurs, the rollback method may restore the previous stable version or an appropriate backup, depending on the project's data structure.

Questions to ask

• Who owns the pre-release checks and final approval?
• In which order will domain, TLS, database, file, and service changes occur?
• Which backups will be created, and has the restoration method been tested?
• If the database changes, how will rollback be handled?
• Which critical scenarios will be re-run after deployment?
• Who can initiate rollback, and at what decision threshold?

Evidence you can request

• A release checklist
• A backup and rollback plan
• Release owners and an escalation list
• A post-release critical-check list
• A migration or change sequence

There is no responsible universal promise for how quickly every rollback will finish. The time depends on data volume, database changes, integrations, and infrastructure. Ask for the method, owner, and decision threshold instead of an unsupported guarantee.

Red flags

• Treating the existence of a backup as proof that restoration is planned
• Ignoring rollback while making database changes
• Failing to re-test forms and integrations after deployment
• Concentrating every access and release decision in one person without an alternative contact plan

Gate 6: Monitoring, Maintenance, and Security Continuity

Technical responsibility does not disappear after launch. The contract or support plan should define how defects are reported, who examines logs, who is responsible for updates and backups, what happens when a third-party service changes, and how new development is separated from defect remediation.

The NIST SSDF includes identifying and responding to vulnerabilities in released software as a distinct group of practices. A capability review should therefore cover ongoing issue and change management, not just the first delivery.

Questions to ask

• Which channel is used for defect, access, and security reports?
• Who owns logs, backups, updates, and operational continuity?
• How are support, warranty-style defect remediation, maintenance, and new development separated?
• How will a third-party service change be investigated and priced?
• When the service ends, how will the final version, access, and operational knowledge be handed over?

Unless a quotation or contract states otherwise, Kumsal Ajans provides six months of free technical support for custom software projects from go-live or final handover. This period covers remediation of defects within the delivered scope and investigation of technical issues caused by the project. New features, scope expansion, routine maintenance, third-party changes, and external service fees are assessed separately.

Evidence you can request

• Support scope and its start and end dates
• Reporting channel and responsible contacts
• Maintenance, update, backup, and monitoring scope
• Criteria that distinguish a defect from a new request
• End-of-service handover steps

Red flags

• “Support is included” without a duration, reporting route, or scope
• Combining warranty, maintenance, and new development into one undefined service
• Leaving update and backup ownership ambiguous between the parties
• No handover plan for access and the current release when the service ends

Gate 7: Documentation, Access, and Client Ownership

Handover is one of the most visible outcomes of technical capability. The client should receive more than a working interface. Subject to the contract, it should also receive the agreed code, data, accounts, access, and operational information needed to maintain the system.

Where possible, Kumsal Ajans prefers domains, servers, email, and third-party service accounts to be created directly in the client's name. The handover scope for custom development is defined in the contract. Depending on the project, it may include:

• Current source code and repository access
• Production and test server access
• Domain, DNS, hosting, cloud, or server accounts
• Database and management-panel access
• Third-party service accounts and integration information
• Installation, deployment, backup, and restoration guidance
• Environment requirements and relevant technology information
• Necessary data-structure or API documentation
• Management-panel guidance or training
• Licences, known technical constraints, and future-development recommendations

Passwords, API keys, and other sensitive access should not be placed in broadly shared documents. They should be transferred to authorised people through a controlled method.

Questions to ask

• Which code, data, designs, documents, and accounts will be handed over?
• What licence boundaries apply to third-party or reusable components?
• Will accounts be created in the client's name; if not, what is the exit process?
• Which documents and access would another team need to take over the project?
• How will secrets be transferred and permissions changed at handover?

Red flags

• Source-code, data, or account ownership is explained only verbally
• Client services remain exclusively in the supplier's account without a reason and exit plan
• The handover list omits release, backup, installation, or environment information
• Sensitive credentials are routinely sent through uncontrolled files or open messages

The Seven-Gate Technical Evidence Checklist

Complete the following table for every candidate. In the evidence column, enter the document name, proposal section, sample output, or unanswered question.

Do not rely on a single total score. Mark critical requirements separately. If a project includes payment processing, sensitive data, low tolerance for interruption, or regulatory obligations, an “unclear” result in the relevant gate cannot automatically be offset by strong answers elsewhere.

A Clearly Fictional Evaluation Scenario

The following scenario is fictional and is included only to demonstrate how the method can be applied. It is not a client case study.

Imagine an organisation with several branches that needs content management, department-level permissions, and data from two external systems. Company A presents a modern technology list and a rapid delivery date but does not explain the data flow, test environment, or handover documents. Company B proposes a longer discovery phase and documents user roles, integration failure states, test scenarios, the release plan, and source-code handover.

This does not automatically make Company B the “best” supplier. Price, timing, team fit, and the risk of unnecessary complexity must still be examined. However, the way technical risks will be managed is now comparable. Company A can reach the same evidence level by completing the missing items in writing.

The purpose is not to select a brand or technology. It is to expose critical uncertainty before the contract is signed.

15 Short Questions for a Technical Meeting

1. Which user, data, and integration assumptions support your proposed architecture?
2. What are the project's three most important technical risks?
3. Which requirements remain uncertain with the information available today?
4. How will user roles and critical permissions be verified?
5. How will secrets be kept out of source code and general documentation?
6. How will the project's risk determine the security test scope?
7. How will the production version stay connected to the source repository?
8. How will development, test, and production environments be separated?
9. Which scenarios and criteria define client acceptance?
10. If an integration fails, which party investigates which component?
11. Which backups and checks will be prepared before release?
12. Who can start a rollback, under what conditions, and by which method?
13. Which critical actions will be tested again after release?
14. How are support, maintenance, and new development separated?
15. If another team takes over, which code, data, accounts, and documents will be delivered?

Ask for the answers to appear in the proposal or an accompanying technical document. Compare project-specific, verifiable answers rather than general company presentations. You can use the website proposal comparison scorecard to assess the commercial scope in a consistent format as well.

Conclusion: Examine Decision-Making and Handover, Not the Technology List

When selecting a web software company, do not reduce technical capability to the longest technology list, the lowest price, or the boldest security statement. A capable process discovers the real requirement, exposes risks, defines security and testing in proportion to the project, plans a controlled release and rollback method, and makes code, data, access, and responsibilities transferable.

Apply the seven gates to every candidate in the same order. If a critical answer remains unclear, request written evidence. If an item is genuinely unnecessary, a reasoned “not applicable” decision can also protect the project from needless services and complexity.

To discuss your project's technical scope, security, and integration requirements, explore the Kumsal Ajans web software service.

Frequently Asked Questions

Can a team with limited technical knowledge assess a web software company?

Yes. The team does not have to validate every technology decision alone. It can ask every supplier the same questions and compare whether assumptions, owners, tests, and handover items are documented. An independent technical adviser may be engaged for critical architecture or security decisions.

Is a strong portfolio enough to prove technical capability?

No. A portfolio may show experience with certain types of work, but it does not prove how discovery, security, testing, integrations, release, and handover will be managed for your project. Assess it together with project-specific process and evidence.

Does every web software project need independent penetration testing?

No single test scope fits every project. The nature of the data, user roles, payments or critical integrations, access levels, and sector-specific obligations affect the required depth. If independent penetration testing is needed, define the scope, environment, owner, and remediation process separately.

Does receiving the source code prove technical capability?

Not by itself. The code should represent the current release and be accompanied by relevant installation information, dependency and licence details, data and account access, and the materials another authorised team would need to maintain the system.

How can we compare companies that propose different technologies?

Do not score technology names in isolation. Examine how each proposal addresses the same workflows, data, integrations, security, performance, maintenance, and handover requirements. The company should be able to explain the reason for its choice, its limitations, and the resulting operational responsibilities.