Skip to main content
In active use

Custom analytical tooling

Builds the model, calculator or interface an institution needs and does not have — and, critically, builds it so the institution can still run it after the assignment ends.

What it looks like

Custom build — chosen for who operates it
WorkbookFor a team that lives in Excel
ApplicationWhere there is engineering capacity
InterfaceBuilt with Rubik
HandoverDocumented method · version control · training · the client owns it
Schematic layout — the tool's real structure and outputs, drawn rather than screenshotted so no client data appears. Bars and blocks are placeholders, never figures. Labels inside the frame are the tool's own interface, which is in English.

Decision supported

Whatever recurring decision the institution has to make repeatedly and currently cannot make on its own evidence.

Intended user

Institutions that keep re-commissioning the same analysis because the last consultant left with the spreadsheet.

What goes in, what comes out

Goes in
  • The decision that has to be made, and how often
  • Data the institution already holds, in whatever state it is in
  • Who will operate the tool and what they can realistically maintain
  • Reporting or regulatory obligations the output must satisfy

Custom analytical tooling

Comes out
  • A working tool — spreadsheet model, Python application or web interface, chosen for who has to run it
  • Documented method, so results can be defended and reproduced
  • Handover and training for the team that will own it
  • Version control and a change log where the tool will be maintained over time

What goes in and what comes out. The model itself — its formulas, weighting and optimisation logic — is method, not proof, and is not drawn here.

Methodology summary

We build in the format the client can actually sustain. A ministry team that lives in Excel gets a rigorous, documented workbook rather than a Python service nobody can maintain; a team with engineering capacity gets an application with version control and tests. Where the interface needs real software engineering, our partner Rubik builds it. The choice is made on who operates it afterwards, never on what is most impressive to deliver.

Limitations

  • We do not sell software licences or run a SaaS product. These are commissioned tools, built for one institution's decision and owned by it.
  • A tool cannot fix a data problem. Where the underlying data does not exist, the first deliverable is an honest account of that gap, not an interface that hides it.
  • Sustained maintenance is the client's, unless a support arrangement is agreed separately. We build for handover rather than for dependency.

Public preview

Custom analytical tooling — interface rendering showing the executive dashboard with a demo dataset.
Interface rendering, demo data throughout — no client information appears.

Access model

Commissioned. Scoped and priced as part of an engagement or as a standalone build.

Want this run on your own numbers?

Discuss a project →We reply within two business days.