Before You Buy Software, Name Who Will Maintain It

Every software decision leaves someone keeping the work running after setup is finished. To decide whether to build, buy or integrate software, describe the work that needs to change, name the obstacle, and pick an approach the business can actually maintain. A tool belongs on the shortlist when you can say both the job it will do and who will look after it.

Describe the work before choosing software

Start with what a customer or employee experiences. A customer asks for an update and the office can't tell whether the job is ready. Staff copy information between systems because the next person can't find it. Those descriptions give a software conversation something concrete to fix.

"We need better software" leaves the problem open to interpretation. A developer hears a request for a custom app. A vendor hears a need for their product. The employee living with the problem may mean that nobody records changes to the job. Describe that gap before anyone proposes a solution.

A healthcare operator who has bought and led businesses went looking for a healthcare services business where technology would change what limits growth. Many healthcare businesses grow by adding locations and clinicians, so even strong demand is hard to serve. That test is a good one for any owner: which barrier does this technology move? Replacing a tool because it's old isn't a reason on its own.

A business guide asks owners what game they're trying to win (better execution, more speed, or getting past some specific constraint) and what obstacle stands in the way, before they choose a management system. For software, that means saying what better execution looks like in the work itself. The goal might be that staff can answer a customer without asking the owner to reconstruct the history.

Write the problem in plain words

Take a made-up service business where the office struggles to invoice after jobs finish. The field team marks jobs complete, but the office still has to ask whether the customer approved extra work. The complaint arrives as a request for an invoicing tool. What's actually missing is the approval.

That changes the questions. Can staff find the approval in an existing record? Does someone need to capture it? Does the business agree on what "approved" means? Each answer points somewhere different. Buy a product before that conversation and the same uncertainty moves onto a new screen.

Write a short description the people doing the job can correct:

• What starts the work, and what does a finished result mean?
• Where does someone wait, retype an entry or ask the owner for help?
• What information or decision is missing at that point?
• What does the next person need in order to act?
• Which responsibility stays with a person after any software change?

Keep this separate from a feature wish list. Its job is to show whether software can address the problem at all. If the team is still choosing which work to tackle, start with what to automate first.

Building versus buying

Building and buying leave different obligations with the business. A custom tool leaves you defining how it behaves and arranging upkeep, indefinitely. A purchased product gives you an existing design to live within.

Describe the capability you need before treating a gap as a reason to build. In the invoicing example, the question is whether staff can find and interpret the customer's approval. Custom software may be worth considering for its fit, cost or control, even when an available tool meets the requirement. The business still needs to maintain what it builds.

For a purchase, ask what staff will still do outside the product. A feature may exist and still leave them reconciling records or handling exceptions by hand. That leftover work belongs in the problem description and in the maintainer's job.

The build-versus-buy software comparison covers the detailed trade-offs in fit, maintenance, outside support and adaptability.

Is connecting what you have enough?

Integration means connecting tools so information moves between them. It's worth considering when each tool does its job but the handoff between them creates repeated work. The gap may be the connection, not the software on either side.

In the invoicing example, suppose the approval already sits in the job record and the office needs it in billing. Connecting the two could fix the handoff. If nobody captures approval, no connection can supply the missing decision.

Workflow automation gives the background. For the software choice, stay focused on what information has to move and what the person receiving it needs to understand.

Check what your current tools already do

Ask the people who use the current systems what works and where they leave the system to finish a task. A tool may hold customer history the team trusts. Information living in several places isn't, by itself, a reason to rip a tool out.

Then check that records mean the same thing. To the field team, "complete" may mean the work on site is done; to the office, it means the paperwork is ready. Moving that status between tools carries the confusion into another part of the business. Agree on the meaning first.

Integrations need an owner too. Someone has to know which tool holds the record the business relies on, and who settles a disputed result. A connection can be the right call and still create support work.

You can mix approaches: buy a product and connect it to an existing tool, or commission a small custom piece around purchased software. Say who is responsible for each part. The people who use and maintain a mixed setup should be able to explain it.

Name who will maintain it

The person who approves a software decision often isn't the one who keeps it running. Bring the future maintainer in while the choice is still open. They can tell you what they'd need and where the proposal leaves them depending on someone else.

Name the missing capability before assigning the job. It might be technical upkeep, clear reporting, agreement on how the work should run, or someone who resolves questions. Handing it to the most tech-comfortable employee doesn't give them the authority or operating knowledge it needs.

Put the ongoing obligation in plain words. Someone answers staff questions, decides whether a requested change makes sense, and gets help when the system misbehaves. That's part of the choice, alongside the setup. Automation costs small businesses can miss covers the wider list.

Ask the maintainer before committing

• Can you explain which business problem this software is meant to fix?
• Which parts would you maintain, and which would need outside help?
• Who answers questions about what a record means or what happens next?
• What access, documentation and authority would you need?
• Who covers if you're unavailable?
• What would the team still do by hand, and who owns that?
• How would you keep the system in step when the business changes how it works?

Write down the work problem, the missing capability and the person who'd maintain the result, and take it to the maintainer before you choose.

Source notes

Guest remarks are paraphrased from interviews with a healthcare operator and a business guide; examples are our own.