Library / Projects / KEVOS® original book
Commissioning Custom Software
How an engineering or manufacturing business buys bespoke software from a developer and gets what it needs, on budget, and owns the result
Commission custom software from a developer: decide build or buy, write a brief, choose a pricing model, contract for ownership, run increments, test, go live and support it.
Start readingAbout this book
Sooner or later, most growing engineering and manufacturing businesses pay someone to build software. A job-tracking app for the shop floor, a quoting tool, a portal for customers, a connection between the accounting system and the machines. The owners are usually expert in their own work and inexperienced at buying software, and the developers they hire are usually expert in software and inexperienced in the business. Both sides mean well. Projects still go over budget, deliver something different from what was imagined, or leave the business dependent on one developer it cannot replace.
This book is for the buyer. It covers deciding whether to build at all, writing a brief developers can price, choosing a developer and a pricing model, contracting so the business owns what it pays for, running the work in short increments, testing and accepting the result, going live on the shop floor and supporting the software for years. Each chapter works one decision through the running case with real numbers and ends with an exercise and its worked answer.
It assumes no software background. Where a technical idea matters, the chapter explains it in plain terms.
The running case
The book follows a fictional precision machining business of about 40 people with 18 CNC machines, running about 350 jobs a month. Jobs are tracked on paper travellers and a supervisor’s spreadsheet. Nobody knows, without walking the floor, which jobs are late, how long each operation really took or how much material was scrapped. The owner decides to commission a shop-floor job-tracking app, used on tablets at the machines and connected to the business’s existing accounting and job system, from a local software developer.
All quantities, prices, hours and results are invented for teaching. This is an illustration. None of it describes a KEVOS® client, supplier or project. Money is in Australian dollars, excluding GST unless stated.
How to use the book
Read Chapters 1 and 2 before speaking to any developer: they decide whether to build and what to ask for. Chapters 3 and 4 cover choosing and contracting, and Chapters 5 to 8 cover running, accepting and living with the software. The companion books CAD Automation by the Numbers and Engineering Software You Can Sell cover building software inside an engineering firm and selling it to others.
Source limits and professional responsibility
A book on developing and distributing CAD software was supplied for this series. It informed only the developer’s-eye view of planning and deployment. The structure, case, calculations and figures here are original. Contract, intellectual property and consumer law points are general information, not legal advice. Software contracts are worth a lawyer’s review, and software that controls machines, affects safety or handles personal information carries obligations beyond this book’s scope.
Who this book is for
Owners, operations managers and engineers at small and medium engineering and manufacturing businesses who are paying a developer to build software they will depend on, often for the first time.
What you will learn
- Decide honestly between buying, configuring and building software, with five-year costs.
- Write a brief and acceptance criteria that developers can price and that settle disputes.
- Choose a developer and a pricing model, and contract for ownership, data and a way out.
- Run the work in short increments with visible progress, change control and budget tracking.
- Test, accept, go live and support the software so it keeps delivering after the developer leaves.
Inside this book
Chapters
- 01Decide whether to build at allCompare buying, configuring and building software on fit to must-have needs and five-year cost, include the hidden costs of each, and build only what nothing else can do.
- 02Write a brief developers can priceWrite a software brief with the problem in numbers, must-haves as user stories with acceptance criteria, data volumes, integrations, quality needs and a budget range.
- 03Choose a developer and a price modelEvaluate software proposals on understanding, approach, team, price and support, check references, compare fixed, hourly and capped pricing, and consider paid discovery.
- 04Contract for ownership and exitWrite a software contract so the business owns its code and data, receives source as it is built, pays against accepted increments, has a warranty period and can leave without losing the system.
- 05Run the work in short incrementsRun a software build in three-week increments with working software shown on the floor, one product owner deciding priorities, visible budget tracking and change control.
- 06Test and accept the softwareTurn acceptance criteria into tests, test the whole system under real load and integrations, classify defects by severity, run old and new in parallel and accept only against agreed rules.
- 07Go live and train the floorPlan a software go-live on the shop floor: readiness checks, the right date, short role-based training, floor champions, open work in progress, a paper fallback and close support for the first weeks.
- 08Support, host and plan for the long runSupport custom software for years: a support agreement with clear response times, hosting and accounts the business controls, security updates, measured benefits and a yearly exit check.
Apply This in Practice
No tool has been matched to this book yet. Browse the related tools: Projects & Improvement tools
References and source notes
The manuscript and worked examples are original KEVOS® writing. References inform particular concepts; their authors do not endorse this book. Web references were consulted on 26 October 2026.
- Luke Malpass, AngelSix. SolidWorks 2009 API: Advanced Product Development, first edition (2008–2013). Supplied source, used only as background on how software tools are planned, built and deployed from a developer's point of view. No text, code or structure is reproduced.
- Digital Transformation Agency, Australian Government. Digital Sourcing Framework (current web page). Background on the Australian Government's principles and contract templates for buying digital products and services, referred to in Chapter 4 as a useful public model. Its clauses are not quoted.
- Australian Competition and Consumer Commission. Businesses urged to remove unfair contract terms ahead of law changes (2023). Source for the unfair contract terms changes from 9 November 2023, relevant in Chapter 4 to standard-form contracts offered to small businesses.
- Business Victoria, Victorian Government. 4 intellectual property considerations for software ownership (current web page). Background for Chapter 4: a contractor generally keeps copyright in software it writes unless it is assigned in writing.
- Kent Beck and others. Manifesto for Agile Software Development (2001). Background for the short, incremental way of working described in Chapter 5. Paraphrased, not quoted.
- ISO and IEC. ISO/IEC 25010, Systems and software quality models (current edition). Named by number and scope only as the international model of software product quality characteristics, used as a checklist prompt in Chapter 2.