How a Company Without In-House Developers Should Choose a Software Vendor — What to Check Before Estimates and Contracts

Sometimes a company asks an outside firm to develop a business app without anyone in-house who understands system development. Even after receiving proposals and estimates from candidate companies, you cannot compare them on their technical content.

This article takes up what a client without technical knowledge can still compare: how each vendor answers questions about “how they work” and “what the contract will decide.” That means how requirements definition is run, the assumptions behind the estimate and how changes are handled, deliverables and copyright, acceptance, the working team and subcontracting, the handling of data you entrust to them, and maintenance after delivery. As a yardstick, it uses public materials such as the “Information System Model Transaction and Contract” published by IPA (Information-technology Promotion Agency, Japan).

The scope is having an internal business app built through custom software development. This article does not deal with interpreting contract clauses or making legal judgments, so before signing a contract, also check with your legal staff or a professional. What to sort out in your own company before making a request is covered in “Windows App Outsourcing and Custom Software Development: What to Sort Out Before You Ask,” and how to structure the contract in “How Should You Structure a Custom Software Development or Operations & Maintenance Contract?.”

What You Can Compare Without Looking at the Technology

Even if it is hard for the client to tell the quality of a vendor’s code in advance, you can compare how the vendor explains the way it works: whether the explanation is specific, whether it is given in writing, and whether the vendor is open about the work and decisions that will also be required of the client.

IPA’s Model Transaction and Contract is a template for the contract concluded between the user (the client) and the vendor. Its clauses list what the client should settle in advance, such as the division of roles in requirements definition, the rights to the deliverables, acceptance, subcontracting, the change procedure and security¹. If you turn this list straight into a list of questions, even a client without technical knowledge can compare candidates on the same yardstick.

flowchart TB
        accTitle: Points for comparing candidate vendors
        accDescr: Shows asking candidate vendors the same questions and comparing their answers on how requirements definition is run, estimates and changes, deliverables and copyright, acceptance, the team and subcontracting, entrusted data and maintenance.
        A["Candidate vendors"] --> Q["Ask the same questions"]
        Q --> P1["How requirements definition is run"]
        Q --> P2["Estimate assumptions and changes"]
        Q --> P3["Deliverables and copyright"]
        Q --> P4["Acceptance and team"]
        P4 -.-> P5["Subcontracting, entrusted data, maintenance"]
        P1 --> C["Line up and compare the answers"]
        P2 --> C
        P3 --> C
        P4 --> C

Figure 1: Ask the candidates the same questions, then line up and compare their answers on how they work and on each point of the contract.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (8 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

How Requirements Definition Is Run

The Client Decides the Requirements

Requirements definition is the phase that decides what the system will do. IPA’s “Requirements Definition Guide for Users” says that responsibility for defining a system’s requirements lies with the user, who will use the system to benefit the business². In the model contract too, the division of roles is that the client (Party A) produces the requirements definition document, and the vendor (Party B) supports it through investigation, analysis, proposals, advice and so on based on its expertise³.

Even in a company without developers, it is your company that decides the business flow, how exceptions are handled, which reports are needed and so on. Ask the vendor how it will help you make those decisions.

• Who will run the requirements definition meetings, and how many times and over what period
• What documents will be produced as the output of requirements definition, and who will approve them
• The materials the client must prepare, and an estimate of the time its staff will need to spend

Whether a vendor lists the work required of the client specifically, or just answers “leave it to us,” is a clue for comparison.

Split the Contract by Phase

Rather than putting every phase of development into a single contract, the model contract is built around a multi-stage contract in which an individual contract is concluded for each phase¹. The order is to contract requirements definition as quasi-mandate support work, and to estimate and contract the development part after the requirements are decided.

flowchart TB
        accTitle: Concluding an individual contract for each phase under a multi-stage contract
        accDescr: Shows that under a basic contract, support for requirements definition is done under a quasi-mandate individual contract, development is estimated after the requirements are decided and a separate individual contract is concluded, and then individual contracts for operational preparation and migration follow.
        BASE["Basic contract"] --> R["Individual contract 1: requirements definition support (quasi-mandate)"]
        R --> RD["Client finalizes the requirements definition document"]
        RD --> EST["Estimate for the development part"]
        EST --> D["Individual contract 2: development (contract for work or quasi-mandate)"]
        D --> M["Individual contract 3: operational preparation and migration"]

Figure 2: Estimate development after the requirements are decided, and conclude an individual contract for each phase.

You may receive a proposal that fixes the price and delivery date of the whole development before the requirements are decided. That differs from the model contract’s approach, so ask what the price assumes and how it will be handled if those assumptions change. A proposal that cannot show its assumptions in writing leaves you no basis for comparison when the question of extra costs comes up later.

Estimate Assumptions and How Changes Are Handled

The price in an estimate rests on assumptions such as which features will be built and to what extent, which environment they will run in, and what the vendor will do and what the client will do. If the assumptions differ between candidates, lining up the prices alone is not a comparison. Ask for a breakdown of the estimate and a written list of the work it does not include.

Once development has started, you may want to change the specifications. The model contract provides that a finalized specification may be changed only through the change management procedure³. This is a procedure in which a change proposal is submitted in writing and decided through consultation, including its impact on cost and delivery date.

flowchart TB
        accTitle: The flow of the change management procedure
        accDescr: Shows that when you want to change the specifications, a change proposal is submitted in writing, its impact on cost and delivery date is discussed, and the agreed content is recorded before it is reflected in the work.
        A["You want to change the specifications"] --> B["Submit a change proposal in writing"]
        B --> C["Discuss the impact on cost and delivery"]
        C --> D["Record what was agreed"]
        D --> E["Reflect it in the work"]

Figure 3: A specification change starts with a written proposal, and what was agreed after discussing its impact is recorded before it is reflected.

Ask the candidates how they proceed when asked for a change. A company that documents the content and impact of a change and confirms it lets you trace afterward which change added how much, more than a company that says it will take on a verbal request on the spot.

Deliverables and Copyright

What to Include in the Deliverables

As defined in the model contract, the software to be developed consists of what the individual contract specifies, such as programs, content, databases and related materials³. It is safer to assume that only what is written in the contract will be delivered.

Ask the candidates whether they will include the following in the deliverables:

• The source code
• Design documents and a description of the database structure
• Build and distribution procedures
• Operating and failure response procedures

If you may later ask a different company to maintain the app, you will be in trouble without the source code and design documents. What happens when you take over a system with neither source code nor specifications is described in “When You Inherit a System With No Source Code and No Documentation.”

How Copyright Is Handled

The model contract’s clause on “copyright in the deliverables” (Article 45) has three options³.

flowchart TB
        accTitle: Three options for copyright in the deliverables
        accDescr: Shows that in the model contract's clause on copyright in the deliverables, Option A has it belong to the vendor, Option B transfers it to the client when the fee is paid in full except for general-purpose programs, and Option C makes newly created programs shared.
        CL["Copyright in the deliverables (Article 45)"] --> A["Option A: belongs to the vendor"]
        CL --> B["Option B: transfers to the client on full payment"]
        CL --> C["Option C: shared by client and vendor"]
        B -.-> BX["General-purpose programs stay with the vendor"]
        C -.-> CX["General-purpose programs are excluded"]

Figure 4: Choose whether copyright in the deliverables belongs to the vendor, transfers to the client, or is shared.

Which option is best depends on the nature and price of the software. When comparing, ask which option each candidate assumes and why, and at the same time check whether, if you later ask another company to modify the app, you will be able to hand over the source code and have it fixed. The model contract also leaves the time at which ownership of the deliverables transfers to be set in the individual contract³.

Third-Party Software and Open Source

Besides the parts the vendor builds, a business app includes third-party software such as the OS and database, and free and open source software (FOSS). The model contract provides that when the vendor uses these, it proposes them in writing, showing why they are needed, the license terms and so on, and the client decides whether to adopt them³. Ask the candidates whether they can show a list of the products and libraries they plan to use and their terms of use.

How Acceptance Is Carried Out

Confirming that what was delivered meets the requirements and accepting it is called acceptance inspection. Under the model contract, the client, in consultation with the vendor, prepares an inspection specification that defines the test items, test data, test methods and test period. The client inspects the delivered software based on that inspection specification; if it passes, the client issues an inspection pass certificate, and if it fails, the client states the specific reasons in writing and requests corrections³.

flowchart TB
        accTitle: The flow of acceptance based on an inspection specification
        accDescr: Shows the client preparing an inspection specification in consultation with the vendor, inspecting based on it after delivery, issuing an inspection pass certificate if it passes, and stating the reasons in writing and requesting corrections if it fails.
        S["Prepare the inspection specification together"] --> N["Delivery"]
        N --> T["Inspect based on the inspection specification"]
        T --> J["Does it pass?"]
        J -->|"Pass"| OK["Issue an inspection pass certificate"]
        J -->|"Fail"| NG["State reasons in writing and request corrections"]
        NG --> T

Figure 5: In acceptance, the client inspects based on an inspection specification prepared in advance and returns the result in writing.

For a company without developers, preparing an inspection specification on its own is a burden. Ask the candidates how they will help identify the test items, what tests they will run on their side before delivery, and in what form they will hand over the results. Also decide at the estimate stage whether the client can set aside time to check the software within the acceptance period.

The Working Team and Subcontracting

Points of Contact and Meetings

The model contract provides that both parties appoint a responsible person and regularly hold a liaison council, at the frequency set in the individual contract, to discuss progress, risks and issues³. Ask the candidates who will be the client’s point of contact, how often meetings will be held, and who will write the minutes.

At a company that relies on a single person for development, work may stop if that person leaves. Also ask how handover works when the person in charge changes, and where the source code and documents are kept and who can see them.

Subcontracting

A vendor entrusting part of the work to another company is called subcontracting. The model contract’s subcontracting clause has Option A, which requires the client’s prior written consent to subcontracting, and Option B, which leaves it to the vendor’s discretion while allowing the client to request reports or demand that it stop. Under either option, the vendor imposes the same obligations on the subcontractor and bears the same responsibility for the subcontractor’s work as if it had done the work itself³.

flowchart TB
        accTitle: The model contract's two options for subcontracting
        accDescr: Shows that in the subcontracting clause, Option A requires the client's prior written consent and Option B leaves it to the vendor's discretion while letting the client request reports or a halt, and that under both the vendor concludes a contract imposing the same obligations on the subcontractor and bears the same responsibility as if it had done the work itself.
        SUB["Subcontracting clause"] --> A["Option A: client's prior consent"]
        SUB --> B["Option B: vendor's discretion"]
        B -.-> BR["Client can request reports and a halt"]
        A --> SAME["Same obligations on the subcontractor"]
        B --> SAME
        SAME --> LIA["Same responsibility as doing the work itself"]

Figure 6: Subcontracting is either subject to prior consent or left to the vendor’s discretion, and either way the vendor bears responsibility.

Ask the candidates whether they plan to subcontract and, if so, to whom and for what scope. Rather than whether they subcontract at all, the clue for comparison is whether they can name the party and the scope when asked.

Entrusted Data and Security

During development or maintenance, you may hand business data or customer information to the vendor. IPA’s “Information Security Guidelines for SMEs” says that when you provide important information to a contractor, you need to take into account what measures the contractor has in place, because even if information leaks through the contractor’s shortcomings, you will be held responsible for its management as the outsourcer. It also says that when you outsource part of your business, the contract must state, and both sides must agree on, the contractor’s responsibilities for information security and the measures it must implement⁴.

If the data you hand over includes personal data, supervision of contractors under the Act on the Protection of Personal Information (Article 25) also comes into play. The Personal Information Protection Commission’s guidelines list the necessary measures as selecting an appropriate contractor, concluding an outsourcing contract and keeping track of how the contractor handles the data. When the contractor subcontracts, they say it is desirable to receive a report in advance or give approval, among other steps⁵.

flowchart TB
        accTitle: Data handed to the vendor and what to check
        accDescr: Shows, for data handed to the vendor, checking the contractor's measures, agreeing on responsibilities and measures in the contract, and, if personal data is included, checking the selection of the contractor, the contract, how the data is handled and how subcontracting is dealt with.
        D["Data handed to the vendor"] --> M["Check the contractor's measures"]
        M --> K["Agree on responsibilities and measures in the contract"]
        D --> PD["Does it include personal data?"]
        PD -->|"Yes"| S["Selection, contract, tracking of handling"]
        S --> RE["Reports or approval for subcontracting"]

Figure 7: For data you hand over, check the contractor’s measures and the agreement in the contract, and for personal data supervise down to subcontracting.

As for the security of the software to be built, the model contract has a clause in which the specific features, management structure and cost-sharing are discussed and the security specification is finalized in writing. One of the draft clause options says it is to be finalized before the software development work begins³. Ask the candidates where they will keep the data you hand over, who will have access to it and how they will delete it when the work is done, and when and how the security specification will be decided.

Maintenance After Delivery

A business app is not finished when it is delivered. Bug fixes, keeping up with updates to the OS and surrounding software, and modifications to match changes in the business continue. Separately from the one for development, IPA also publishes a model contract for outsourcing maintenance and operation¹. What to include in the fixed-fee scope of maintenance and what to estimate separately is taken up in “How Should You Structure a Custom Software Development or Operations & Maintenance Contract?.”

Ask the candidates whether they will take on maintenance after delivery and, if so, the scope, how fees are determined and the point of contact for inquiries. Consider this together with the deliverables in the earlier section, so that you are not stuck if you end up asking a different company to handle maintenance.

Comparing Candidates with the Same Questions

The following table collects the points so far so that you can put them to the candidates in the same form. When you obtain competitive estimates, putting the questions from this table into your request document lets you line up the answers side by side and compare them.

When comparing the answers, watch for not answering what was asked specifically, making only verbal promises without putting them in writing, and flatly saying the client will have “nothing to do.” The first two leave you no way to check what was promised when a difference in understanding comes up later. The third does not fit with the model contract’s assumption that both the client and the vendor do work (Article 8)³.

Start Small and Evaluate

Under a multi-stage contract, the first individual contract can be concluded for a small scope, such as requirements definition support. In that phase you can see for yourself what documents the vendor produces, how it runs meetings and how it answers questions, and then decide whether to move on to the development contract¹.

flowchart TB
        accTitle: Evaluating a vendor with a small individual contract
        accDescr: Shows first concluding a small individual contract such as requirements definition support, checking the deliverables and the way the work is run, moving on to the development contract if satisfied, and otherwise considering other candidates.
        A["Small individual contract (e.g. requirements support)"] --> B["Check the deliverables and how work is run"]
        B --> C["Move on to the next phase?"]
        C -->|"Move on"| D["Individual contract for development"]
        C -->|"Reconsider"| E["Consider other candidates"]

Figure 8: Make the first phase a small contract, and decide whether to move on after seeing the deliverables and how the work is run.

When rebuilding an existing system, another approach is to make the investigation of the current system the first scope. In either case, if you make sure the client receives the deliverables of the first phase (the requirements definition document or the investigation report), they become material for switching to another company.

Related Articles

• Windows App Outsourcing and Custom Software Development: What to Sort Out Before You Ask
• How Should You Structure a Custom Software Development or Operations & Maintenance Contract?
• How to Work Correctly Under a Quasi-Mandate Contract and Avoid Disguised Contracting
• When You Inherit a System With No Source Code and No Documentation
• Where Should SMEs Start on Security?

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These are topic pages close to this theme. Starting from the article, you can go on to related services and other articles.

Services Connected to This Topic

This article leads to the following service pages. Start from the entry point closest to your situation.

Frequently Asked Questions

Questions commonly asked at the time of consultation about the topic of this article.

Can we judge whether a vendor is good or bad when nobody in the company understands the technology?

Even if it is hard to evaluate the quality of the code directly, you can ask each candidate the same questions and compare their answers on how requirements definition is run, the assumptions behind the estimate, how changes are handled, deliverables and copyright, acceptance, subcontracting, the handling of data you entrust to them, and maintenance. Whether the answers are specific and given in writing is what lets you compare them.

Isn't a company that fixes the price of the whole development up front the safer choice?

IPA's Model Transaction and Contract is built around a multi-stage contract that splits contracts by phase and estimates development only after requirements definition is finished. When you receive a proposal that fixes the total before the requirements are decided, check what that price assumes and how it will be handled if those assumptions change.

Should we have the source code delivered to us?

Under the model contract, what the deliverables include is defined in the individual contract. If you may later ask a different company to maintain the app, check before signing whether the source code and design documents will be included in the deliverables, and which option will govern copyright in the deliverables.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and bug investigation, with particular strength in projects where existing assets remain and in investigating failures whose cause is hard to see.