Two proposals for the same software cannot be compared on price as long as they do not answer the same things. One includes migrating your data and the other does not even mention it; one hands you the code and the other does not say who owns it; one fixes the price and the other estimates it. The only thing they have in common is the figure at the bottom.
For them to have something more in common you need eleven questions, and the time to ask them is the first meeting, when you have not signed anything yet and asking costs nothing. They go in the order that conversation usually takes, what is going to be built, what it is going to cost, who it will belong to and who will do it, each with the answer you should hear. And, where it is relevant, with the one I give when I am asked.
What is going to be built
What is left out?
The list of what a project includes always looks complete. The one that really draws its boundary is the other one, the list of what it does not include: a scope that only lists what is in leaves everything else open. Ask for the exclusions in writing: which integrations are not touched, on which devices it does not have to work, which reports are left for later.
How will we know it is finished?
Every feature should carry an acceptance criterion: a sentence that both of you can check without arguing. If the answer is “when it works”, there is no criterion yet. A real one looks like this:
Given an order with three lines and a valid coupon,
when the customer confirms the payment,
then the system issues the invoice, deducts the stock
and sends the confirmation email in under a minute.
With criteria like that, accepting a delivery stops being a matter of opinion.
What am I going to see, and when?
The sooner you test what has been built, the sooner the course is corrected and the cheaper the correction is. Ask how often you will receive something that works and where you will be able to test it. There is one answer you do not want to hear: “at the end”.
I set up a test environment in the first sprint and deliver every week, with its progress report.
What it is going to cost
What happens if I change my mind?
You will change your mind, and that is fine: a system is better understood once it starts being used. What matters is what happens then. Find out how a change is requested, how long it takes to quote and whether it moves the calendar.
Since I work in one-week sprints at €1,190, each with its scope and its price fixed, a change goes into the next sprint without undoing the previous one. If it extends the project, I propose the sprints that are needed to you in writing, with their cost, and you decide whether we carry on.
How and when is it paid?
The payment schedule tells you who bears the risk: you, if you pay everything up front; the developer, if they collect everything at the end. The reasonable place is in between: payments that follow the deliveries, with none of them advancing much more work than you have already seen.
My sprints are billed in blocks of two, half at the start of the block and the other half at the end; a single sprint is paid in full before starting. In no case do you advance more than one week of work.
What will I keep paying afterwards?
Custom software does not end on delivery day: there remain the hosting, the domain, the licences for external services, the backups and the security updates. Ask for the monthly figure before signing, item by item, and ask in whose name each one is. What is in your name you take with you; what is not depends on someone else.
If the system is deployed on your servers, there is no fee left with me. If I host it, the hosting goes into a maintenance plan sized for that system and broken down in the proposal.
Who it belongs to
Who owns the code?
The answer you should hear is “you”. The law, however, does not hand it to you. The Spanish Intellectual Property Act attributes the rights to a program to the company when one of its employees writes it; it does not say the same about an external provider. With a provider, the exploitation rights belong to whoever writes the code until a contract assigns them.
And that assignment has small print. If the contract sets no term, the law leaves it at five years; if it sets no territory, it narrows it to the country where it is signed. A well-drafted clause assigns, exclusively, all the exploitation rights, including the right to modify the program, for the whole world and for as long as the law allows.
Everything I develop and deliver is yours: the complete code with its documentation and, if you want it, the repository in your name. With the code, the repository and the access details in your hands, the project carries on with whoever you decide.
What does the contract say, besides the price?
A development contract does not need to be long. It does need to cover these points:
- The scope, with its exclusions and its acceptance criteria.
- The price, the payment schedule and what happens if the project stops halfway.
- The assignment of the exploitation rights, with term and territory.
- The delivery of the source code, the documentation and the credentials for every service.
- The third-party pieces the system carries, such as open-source libraries, which keep their own licence.
- The confidentiality of what you share.
- The data processing agreement the GDPR requires, if the system handles personal data.
What I describe here is general information from the trade; drafting a specific contract is a lawyer’s job.
What documentation will I receive?
Useful documentation is the kind that lets another developer pick up the work: how the system is deployed, where the data lives, what configuration each environment needs, what every scheduled task does. A short, up-to-date one is worth more than a long one nobody maintains.
Who will do it
Who is going to write the code?
Ask who is going to program the system and whether you will be able to talk to that person. When an explanation passes through several hands before reaching whoever programs, something is lost in each one.
In my case there are no hands in between: whoever analyses the job is whoever builds it and whoever answers for it afterwards.
What do you need from me?
A custom project also asks for your time: deciding, providing real examples, testing each delivery. Find out how many hours a week and at what moments. For me, one point of contact who validates each delivery is enough; but that person has to exist, and have the room to do it.
And now, the price
Go back to the two proposals from the beginning. With the eleven answers of each one on the table, either they describe the same thing or you can see where they part ways, and the figure at the bottom finally means something: you know what every euro buys.
If you want to see prices with their scope beside them, in Four examples of custom software I describe four real jobs with their weeks and their price.
The list, on one page
The eleven questions, to take to the first meeting:
- What is outside the scope?
- How will we know each feature is finished?
- What will I be able to test, and how often?
- What happens if I change my mind?
- How and when is it paid?
- What will I keep paying after delivery, and in whose name?
- Who owns the code, and where does the contract say so?
- What does the contract say, besides the price?
- What documentation will I receive?
- Who is going to write the code, and will I be able to talk to that person?
- How much of my time will the project need?
Frequently asked questions
What should a custom software development contract include?
At the very least, the scope with its exclusions, the acceptance criteria, the price and the payment schedule, the assignment of the exploitation rights to the code, the delivery of the source code and the documentation, confidentiality and, if the system processes personal data, the data processing agreement the GDPR requires.
Who owns the intellectual property of commissioned software?
Whoever writes it, unless the contract says otherwise. The Spanish Intellectual Property Act only attributes the rights to the company automatically when the program is created by one of its employees. With an external provider, a written assignment clause is needed; if it sets no term and no territory, the law limits it to five years and to the country where it is signed.
Is it better to hire a developer by the hour or at a fixed price?
A fixed price leaves the risk of the estimate with whoever makes it, which is who can control it. I quote in one-week sprints at €1,190, each with its goal and its price fixed: the cost is known before starting and the project can stop at the close of any of them.
What should you ask before hiring a software developer?
What is outside the scope, how a delivery is checked as finished, what happens when the requirements change, how much it will cost to maintain the system afterwards, who owns the code and who you will be talking to during the project. The full list is at the end of this article.
Should I sign a non-disclosure agreement before explaining my project?
If preparing the proposal means sharing sensitive information, it is reasonable to ask for one. I sign whatever non-disclosure agreements you need, also before the initial proposal.
