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

Look first at relevant experience, not the length of the client list. Ask to see two or three projects that sit close to your technology stack, and then ask specifically who actually wrote that code. A serious vendor will put you on a call with the engineers. Vague answers at this stage usually mean the demo work came from somewhere else.

The agreement needs more scrutiny than the proposal. Three clauses do most of the work: assignment of intellectual property, go consulting services the NDA, and termination and handover. All the work product has to transfer to you on payment, including source code, designs and infrastructure as code. Be careful with language that leaves so-called reusable libraries in the vendor's hands, since it is usually the dependency that makes switching painful.

Find out how the estimate was built. A credible estimate comes with the assumptions behind it, performance php vs python a breakdown per feature and an explicit range. A fixed-price contract is only reasonable when the scope is genuinely frozen; in any other case the provider pads the number and you pay for uncertainty either way. Hourly billing shifts that risk to you, so it needs visible weekly reporting and a spending cap.

How the work is run matters as much as team size. Establish how a new requirement enters the plan, who writes the acceptance criteria and how testing is organised. A mature team will be able to demonstrate running software development blog rather than status reports. Acceptance criteria in writing remain your only real protection against an argument at delivery time.

Finally, consider the end of the engagement while the relationship is still good. Ask that the repository stays under your account from the beginning, and that a readme and architecture notes are kept current as the code changes. A provider confident in its own work says yes immediately; hesitation here says most of what you need to know.