If you’ve never hired a software developer before, or if a past engagement went poorly, you may not know what a healthy development process looks like. This post lays it out plainly.

Phase 1: Discovery

Before anyone writes code, there should be a discovery phase. This is where you and your developer or development partner align on:

  • What problem are you actually solving?
  • Who are the users, and what do they need?
  • What does success look like?
  • What are the constraints: timeline, budget, existing systems?

A discovery phase typically involves one or more conversations, plus a written output: a requirements document, a scope document, or a project brief. If a developer wants to start coding before this step exists, that’s a red flag.

At Mengarelli Engineering, we prepare a detailed requirements document before we quote or start any project. It forces the right conversations early, before they become expensive to fix.

Phase 2: Scoping and Proposal

Once the discovery is done, you should receive a written proposal that includes:

  • What will be built (specific features, not vague descriptions)
  • What won’t be built (explicit exclusions prevent scope creep)
  • Timeline with milestones
  • Price: fixed if the scope is well-defined, estimated ranges if there’s genuine uncertainty

Read the proposal carefully. If something you discussed isn’t in the scope document, it won’t get built.

Phase 3: Active Development

During development, expect:

Regular updates. Weekly check-ins or progress updates are normal. Going silent for weeks is not. You should know whether the project is on track.

Iterative delivery. Good developers don’t disappear for two months and reappear with a finished product. They build incrementally and show you working software along the way so you can course-correct early.

Questions. Real-world development surfaces edge cases and ambiguities the original requirements didn’t capture. A developer who never asks questions is either building exactly what was written (even if it’s wrong) or making assumptions. Expect questions, and answer them promptly to keep the project moving.

Change management. If the scope changes during development (new requirements, changed priorities, discovered complexity), a good developer will tell you what that means for the timeline and cost before absorbing it. Scope changes mid-project are normal; what matters is that they’re communicated and agreed on explicitly.

Phase 4: Testing and Delivery

Before handoff, the software should be tested, both by the developer and ideally by real users or stakeholders. What to expect:

  • Functional testing (does it do what it’s supposed to?)
  • Basic edge case testing (what happens with bad input? empty states? errors?)
  • Deployment to a staging environment for your review

You should have time to review and request fixes before anything goes to production.

Phase 5: Handoff and Support

At the end of the project, you should receive:

  • Access to all code, repositories, and accounts
  • Documentation: at minimum, how to deploy and maintain the system
  • A clear path for ongoing support if needed

If a developer retains access credentials, owns the repository, or delivers undocumented code, those are problems. You paid for it. You should own it completely.

Red Flags to Watch For

  • No discovery phase or requirements documentation
  • Quote delivered in minutes without detailed questions
  • Vague deliverables in the contract
  • No milestone-based check-ins during development
  • Resistance to showing work in progress
  • Code delivered without documentation or repo access

What Good Looks Like

A good engagement feels like a collaboration. The developer understands your business, asks the right questions, delivers incrementally, communicates proactively about issues, and hands off something you can understand, maintain, and build on.

If you’ve had bad experiences before, it’s worth taking time to find a partner who operates this way. The process matters as much as the code.

Reach out if you want to talk through a project. We’ll tell you honestly whether we’re the right fit. If we’re not, we’ll say so.