A product or a project? Compare the job before the tools
Compare an existing product, a connection between tools and a specific build using one recurring job, one essential rule and a plan for ongoing ownership.
A team has a recurring job that its current setup does not support well. Someone suggests buying a product. Someone else suggests building a tool. Before choosing a route, both proposals need to answer the same question: what must this particular job let the team do?
Our suggested comparison starts with three details: the job that repeats, the rule it must respect, and who will look after the result. These details give an existing product, a configuration change and a specific build a common test.
Put one job in the middle
Consider a fictional repair business that needs to receive a request, assign the work and record its completion. This is an illustrative scenario, not a client case.
Most requests follow a simple path. One type of repair can only be assigned when a particular specialist and a required part are both available. For this example, that is the essential rule. A useful comparison must include it, rather than showing only a straightforward request that every option can handle.
The next question is what the business already has. Perhaps a form receives requests, a scheduling tool manages specialists and an inventory tool records parts. The gap could be a missing capability, an unused setting or information that does not pass between tools. These are different problems to investigate.
Route one: use an existing product
An existing product is worth testing when its supported way of working fits the job. In this example, the team would walk through a normal request and the request with the specialist and part requirement.
The check should include who can make or change the assignment, what happens when availability changes and how the team retrieves its records. A feature name on a comparison page does not answer those questions. The team needs to see the relevant behaviour in the version and plan it is considering.
The trade is accepting the product's boundaries. That may be perfectly reasonable. A preference for a different screen layout is different from a rule that the business must preserve.
Route two: configure or connect what exists
If the current tools already cover the job, a configuration change or a connection may be worth testing first.
For the repair example, the question could be whether an approved request can reach the scheduling tool with the right details. The comparison would also check what happens if a transfer fails or the same request arrives twice.
A connection still creates ongoing work. Someone must look after access, changed fields and failed transfers. It should have a clear purpose and an owner, just as a new application would. The useful outcome is a complete job across the tools, not merely a successful transfer in isolation.
Route three: commission a specific build
A specific build is worth exploring when an essential rule remains unsupported after checking available products and configurations. In our example, that might be the assignment rule. It is a reason to investigate, not evidence that custom software is already necessary.
The proposed scope should explain what will be built, what will remain in existing tools and how the team will test the complete job. It also needs an agreement about maintenance, access and future changes. A first release and its continued operation are separate parts of the decision.
At WGMI, our work includes websites, software and integrations. Our own projects include TAORO, focused on client operations for small agencies, and DOLFA, a medical workspace project in development. They address different kinds of work. That is why we start with the task before choosing the tool.
Put the comparison in one fit note
Use the same note for every route so that a polished demonstration does not change the question halfway through.
The job that repeats: What should someone be able to complete?
The rule we must keep: What condition makes this job different?
What our tools already cover: Which parts work, and where is the actual gap?
Who will maintain it: Who can change settings, resolve failures and arrange support?
The route and example we will test: Which option will we examine next, and which realistic request will show whether it fits?
Complete this fit note for one recurring job before comparing your next options.
Prepared for WGMI with AI assistance.