What we solve ·How do I build something that later runs on its own?
Forge · Build
What do you do when a process that matters lives in a spreadsheet?
We run it in a spreadsheet and no product on the market does exactly this.
A small, specific application for your process, with an operating manual, a named owner and the three year cost of operation stated in the proposal.
Custom operational applicationSend this page to whoever decides
What you receive
- The application in production, with the code or the configuration in your hands.
- Operating manual, monitoring, backup and recovery procedure.
- The three year total cost of operation projection.
- The handover record with a named owner and the written retirement criterion.
The proof that applies here
- 19 years of domain in service and incident management systems.
- An operation built from zero to 150 people across eleven teams.
- Two corporate products taken to the Gartner Magic Quadrant, from the side that decides what gets built and what does not.
How we solve it
The method, not the promise.
- The process gets observed as it is executed, not as it is described in an interview. That is where the exceptions that define the scope live.
- The owner gets named and the three year cost of operation gets accepted in writing. Without both, nothing goes past this point.
- It gets built with a deliberately narrow scope, integrating through the paths that are already supported.
- It gets delivered with an operating manual, monitoring, backup and a recovery procedure, plus the code or the configuration in your hands.
- The retirement criterion gets written: under what condition this should be replaced by a market product.
Use this today, without hiring anyone
The arithmetic that decides whether building is worth it. It is five lines the proposal does not carry; do them yourself before asking for quotes and you will drop half the ideas.
- Build. What they will quote you. It is the line everyone puts in and the least important of the five.
- Operation, year one through three. Who maintains it, how many hours a month, at what cost. Add the three years before comparing against a license.
- The person. The name of whoever answers for this in year two, and what happens if they leave. If you cannot write the name, do not build.
- Exit. What it costs to switch it off and take the data out the day it is no longer useful. An application with no retirement criterion stays forever.
- What you already pay for. Check whether some tool you already have does 80% of this. It happens more often than it seems and it is the cheapest answer.
All five come down to one rule. If there is no named owner and no cost of operation accepted in writing, nothing gets built. It is the firm's rule and it works for you with any vendor.
This sounds like you if
- A process that matters depends today on a shared spreadsheet.
- Buying a product off the market costs more than the problem.
- Something built earlier ended up with no designated owner.
Before you hire
Before building, the internal owner gets named and the cost of operation gets accepted in writing. It is the rule that avoids handing you a problem three years out, and that is why it gets closed first.
The right question here is who answers when it fails in year two. This service is designed by someone whose entire career was operating software other people built, and that is why the deliverable includes the cost of maintaining it and the criterion for switching it off.
Who is going to answer for that application two years from now, and what will it cost you a month?
If the problem is a different one
The areas built their applications with AI and the person who made them left in March.
Self built software debt
The pilot worked, everyone applauded and eight months later it is still a pilot.
From use case to production
We were told to bring the budget down and every owner defends their application.
Technology spend rationalization