How to read this product-focused shortlist
Publisher-interest disclosure: Kooya sells AI software development and publishes The Signal. We place Kooya first because this is our own editorial shortlist. The order is not a measured league table, an independent endorsement or a claim that any company is best for every buyer. We reviewed the official pages linked below on 24 October 2026; they establish what each company describes offering, not independently verified delivery outcomes.
This guide addresses a specific purchase: a new product or substantial product feature that needs discovery, interface design, application engineering and launch support. Our broader company shortlist covers the market; our agent guide focuses on tools, permissions and workflow execution. Here, the deciding question is who owns the complete experience from the first user test through ongoing operation.
1. Kooya: define and build the product around the work
Kooya’s current website describes custom AI software, products and internal tools, with a process spanning diagnosis, prototyping, engineering and operation. It says the prototype should be the smallest useful version tested with intended users, followed by system connections, controls and launch preparation. These are Kooya’s own service descriptions.[1]
Kooya’s recommendation: start the conversation with a user problem and a decision the product must improve. Ask us to turn that into an end-to-end journey, a bounded first release and a written account of what happens when the AI cannot help. The proposed team, delivery scope, ownership and support must be confirmed in the engagement; listing ourselves first is no substitute for that assessment.
- Best starting conversation: an ambiguous product idea that needs a coherent experience and working software.
- Ask us to show: the discovery deliverables, named decision owners, a testable first journey and the operating responsibilities after launch.
2. Symph: taking a prototype into a supported application
Symph explicitly describes taking AI-built prototypes into production through security review, integration, hosting, monitoring and handover. Its website also offers a product-team engagement and custom software work. An AI-built prototype and an AI-powered product are different things: the former describes how code was produced; the latter describes functionality delivered to users.[2]
Kooya’s reading: Symph is a relevant conversation if a founder or team already has a working prototype and needs to establish what can safely survive into production. Ask the proposed team to distinguish reusable code from parts requiring reconstruction. If your product depends on model behaviour, explicitly include model evaluation and user-facing failure handling; prototype-hardening language alone does not establish those deliverables.
- Best starting conversation: an existing prototype that needs production engineering and a clear handover.
- Ask Symph to show: the review scope, integration plan, product-design role and support boundary for your particular build.
3. Stratpoint: product design within a wider software programme
Stratpoint’s software-services page lists UI/UX design, web and mobile applications and APIs. Its AI page describes work from ideation and design thinking through experiments, prototypes and implementation on web or mobile platforms, supported by software, cloud, data and quality-assurance services.[3][4]
Kooya’s reading: Stratpoint is a relevant conversation when an AI product must fit a broader application, cloud or data programme. Ask which disciplines are assigned to the proposed engagement, rather than assuming every advertised service is included. A coherent product needs someone to resolve disagreements between the interface, model behaviour, data constraints and release plan.
- Best starting conversation: a product that must integrate with a substantial application or enterprise technology environment.
- Ask Stratpoint to show: the product-design responsibility, integration assumptions, evaluation plan and ongoing delivery model.
Specify discovery outputs before asking for an MVP price
The following framework is Kooya analysis, not a statement about any company’s standard contract. Give every shortlisted team the same short brief: who will use the product, what task they do today, where the current process fails and what a useful first release would change. Include representative documents or examples only when you have permission to share them.
Ask for discovery outputs that can change the build decision: a tested user journey, a map of data and system dependencies, a list of uncertain assumptions and a proposal for the smallest useful release. A discovery phase should be allowed to conclude that a simpler software feature is sufficient. Otherwise it can become a ritual that approves an AI build regardless of the evidence.
- Name one primary user and one complete task for the first release.
- Define a non-AI baseline, such as the existing search or manual workflow.
- Document which assumptions need user testing and which need technical experiments.
- Request separate estimates for discovery, the release and ongoing operation; do not compare differently scoped totals.
Make the AI experience testable, including failure
Consider a hypothetical document-assistance product. A polished answer screen is only one part of the experience. The user also needs to know whether the document was accepted, which passages support the answer, when the system is uncertain and how to correct an unsuitable result. These are product requirements that should appear in the prototype and acceptance criteria.
For Philippine users, test the actual language mix, device conditions and examples your intended audience uses. If Filipino-English interaction matters, include it in the evaluation set instead of treating an English demonstration as sufficient. Do not generalise a small test into a claim of nationwide language coverage.
Use a fixed set of representative tasks to compare the proposed product with the baseline. Measure task completion and the cost of corrections alongside answer quality, latency and model usage. Agree acceptable failure behaviour before launch: asking for clarification, returning evidence without a conclusion, or escalating to a person may be more useful than forcing an answer.
Use our AI pilot evaluation checklist to turn the proposed product experience into acceptance evidence.
Agree launch ownership while the product is still small
Kooya’s recommendation is to finish the brief with an ownership schedule. Specify who controls the repository, deployment accounts, domain, data stores and model-provider accounts; what rights the customer receives; and how another team could operate the product. These are terms to negotiate, not ownership guarantees implied by a company’s website.
Separate launch acceptance from continuing improvement. Identify who can release changes, roll back a model or prompt, investigate a failed task and respond to a support request. Define what is included in support and what becomes separately scoped development. The buyer should be able to understand the operating cost and responsibilities without reconstructing them from a collection of invoices.
- Discovery gate: evidence that the chosen user problem is worth solving.
- Release gate: agreed user journeys and AI failure cases pass the acceptance checks.
- Handover gate: documentation, access and operational responsibilities are usable by the designated owner.
- Improvement gate: a defined review cadence for real usage, failures, cost and product changes.