When the subscription stops fitting the work
Software as a service is often the fastest way to solve a common problem. Accounting, payroll, scheduling and customer relationship systems are good examples. The trouble starts when a small team needs one focused workflow but has to buy a much larger platform to get it.
Seat pricing can grow faster than the value. Staff may still copy information between systems because the paid product does not match the actual handoff. A broad system can also bring configuration, training and administration that the business never wanted.
Are we paying for a product, or are we paying to avoid fixing the workflow?
When a focused custom application makes sense
A custom application becomes worth considering when the work is important, reasonably stable and specific to how the business operates. The team should be able to explain what starts the job, what decisions are made and what a useful result looks like.
The process repeats. A small improvement will be used often enough to matter.
The existing gap is clear. Staff can show where information is copied, delayed or lost.
The first user group is small. A focused release can be tested without changing the whole company.
The result can be measured. The business can compare time, rework, response or completeness before and after.
The application does not have to replace every system. In practice, it may sit between an inbox, a spreadsheet and an existing business platform. Its job is to make one piece of work easier to complete and easier to track.
A useful first release is deliberately narrow
The first version should handle one end-to-end job for a defined group of people. For example, it might turn an incoming request into assigned work, prepare an approval packet or give sales staff a complete opportunity record before they follow up.
- Map the current process and agree on the real problem.
- Choose the smallest release that produces a complete business result.
- Connect only the information sources that release needs.
- Run it beside the current process long enough to compare the two.
- Improve, expand or stop based on what the business can see.
This approach keeps the budget tied to evidence. It also avoids a long build based on assumptions that have not yet met real work.
Ask about the whole cost, including ownership
A custom application avoids some subscription costs, but it is not free software. The business still needs to account for design, development, hosting, maintenance, support and future changes.
- Who owns the code, data and accounts?
- Can the business export its information in a usable format?
- What does hosting cost at the expected level of use?
- Who handles security updates and service failures?
- What happens when an outside system changes?
- Can another qualified developer maintain the application later?
These questions should be answered before the build begins. A lower monthly bill is not much of a win if the business ends up with an application it cannot operate or change.
Sometimes an existing product is still the better choice
The process is standard. A mature product already handles the work well and at a sensible price.
The requirements are still moving. The team has not agreed on the process that software would support.
The business needs regulated or specialist functions. Buying a proven platform may reduce risk and support burden.
The custom build cannot stand on its own. A first release that needs years of work before it helps anyone is too large.
Main Sequence starts with the business problem because either answer can be right. The point is to spend money on the change that fits the work, not on a preferred category of technology.
Start by testing the business case.
Bring the process, the current tools and the part that is costing too much. We can work out whether a focused application is sensible.
Discuss the process