Independent software selection and implementation
We are paid for the assessment, not by the vendors we recommend, and our fee does not change based on which product you choose. We work out what your business actually needs, measure the real options against it, and help you put the winner in — or hand the whole thing to whoever you would rather use.
Most people who ask us to help choose software have already sat through the demos. Every product looked capable, every salesperson said yes, and nothing in the room told them which one fits the way their business actually runs.
That is not a failure of attention. A demo is a sales tool: rehearsed, on clean data, running a workflow the vendor picked. Start there and the products end up defining the criteria, so you compare the features you were shown rather than the things your business needs. The requirements nobody wrote down stay invisible until implementation, which is the most expensive possible moment to find them.
We run it the other way around, which is what an independent software selection consultant is actually for. Requirements first, agreed and written down. Then the products get measured against them, and a demo becomes a test with an agenda instead of a presentation.
Where independence actually shows up
Independence is a structural claim, not a personality trait, so here is exactly what it means.
We are paid for the assessment, not by the vendors we recommend. Our fee does not change based on which product you choose, so there is no version of this engagement where one answer earns us more than another.
The requirements and the recommendation are written to be handed to someone else. The vendor's own team, your internal IT or another implementer can pick them up. That is deliberate, and it is what makes the advice worth paying for.
We write custom software, so we have an obvious incentive to recommend it. That is precisely why we say plainly when a product you can buy covers the job — it will be faster, cheaper and better supported than anything we would write for you.
Where we hold a partner or technical integration relationship with a vendor, you hear about it before the evaluation starts, not after. Neutral does not mean we have never worked with anyone; it means you know what our interests are.
How a selection runs
Software gets chosen by people who will not use it daily, which is the most common reason it fails. We take requirements from management, from office and admin, and from the field crew who will use it on a phone in the rain. All three or the decision is made half blind.
"Must have job costing" is worthless — every product claims it. We write criteria specific enough that a product either meets them or does not, weighted so that trading a nice-to-have against a deal-breaker is an explicit decision rather than an accident.
Hard constraints eliminate first. What survives is normally three products, scored against the same weighted criteria so the comparison is like for like. Where a product cannot be judged on paper, the vendor gets a scripted scenario from your business rather than driving their own.
You get the scoring, the reasoning and the trade-offs in writing. There is almost always something you lose by picking the winner. A recommendation claiming a perfect fit has not been tested hard enough.
What gets assessed
These are the things that decide whether the product survives contact with your business.
A decision that cost us the build
A plumbing contractor came to us for a custom field-service system, and we prototyped one. Working through it with them, the conclusion was that we should not build it. Their job lifecycle — schedule, dispatch, site, invoice — is the same shape as most service businesses in the country, and several mature products already do it properly. We told them to buy one instead. They did, and it was the right call.
That recommendation cost us the development work. It is also the clearest evidence we can offer that the advice is not steered: the incentive ran one way and the answer ran the other.
The opposite answer is just as real. Another client's operation genuinely was not a variation on anything you can buy — the way they run work is the reason they win it. Forcing that into a generic product meant either paying to bend the product out of shape or bending the business to suit the software, so they got a custom build. And a third group needs neither: their existing systems are individually fine and collectively disconnected, which is an integration problem, not a selection problem.
Working out which of the three you are looking at is most of the value in the engagement.
Construction, trades and field service
Most of our selection work sits here, and it is genuinely different. The office and the field need different things from one system. Compliance evidence has to survive an audit years later. Jobs change shape once they start. Half the workforce uses the product outdoors, on a phone, with patchy signal — and will quietly stop using it if it fights them.
We work day to day across the platforms these businesses run on: project management, job and service management, estimating and tendering, safety and site access, and the accounting systems underneath all of it. We have integrated them to each other, which matters during an evaluation, because the useful question is rarely "is this a good product". It is "is this a good product for a business shaped like ours, and will it talk to the things we are keeping".
After the decision
Choosing well and implementing badly produces the same outcome as choosing badly, so we can stay on and make the thing land: configuring it around the process you agreed, moving the data, connecting the systems either side of it, building the reporting, and being there while your people start using it in anger.
We are equally happy not to. You can hand the requirements and the recommendation to the vendor's own professional services team, to your internal IT, or to another implementer entirely. The documents are written to be picked up by someone else — that is deliberate. If you do use someone else and it drifts, we can review the implementation against the criteria you signed off and tell you where.
In more detail
Most of the time the business has already tried. Someone has sat through three or four demos, collected pricing that cannot be compared line for line, and come away less certain than when they started. Every product looked capable. Every salesperson answered yes. Nothing in the room told them which one fits the way their business actually runs.
The other common starting point is a system that no longer fits. It was chosen when the business was half its current size, or it was inherited, or it solved one problem well and nothing else. The question is no longer "which product" but "do we replace this, extend it, or connect it to something that fills the gap".
Both are decisions worth getting right. Operational software is not a purchase you reverse cheaply. The licence cost is usually the smallest part; the real cost is the process rebuilt around it, the data moved into it, and the people trained on it.
A demo is a sales tool. It is designed and rehearsed to show a product at its best, using clean data, on a workflow the vendor chose. That is not dishonest, it is just what a demo is for. The trouble is what it does to the decision.
Starting with demos means the products define the criteria. You end up comparing features you were shown rather than the things your business actually needs, and the loudest feature wins. Requirements you never articulated stay invisible until implementation, which is the most expensive possible moment to discover them.
Demos also hide the parts that matter most operationally. You rarely see what happens when a job changes halfway through, what the app does with no signal on site, how the data gets out to your accountant, or what the fifth year of subscription costs once you have grown.
We do it the other way around. Requirements first, written down and agreed. Then the products get measured against them, and the demo becomes a test with an agenda rather than a presentation.
Software gets chosen by people who will not use it every day, and that is the single most common reason it fails. The office understands invoicing and compliance. The field crew understands what it is like to fill in a form on a phone with wet hands in the rain. Management understands the numbers it needs out the other end. All three sets of knowledge have to be in the requirements or the decision is being made half blind.
So we gather from all three:
We watch the work where we can rather than only asking about it. The gap between the documented procedure and the real one is usually where the requirement is hiding.
A requirements list that reads "must have job costing" is worth very little, because every product will claim it. Useful criteria come from the process itself and are specific enough that a product either meets them or does not.
We take the way the work runs today, decide what is worth keeping and what should change, and write the result as testable statements: what has to be captured at each step, who has to see it, what has to happen automatically, what has to survive an audit. Each one gets a weighting, because trading a nice-to-have against a deal-breaker is the whole point of the exercise.
That document is yours. It outlives the selection, and it is the thing that keeps the implementation honest later, whoever runs it.
We start wide and cut quickly. Products are eliminated on hard constraints first — the things that make an option unworkable regardless of how good the rest of it is.
The shortlist is normally three, occasionally four. Each one is scored against the same weighted criteria, so the comparison is like for like rather than a collection of impressions. Where a product cannot be judged from documentation, we get it in front of the people who would use it and give the vendor a scripted scenario from your business rather than letting them drive.
You get the scoring, the reasoning and the trade-offs in writing, including what you give up by picking the winner. There is almost always something. A recommendation that claims a perfect fit is a recommendation that has not been tested hard enough.
Independence is a structural claim, not a personality trait, so it is worth being concrete about what it means for our software selection services.
We are paid for the assessment, not by the vendors we recommend. Our fee does not change based on which product you choose, so there is no version of this engagement where one answer is worth more to us than another. You are the client; the shortlist is not.
We also do not need the answer to be a build. We write custom software, and that means we have an obvious commercial incentive to recommend it — so we say plainly when the right answer is a product you can buy. If a mature product covers the job, buying it is faster, cheaper and better supported than anything we would write, and telling you otherwise would be selling you the wrong thing.
Where we do have a relationship with a vendor — a partner or technical integration programme, for instance — we tell you before the evaluation starts, not after. Neutral does not mean we have never worked with anyone. It means you know what our interests are and can weigh our advice accordingly.
The honest version of this decision has three answers, and we have given all three.
Buy when the process is common. Most trade and field-service businesses run a version of the same job lifecycle, and there are mature products built for exactly that. If your operation looks like the market's, the market has already paid to solve it.
Build when the process is genuinely yours. Some businesses have an operation that is not a variation on anything you can buy — the thing they do differently is the reason they win work. Forcing that into a generic product means either paying to bend the product out of shape or bending the business to suit the software.
Connect when the systems you already own are individually fine and collectively disconnected. That is an integration problem, not a selection problem, and replacing working software is an expensive way to solve it.
Deciding which of the three you are looking at is most of the value in the engagement.
Choosing well and implementing badly produces the same outcome as choosing badly, so we can stay on to make the thing actually land: configuring it around the process you agreed, moving the data, connecting the systems either side of it, building the reporting, and being there while your people start using it in anger.
We are equally happy not to. You can hand the requirements and the recommendation to the vendor's own professional services team, to your internal IT, or to another implementer entirely. The documents are written to be used by someone else — that is deliberate, and it is what makes the advice worth paying for.
If you do use someone else and it goes sideways, we can review the implementation against the criteria you signed off and tell you where it drifted.
The related job is the one nobody schedules: working out what you are actually paying for. Businesses accumulate software the way they accumulate anything else. Licences stay allocated to people who left. Two departments buy overlapping tools. A product bought for one project renews for four years.
A spend review lists every subscription, what it costs annually, who genuinely uses it, and what overlaps with what. Usually a meaningful amount comes straight back, and occasionally it turns out you already own a product that solves the problem you were about to buy software for.
This is where most of our work sits, and it is why people look for a construction software consultant rather than a general IT one. It is a genuinely different selection problem. The office and the field need different things from the same system. Compliance evidence has to survive an audit years later. Jobs change shape once they start. Half your workforce uses the product on a phone, outdoors, with intermittent signal, and will simply stop using it if it fights them.
We work day to day across the platforms these businesses run on — project management, job and service management, estimating, tendering, safety and site access, and the accounting systems underneath them all — and we have integrated them to each other. That matters when you are evaluating, because the useful question is rarely "is this a good product". It is "is this a good product for a business shaped like yours, and will it talk to the things you are keeping".
Real projects, including the parts that took longer than expected.
AAA runs its week off a scheduling board that moves hundreds of thousands of dollars of work around every Thursday, and sometimes has to rebuild it around an emergency within the hour. The board they run now remembers every move, gates the handover to the crews, and carries the same record from quote to site to payroll.
View the project
AAA's salespeople quote, get approval, and hand work to the crews inside one system, where the quote the customer sees, the number the manager approves and the schedule the crews work are the same record.
View the project
Estimating teams spend most of their working year on jobs they will never win. Impact Plumbing now measures the part of that they can control: how fast a tender gets answered, how long since anyone touched it, and what the company keeps walking away from.
View the projectIf the process itself is the problem, choosing software will not fix it — that work starts with pulling the process apart and deciding what should change before anything is bought. If the systems you own are fine but do not talk to each other, that is systems integration. If the repetitive parts of the job are the pain, that is business automation. And if the reporting is what you cannot get out of any of them, that is reporting and dashboards.
Where a product genuinely does not exist for what you do, we can build one — but we will say so only after we have looked properly for one you could buy.
Tell us how the work runs today. We will tell you which of the three you are actually looking at, and we have no product to sell you either way.
