Software built for one client, one decision, and the people who have to live with it.
The software practice is the newer part of TIBI Services. It grew out of consulting work, where the same gaps kept appearing: a decision made in a spreadsheet nobody trusted, a report assembled by hand every Friday, a process held together by email. We now build the tools that close those gaps, and we build them to be owned by the client.
Four kinds of software, all of them specific
We do not build platforms for the market. Everything the practice makes is for a named client with a named problem, which is what lets it be small, precise and finished.
- Internal tools
- Applications that replace a manual process inside an organisation: intake and approval workflows, tracking systems for a program or a portfolio, tools that collect evidence for a compliance review, or a simple operational console that puts the information a team needs on one screen. Usually web-based, access-controlled, and integrated with the systems the data already lives in.
- Decision-support systems
- Software that helps a person make a recurring decision better: a scheduling or allocation tool, a scenario model with real data behind it, a risk scoring view that shows its reasoning. The emphasis is on making the next decision obvious and auditable, not on automating the person out of it.
- Data products
- Pipelines, reconciliations and reporting layers that turn scattered data into something an executive or a regulator can rely on. This often starts as consulting work, when a program needs a single view of status or evidence, and becomes a product the client keeps running after the program closes.
- Client-facing digital products
- Products that an organisation's own customers or members use: a portal, a mobile-friendly application, a self-service tool. These carry higher expectations for design, security and support, and we take them on where the client has a clear owner for the product after launch.
The same discipline, pointed at a build
Program management and software delivery are not separate worlds. A build has scope, dependencies, risks, a sponsor and a date, and it fails for the same reasons a program does: unclear ownership, decisions that drift, status nobody believes. The software practice runs a build the way the consulting practice runs a program, with a plan the client can read and a status that says what has changed.
The connection also runs the other way. Consulting engagements surface the tools a client is missing, and a build is often the most useful thing that can come out of an assessment. When that happens we propose it plainly, as a separate piece of work with its own scope, and the client decides.
The two practices are kept distinct on purpose. A consulting client is never obliged to buy software from us, and we will say so if an existing product would serve them better than something built.
Discovery, prototype, build, handover
Every build goes through the same four stages. Each ends with something the client can see and a decision about whether to continue.
-
Discovery
Who uses the tool, what decision or process it serves, where the data comes from, and what already exists. Output: a short written brief with the scope of a first version, what is deliberately left out, and an estimate.
-
Prototype
A working version with real data and the core flow, put in front of the people who will use it within weeks rather than months. Output: a prototype, a list of what changed after people used it, and a confirmed scope for the build.
-
Build
Building the production version in short increments, each one shown to the client. Security, access control, logging and backups are part of the build, not a phase after it. Output: a tested, documented application running in the client's environment.
-
Handover
Source code, documentation, deployment instructions and a walkthrough for whoever will maintain it. Output: a client who owns the software completely and can keep it running, change it, or hand it to another team without needing us.
What you own, and how it is built
Ownership and intellectual property
Software we build for a client belongs to the client. On payment, the client owns the source code, the documentation and the data, and may use, modify, host and extend the work without any continuing obligation to TIBI Services. We do not retain rights to resell client-specific work to anyone else.
Where a build uses open-source libraries, those libraries stay under their own licences, which we list in the handover documentation. Where we bring general-purpose tooling we have developed before, we say so at the start and grant the client a perpetual licence to use it as part of their system. There are no subscription locks, no proprietary runtimes and no features that stop working if the engagement ends.
Confidentiality applies to software work exactly as it does to consulting. We do not publish what we have built for a client, show it to other clients, or use client data for anything but the work itself.
Technology approach
-
Boring where it should be
Mature, widely used languages and frameworks with long support horizons, so that the client's own team or any competent developer can maintain the work later.
-
Runs where the client needs it to
Deployed in the client's cloud account or on their own infrastructure, under their security controls. We do not host client systems on our own accounts.
-
Small and finished over large and ongoing
A first version that does one thing well and is in use, then improvements based on how people actually use it. We would rather ship a tool than a roadmap.
-
Secure by default
Authentication through the client's identity provider where one exists, role-based access, encrypted data at rest and in transit, and an audit trail for anything that matters.
-
Documented for the next person
A readable architecture note, setup instructions that have been tested on a fresh machine, and comments where the code is doing something non-obvious.
-
Honest about fit
If an existing product, a spreadsheet or a process change would solve the problem better than custom software, we say so in discovery and stop there.
Next steps
If there is a tool your team keeps wishing it had, or a decision that is still being made in a spreadsheet nobody trusts, the contact page explains how a first conversation usually goes.