Mhalah

Buy one, if your procedure looks like everyone else's: accounting, payroll, standard inventory. Off-the-shelf is cheaper, faster and better tested there, and we'll say so plainly. But approval workflows differ from one organisation to the next: who signs, when a request moves on, and what stops it. Off-the-shelf imposes its route on you, so you either reshape your work to suit a program, or work around it with side spreadsheets and end up back where you started. The test is practical: if you find something off the shelf that matches your route without workarounds, it's the better value. If you're going to buy it and then work around it, you've paid twice.

That isn't guaranteed by a promise, but by making our presence unnecessary: the repository, the hosting and the database are in your organisation's name, with full keys in your hands, and the documentation is written so another team can pick it up without coming back to us. Post-handover support is a separate annual contract that states in writing what it covers and what it doesn't.

You may not, and that's an honest answer. Your developer knows the organisation and its people, and that's an advantage we don't have. But what usually stalls these projects isn't the programming: it's getting the procedure written down as it is actually practised, settling who owns changing it, and producing the document that gets signed before building begins — work that is hard for someone inside the organisation who is party to its procedures. So if you have a developer, the most useful thing we can give them is a route document to build from, not a system built in their place.

We have cybersecurity expertise on the team, and our systems are built and tested against national cybersecurity controls: permissions for every role, and an audit trail recording every action with its time and its actor.

Your organisation owns its data outright: it is held on secure infrastructure, each organisation's data isolated from every other and not accessible to anyone else, with regular, separate backups. It is never shared with a third party and never used outside the purpose it was collected for. Our access ends when the contract ends, and everything is handed over with its keys.

The written commitments and details are set out in the contract, and we'll provide them on request.

By scope, not by a fixed rate: the number of approval workflows, the roles involved, the integrations required, and whether we're building from scratch or tailoring our ready system. We quote in writing after understanding and documenting the procedure, not before.

It depends on the scope, and we don't quote a duration before reading the procedure. What we can say is that documentation comes first and shortens everything after it — a system built on a signed document takes less time than one discovered as it's built.

Support is a separate annual contract, covering: beginning work on what breaks within two working days, security and dependency updates, and a six-monthly review of what has changed in your procedure and what needs adjusting. It does not cover a new service, a new route, or integration with another system — those are quoted separately before any work begins, and the binding wording for each item is in the contract.

Yes. Our field is the administrative procedure, wherever it is practised — nonprofits, endowments, government entities, healthcare providers, professional practices, schools and companies. What sets the boundary is the procedure, not the sector.

Send us a request with a description of what you need. We'll reply in writing within two working days of your request being complete, and if there's a fit we'll arrange a session with whoever practises the procedure day to day — that session is where the work actually begins.