Contents
How to commission custom software? Start with a document, not a contract: a brief that names the problem, the users, the data and how success will be measured. After it comes a short discovery or prototype phase, a contract that settles code ownership and how acceptance works, acceptance testing on real data, and a plan for support after delivery. Most projects that miss their target went off course at step one.
In a web development class the founder had an assignment with a one-sentence brief: make a website. Most of the class stopped once the tabs worked. He worked until 3 AM and was back at it by 8 AM, because the transitions could be smoother.
Both results met the brief.
A brief that doesn't define done accepts both, and the client doesn't find out which one they're getting until delivery day.
Before commissioning: do you need custom software
Check three cheaper options first: an off-the-shelf product that does the job with some configuration, a feature in software you already own and don't use, or a well-structured Excel file with a few clear rules. If one of those solves it, you don't need custom software, and you don't need us, or anyone like us.
Custom software earns its cost when the company's workflow runs on the company's own rules, when data moves between several programs by hand, or when a manual error in a repeated task has a known cost. Digital transformation for engineering firms covers how to pick the first process.
Writing a custom software brief
A brief describes the problem, not the solution. "We want a dashboard" is a solution. "The project manager spends hours every week merging reports from several programs in Excel, and the numbers don't reconcile" is a problem, and a developer can propose the right fix for it. If you already have a solution in mind, rewrite it as the problem it's meant to solve.
A complete brief covers:
- The current workflow: what's done, by whom, in which program, and how often.
- Users: how many, in what roles, how comfortable with software.
- Data: inputs and outputs, file formats, and the programs the new system has to talk to.
- Constraints: infrastructure, security, versions of existing software, budget.
- Success criteria: measurable ones, the time a task takes, the number of errors, that acceptance testing will check.
- Out of scope: what isn't being built this round.
The last item matters as much as the rest. Anything not ruled out drifts into scope during the project, and its time and cost come with it.
Discovery and a prototype before the full build
When the problem isn't fully defined yet, a short, separate phase before the full build takes out the main risk. The UK government's service manual calls it discovery: understand the users, the constraints and how success will be measured, without building anything. Its output is a decision, go on or stop, and stopping there is a legitimate result.
Then a prototype or MVP gets built with the fewest features needed and tested with real data and real users. Building in stages shows what works, what needs to change, and what shouldn't be built at all, before the full investment is made. That phase is covered in MVP development for internal tools.
Estimates and payment models
There are two main models. Fixed price: scope and cost are set before work starts, and every change needs a separate agreement. It fits when the brief is complete and stable. Time and materials: you pay for hours worked, and scope can move during the project. It fits when part of the need is still taking shape.
Either way, tie payments to delivery and acceptance, not to the calendar. Each milestone has a specific, testable output, and it's paid once that output is accepted. An estimate given before discovery is a guess, and it should be revised after.
The software development contract and code ownership
Paying for development doesn't automatically make you the owner of the code. Under many legal systems the developer keeps the intellectual property unless the contract expressly transfers it, and developers sometimes grant only a licence, especially when they reuse their own earlier code. If ownership matters to you, it has to be written down.
The contract should also cover: delivery of source code and documentation at each milestone, how open-source libraries and third-party code are handled, confidentiality of the company's data, a bug-fix period after delivery, and what happens if the contract ends early. If you're worried about the developer staying in business, source code escrow is an option. IP rules differ by country; have a lawyer review the final text.
Software acceptance testing
Acceptance testing is where the client confirms the software matches the brief. It runs against the success criteria written in the brief, on the company's real data, by the people who'll use the software every day, not only by the manager who ordered it.
Defects go on a written list, each with a priority and whether it has to be fixed before acceptance. Acceptance is given in writing, and that milestone is paid after it. A success criterion that wasn't written down at the start turns into a disagreement here.
Support, maintenance and handover
Software keeps changing after delivery. The programs it connects to release new versions, users find new needs, and bugs appear that testing didn't catch. An add-in built for Revit has to be checked against every annual Revit release, and rebuilt when needed.
Before signing, settle how support works: response time for bugs, the cost of changes and updates, and the documentation handed over so another team could pick up the work later. What to look for in a developer is covered in choosing a Revit plugin development company, and building custom tools for technical teams is our AEC workflow automation service.
Conclusion
Commissioning custom software starts with a brief that sets out the problem, the users, the data, the success criteria and the scope. A discovery or prototype phase takes out the main risk before the full build, the contract settles code ownership and acceptance, and acceptance testing runs against the same criteria. "Make a website" is met by a few working tabs and by something far past them. The brief is the only place that difference gets decided. What's the first thing you'd change?
FAQ
Where do you start when commissioning custom software?
With the brief: the current workflow, the users, the data, constraints, success criteria and what's out of scope. It's the basis for the estimate, the contract and acceptance testing.
What should a software requirements document include?
The problem rather than the solution, the users and their roles, inputs and outputs, the programs the system has to connect to, measurable success criteria, and what isn't being built this round.
Is fixed price or time and materials better?
Fixed price suits a complete, stable brief. Time and materials suits a project where part of the need is still forming. In both, tie payments to accepted milestones.
Do we own the code if we pay for it?
Not necessarily. Under many legal systems the developer keeps the IP unless the contract expressly transfers it. Transfer of ownership and delivery of source code both need to be in the contract.
What is software acceptance testing?
The stage where the client checks, against the brief's criteria and on real data, whether the software meets the need. Acceptance is given in writing, and the milestone is paid after it.
Why build a prototype before the full build?
A prototype shows, for less money, which assumptions hold and which features aren't needed at all, before the main budget goes into building them.
What support do we need after delivery?
Fixes for bugs testing didn't catch, updates for new versions of connected software, and new changes. Agree response times, costs and the documentation you'll receive before signing.