Most organisations do not have a software problem first. They have an operations problem that software might help. The distinction matters, because buying or building a platform will not fix an unclear process — it will only make the confusion faster.
A useful test is repetition. If the same request, approval, record or report is handled by copying between email, WhatsApp and spreadsheets several times a week, the organisation is already running a system. It is simply an unofficial one, with no access control, no audit trail and no owner when something goes missing.
Custom software is usually worth considering when three conditions appear together: the workflow is specific to how you operate, the cost of error or delay is material, and off-the-shelf tools force staff into workarounds. If a well-implemented existing product already fits, we will say so. Building something new is not a badge of seriousness.
Before a build starts, decision makers should be able to name the users, the outcome that would make the work successful, the systems that must connect, and who will own the product after launch. That last point is often skipped. Software without an owner returns to spreadsheets within a year.
Discovery is not delay. A short, structured look at the current process almost always reduces the cost of delivery, because it prevents the first release from encoding the wrong habits. It also creates a shared language between operations, leadership and the people who will build the system.
Pentacom's view is conservative on purpose. We would rather ship a smaller system that staff trust than a wide platform that nobody fully runs. Start with the workflow that hurts every week. Make it reliable. Then decide what is next with evidence from production, not from a slide.