• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

Begin with domain experience, not the number of logos on the website. Request a couple of engagements that match your technology stack, and then ask specifically whether those engineers are still with the company. A serious vendor is happy to connect you with the engineers. Answers that name nobody at this stage almost always mean you are talking to a reseller.

The contract deserves more attention than the sales deck. Three sections matter more than the rest: intellectual property assignment, non-disclosure, and exit terms and handover. All the work product has to transfer to you once invoices are settled, along with source code, designs and infrastructure as code. Watch for language that leaves framework code outside the transfer, as it is usually the part you cannot replace later.

Find out how the estimate was built. An honest estimate comes with a list of assumptions, a breakdown by feature or module and an explicit range. A fixed-price contract is only reasonable when the requirements are stable and documented; when the scope is still moving the provider adds a risk premium and you pay for uncertainty either way. A time and materials contract-and-materials model shifts that risk to you, so it requires visible weekly reporting and a spending cap.

How the work is run beats headcount. Ask how change requests are handled, who writes the acceptance criteria and what the QA setup looks like. A well-run team can walk you through running software solutions for government rather than status reports. Written acceptance criteria stay the only reliable protection against the it-was-never-in-scope conversation.

Before signing, think about the end of the engagement while the relationship is still good. Require that the code repository sits on infrastructure you own from day one, and that documentation is written as you go rather than left to the end. A provider confident in its own work accepts it without argument; hesitation here says quite a lot.