Engineering field notes
Start a software project with a decision, not a deadline.
A practical way to scope the first useful version before committing to a build.
What should the first version prove?
A useful first version answers one important question. Will a user complete the task? Can the data support the decision? Can an integration work within the organisation’s constraints? Choose the question before listing features.
Write acceptance criteria a person can check.
Name the user, the input, the expected output and what should happen when the input is missing or wrong. “A dashboard” is a deliverable. “The operations manager can identify overdue jobs and see the source record” is a testable outcome.
Find the expensive unknown early.
Access to data, permissions, legacy integrations and the availability of reviewers can determine the schedule. Test those assumptions before spending most of the budget on polished screens.
Price and schedule the agreed scope.
Estimate after discovery, with milestones and a process for changes. A small prototype and a supported production system have different requirements. We agree the timing and cost of an engagement in writing; there is no universal 14-day delivery or refund promise attached to this article.
Leave a useful handover.
A first release should make the next decision easier. Document what was tested, what remains uncertain and what the organisation would need to operate or extend it.
Explore the Data Lab · Discuss a project
Written by DataXLR8. This is practical guidance, not a claim about measured client results.