Product
What a software development company should deliver before the first sprint
· 7 minute read · Addmarker
Before a sprint starts, a software development company should be able to show the problem, the edges of version one, and how you will know it works.
A sprint is not a substitute for a decision
Agile is a way to learn in public. It is not permission to begin without a point. Before the first sprint, you should be able to read a page that says who the software is for, what they can do on day one, and what they will not be able to do yet.
If a vendor cannot write that page, more stand-ups will not create it. You will get activity, tickets, and a product that feels busy and unclear.
The edges of version one
List the paths that are in: sign up, the core task, the admin action someone on your side must take, the failure the user will actually hit. List the paths that are out, in the same document, so they do not re-enter as “small” favours.
A software development company that only shows you the happy path is decorating. Empty states, permission errors, and the first support request are part of the product.
A sketch of the system, in commercial language
You do not need a novel about architecture. You do need to know where the data lives, what you are integrating with, and which pieces you will own. If there is an AI feature, the sketch should say what the model is allowed to draft and what a person must approve.
Ask who can ship a change after the engagement, and whether the repository is yours. Code you cannot leave with is not an asset. It is a lease.
How you will know the slice works
Pick a demonstration that is not a slide. One user completes the core task in a staging environment, with realistic content, including one thing going wrong. That is the bar for the first release, not a feature count.
Then agree the rhythm: what is reviewed weekly, what “done” means for a ticket, and how a change to scope is written down. Sprints are useful after that. They are theatre before it.