§ For internal tools owners
Maintenance for the internal tool nobody owns full-time anymore.
The tool was built three years ago by someone who has since moved teams. It works. Operations depends on it. The version of Next.js is two majors behind, the dependency tree has not been touched in eighteen months, and last month a deploy almost went sideways for reasons nobody fully understood. Kebehut is what you put in front of that tool so it keeps working — and so the next person who looks at it does not have to start from scratch.
§ What worries this audience
Three things you're probably already feeling.
- The tool fails quietly in a way that costs a team a working day before anyone notices
- Nobody on the current team has actually opened the codebase in over a year
- A required upgrade — a vendor deprecation, a node version bump — turns into a multi-week project right when you need the engineers elsewhere
§ Pilot fit
How a pilot is shaped for you.
Internal tools usually want exactly what Basic offers: a monthly check, a record of what changed, and a heads-up when something needs real engineering hours. Step up to Pro for the month you actually do the upgrade, then drop back.
First month — what lands in your inbox
- An inventory of what the tool does and which teams use it
- A dependency and security audit with severity ranked, not just listed
- An action list separating 'can wait', 'should do', and 'must do this quarter'
- A rebuild-ready specification you can hand to a future engineer in one document
§ FAQ
Questions, briefly answered.
- The tool is behind our SSO. Can you still maintain it?
- Yes. We work from the codebase and your deployment logs; we do not need to log into the running tool itself. If a fix requires running the app against your environment, we set that up under your control, not ours.
- Our security team needs to approve every change. Does Kebehut fit that?
- Yes. We propose changes in pull requests against your repository, with the reasoning written into the PR description. Your security team reviews and merges on your normal schedule; we do not auto-merge.
- What counts as one 'tool'? We have several small internal apps.
- One codebase, one deploy target, roughly one team using it. If you have a portfolio of small internal apps in one monorepo, that is one engagement; if they are separate repos, talk to us and we'll size it together.
Email us about a pilot.
One paragraph about the app, the stack, and what's worrying you. Reply within one working day, from [email protected].
[email protected] →