Software project guide
How to plan a bespoke software project
A practical guide from Artemis Software for businesses and public-sector teams deciding what to build, what to improve and how to keep software dependable after launch.
What is bespoke software?
Bespoke software is an application designed for a particular organisation’s processes, users and information. Unlike a standard subscription product, it can accommodate workflows that do not fit an existing package. It also brings responsibility for maintenance, security and future changes. Before commissioning a build, compare the cost and limitations of configuring an existing product with the cost of developing and supporting your own system.
When should you build, improve or replace a system?
Build new software when an important business requirement cannot reasonably be met by an existing product. Improve an existing application when its foundations remain suitable but users face specific problems. Consider phased modernisation when ageing technology makes changes difficult or support uncertain. Replacement is not always the safest starting point: first assess the application, its dependencies, its data and the consequences of interrupting the live service.
Explore legacy modernisationWhat should a software project brief include?
Describe the problem in everyday language, who experiences it and what a better outcome would look like. Include the current workflow, systems that must connect, information being processed, access requirements and any fixed deadlines. Separate essential requirements from later improvements. Give examples of awkward cases, not just the ideal journey. A useful brief explains the result you need without prescribing every technical decision before discovery.
How should security and integration be planned?
Identify sensitive information and decide who needs to view or change it. Discuss retention, audit records, backups and recovery early, alongside the relevant contractual or regulatory requirements. For integrations, establish which system owns each piece of information, how updates move between systems and what happens when a connection fails. Visible errors and a clear recovery process matter as much as successful data transfers.
Read about integration and automationHow can you assess a software delivery partner?
Ask for relevant delivery evidence and an explanation of the supplier’s actual role. Establish who will make technical decisions, how progress will be demonstrated and how changes to scope will be agreed. Confirm ownership of source code, documentation and access credentials in the contract. A small discovery phase or proof of concept can help resolve an important uncertainty before committing to a larger programme.
See Artemis delivery evidenceWhat happens after launch?
Agree support responsibilities before the system goes live. Cover monitoring, incident handling, software updates, recovery procedures and a process for prioritising improvements. Budget for ongoing ownership rather than treating launch as the end of the project. Artemis builds, improves and supports software, with ongoing application ownership available. The right arrangement depends on the application’s importance, its users and the capabilities of the team operating it.
Explore managed application ownershipDiscuss your next step
Tell us about your current software, the problem you need to solve and any delivery constraints. We can discuss whether discovery, a targeted improvement or a new application is the appropriate next step.
Discuss a software project