How should a custom software project start?
Discovery and written scope first—coding without them burns budget.
Healthy projects do not start with “just start coding.” Discovery comes first: who uses it, which steps exist, what data is entered, which reports matter, which integrations are mandatory. The conversation can be short; the output should still be written.
Then priorities: an MVP that solves one or two critical flows. “Everything in v1” inflates time and risk. Jumping into build without approved flows or a clear screen path multiplies rework.
Proposals should cover scope, phases, acceptance ideas, change handling, and maintenance direction. On your side, decision-makers and real test users must be available—or the timeline stalls for non-technical reasons.
Good start: clear pain, clear success measure, clear first delivery. Code comes after that.
