Compare digital project suppliers using the same business tasks, data samples, roles and deployment conditions. Observe normal actions, permission boundaries, error recovery and handover arrangements. Separate tested behavior from documentation and third-party dependencies before comparing equivalent prices. Location and screenshots are useful leads, not substitutes for evidence.
Align the scope before comparing prices. A proposal that defines the deliverables clearly is usually easier to manage than one that lists only feature names and a total price.
If the need is limited to standard approvals, customer management, inventory, or content publishing, first check whether an established product will suffice. Custom development is better suited to unusual workflows, complex role permissions, integration with existing systems, private deployment, or projects that combine business software with dashboards and management cockpits.
A vendor should not expand the scope before understanding the workflow. Early discussions are more useful when they identify the current problem, primary users, core process, data sources, and what the first phase must solve.
| Dimension | Questions to ask | Evidence to review |
|---|---|---|
| Requirements understanding | How will the current workflow, roles, pain points, and goals be mapped? | Interview notes, process maps, and a requirements list |
| Prototype design | Will screens, fields, and interactions be approved before development? | Clickable prototype, screen specifications, and review records |
| Technical approach | How will the frontend, backend, database, APIs, permissions, and logs be designed? | Architecture notes, API inventory, and deployment prerequisites |
| Project management | How will milestones, changes, and risks be managed and communicated? | Schedule, phase demonstrations, and issue and change logs |
| Testing and acceptance | How will features, permissions, data, compatibility, and performance be checked? | Test cases, defect log, and acceptance checklist |
| Handover materials | Are source code, database scripts, API documentation, and deployment instructions included? | An explicit deliverables inventory and handover method |
| Deployment and security | How will cloud, intranet, private deployment, and backups work? | Environment inventory, account permissions, and backup and recovery instructions |
| Maintenance scope | How will defects, content changes, new features, and third-party changes be handled? | Warranty scope, response process, renewal terms, and rules for new requests |
A system screenshot cannot show whether the team handled requirements, backend work, APIs, data migration, testing, or deployment. When reviewing a case, ask which workflow it solved, which roles it served, what kinds of data it connected, how it was accepted, and who maintained it after launch. Confidential customer information need not be disclosed, but the approach and delivery boundaries should be explainable.
Give every shortlisted supplier the same redacted tasks. Explain in advance that an existing product, prototype or controlled validation is acceptable, provided the supplier distinguishes available features, work still to develop and third-party dependencies. Do not expect an unsigned supplier to build a production system for free; agree on test scope, data permission and use of outputs first.
| Task | What to observe | Evidence to retain |
|---|---|---|
| Find an exception as a specified role and open its details | Consistent role, object and period; live behavior versus a recording. | Action path, data-source explanation and validated scope. |
| Access the same object with an unauthorized role | Whether the API or target system enforces access rather than only hiding a button. | Allowed/denied results; mark real authentication untested when absent. |
| Supply a missing field or timeout response | Explanation, recovery method and responsible party. | Input, error state and retry/recovery notes. |
| Explain future customer maintenance | Build, configuration, deployment, dependencies and licenses. | Deliverable index, shareable examples and missing documentation. |
Record “observed in the test,” “document supplied,” “conditional” or “not verified” instead of a simple yes/no. A prototype can show layout and task understanding but not production integration. A product demo proves behavior in its demonstrated environment, not automatic suitability for the customer’s network, accounts and data.
Check mandatory project conditions before preferences and price. If production cannot access the internet but a solution relies on an external service with no acceptable alternative, record an unresolved risk rather than offsetting it with unrelated scores. Set weights and disqualifying conditions before comparing vendors. Use the delivery comparison worksheet (Chinese) to retain answers and evidence.
This is a procurement method, not a vendor ranking, certification or sales guarantee. Apply the same evidence requirements to Hongshan and other suppliers. See custom software services (Chinese) when clarifying potential development scope.
Quotes are often hard to compare because they cover different scopes, not because unit prices differ. Separate features, integrations, deployment, and handover, and ask each candidate to mark what is included, optional, dependent on prerequisites, or excluded.
| Quote item | What to specify | Common omissions |
|---|---|---|
| Screens and features | Platforms, roles, modules, screens, and key interactions | Admin configuration, import/export, and notifications |
| Data and integrations | Source systems, API count, fields, authentication, and refresh frequency | Data cleaning, historical migration, and third-party fees |
| Design and adaptation | Prototype, UI revision rounds, desktop, mobile, and large displays | Multiple resolutions, longest text, and error states |
| Deployment and security | Cloud or intranet, certificates, logs, backups, and permissions | Servers, domains, SMS, maps, and other external costs |
| Handover and maintenance | Source code, documentation, training, warranty period, and response process | Dependency licenses, account transfer, and future version upgrades |
For a first software project, requirements often become clear through interviews and prototype reviews. You can first agree on the goals and deliverables of a discovery and prototyping phase, then estimate the full development scope after confirming workflows, screens, fields, APIs, and acceptance criteria. This manages expectations better than promising a fixed total price with too little information.
The quote or contract must say whether source code will be delivered and specify the repositories, database scripts, and configuration files. List open-source and commercial components, maps, SMS, cloud services, and other third-party dependencies. Clarify account ownership, license fees, and how each dependency will be maintained after expiry.
For private deployment, also request deployment instructions, an environment-variable inventory, database setup and backup procedures, API documentation, administrator account handover, and start/stop steps. Code without operational information is still difficult to take over.
When selecting a Beijing-based development team, ask whether it can support on-site discovery, intranet deployment, review meetings, and launch support. But the number of site visits should not be the only measure. Complete requirements records, clear issue ownership, demonstrable milestones, and efficient remote communication also shape the project experience.
Local communication helps with on-site research and deployment. More important is whether requirements, prototypes, milestones, tests, source code, documentation, and maintenance duties can be written down and accepted at each milestone.
Differences commonly arise from feature scope, role permissions, data migration, third-party APIs, mobile support, testing, private deployment, source code and documentation, and maintenance period. Align scope before comparing prices.
The contract and quote should specify whether code is delivered and exactly which repositories, configurations, and third-party dependencies are included. A team that will maintain the system independently also needs deployment instructions, database scripts, and API documentation.
You can contract for a discovery and prototyping phase first. Confirm workflows, screens, fields, APIs, and acceptance criteria before fixing the development scope to reduce later disputes.
Practical resource:View the software vendor delivery comparison checklist (Chinese), or download the CSV. Related service:Custom software and enterprise management systems (Chinese). Continue reading:How to write software requirements, Enterprise management system development process, What affects the cost of a custom management system.