A software project becomes easier to commission when you can explain what someone needs to accomplish, which information they need and who can change it. That gives a developer something more useful than a list of screens.
You do not need a finished technical specification to start. Bring a short brief, a few representative records and the people who understand the work. The aim is to make the purchase clear enough that you can compare proposals and recognize a working result.
This guide covers the questions to settle before commissioning custom business software, including an internal application or a system with customer access.
Describe a working day, including the awkward parts
Choose a person and follow one task from start to finish. What do they open, search for, enter, check and hand over? Include the missing information, corrections and interruptions that make the current process difficult.
Bring an empty form, an approved sample spreadsheet or a redacted record. Explain why each field matters. A screen labelled “Dashboard” tells a developer much less than “A supervisor needs to find overdue equipment checks and see who is responsible.”
Name the person who can resolve business questions during the project. They should have access to the people doing the work, including occasional users whose needs may differ from the daily administrator's.
Give each record a clear home
List the records the application will manage: customers, locations, equipment, orders, documents or visits. For each one, identify the system treated as the source of truth and the identifier that connects it to other records.
Decide which information the new software owns and which it only displays. If invoice status belongs to the accounting system, explain how the application obtains that status and what users see when it is unavailable or out of date.
For integrations, name the required information and permitted changes. Ask the supplier to confirm access, available interfaces and any licensing dependencies before including a connection in the delivery scope. Define how existing records will be cleaned, imported and checked before people rely on them.
Specify access in terms people can test
“Staff access” is too broad. Write down who can view, create, correct, approve, export and delete each type of record. Include what happens when someone changes role or leaves.
For customer access, specify which organisation and records each person may reach. Hiding a button is insufficient: the application needs to enforce the permission when the request reaches the server. OWASP recommends limited privileges, refusal where access has not been granted and permission checks on every request. OWASP authorization guidance.
Agree which changes need a history showing the actor, action and outcome. Keep passwords, access tokens and unnecessary sensitive information out of that history; OWASP's logging guidance identifies data that should be excluded or protected. OWASP logging guidance.
Use this brief as a starting point
Planning example: An equipment-maintenance company wants an internal equipment register and service history. The details below describe a proposed application, not a completed customer project. Copy the headings and replace the details with your own.
- Business goal: Let staff find an equipment record, understand its service history and record a completed visit without rebuilding that history from separate files.
- Users: Coordinators maintain equipment details. Technicians add visit notes for assigned sites. Supervisors review corrections and see outstanding work.
- Constraints: Plan for 12 staff accounts and about 3,000 equipment records, with desktop and phone use during site visits. Connectivity varies, so resolve whether offline entry is required. The buyer wants the first release before its next annual inspection cycle; confirm the required date, business reason and available investment range privately before quoting.
- Success: Staff can find a complete equipment history and record a visit without rebuilding it from separate files. Compare the current task with the proposed workflow using representative records; agree how to judge lookup effort, missing information and repeated data entry.
- Records and ownership: Each equipment record has a stable ID and links to a site and customer ID. The customer system remains the source of truth for customer details; the new application owns equipment and visit history after the agreed migration.
- First release: Search equipment, open its history, add a visit and export selected records. Keep invoicing and automated scheduling in the existing tools.
- Access: Technicians see assigned sites. Supervisors approve corrections to completed visits. Exports are restricted to agreed roles. Any later customer view must isolate each customer's records.
- Connections: Import an approved customer/site list and retain its IDs. Specify live updates only after confirming the source system's interface and access.
- Data handling: Use approved sample data during development. Agree storage locations, access, retention and removal for notes, attachments, exports, backups and logs.
- Acceptance: A designated staff member demonstrates the agreed tasks with representative records and checks the restricted actions before approving release.
If attachments are included, define allowed formats, size limits, access checks and storage. OWASP recommends controls for uploaded files, including type validation and storage choices that prevent unrestricted public access. OWASP file-upload guidance.
Agree how you will accept the result
Walk through the application as the people who will use it. For the equipment register, acceptance could include finding an imported record, entering a visit, correcting it through the supervisor's route and producing the expected export.
Also check that a technician cannot open another site's records, a departed user's access is removed and an interrupted save leaves a clear outcome. Compare imported totals and selected records with the approved source. Agree what to do if a check fails and who makes the release decision.
A demonstration can help you decide what to build. Acceptance should use the agreed working software, permissions and data-handling arrangements. Our proof and evaluation material shows the distinction between owned work, interface concepts and planning material.
Put ownership and ongoing support in the proposal
Ask who owns the commissioned code and designs, which third-party components are licensed and who controls the repository, hosting, domain and service accounts. Specify the documentation, export capability and access your team will receive at handover.
Agree responsibility for backups and restore checks, updates, monitoring and supplier changes. Record how faults are reported, the support coverage being purchased and how improvements are scoped. An ongoing arrangement should describe the work and responsibilities clearly enough for both sides to operate it.
You can discuss a focused project or a longer program through our engagement options. Tell us what your team needs to do, who will use the application and which tools are involved. A rough outline is enough to begin the conversation.