No single blind spot became ours
We had three different AI systems each build a full map of how the system works, independently — so a mistake or gap in one didn't quietly become the map everyone relied on.
Case study / Application Managed Services
Three days to safely take over support of a system the business depends on
Wassermeloni runs its day-to-day operations on an ERP system and a separate customer portal — both built up over years, both too important to pause for a rebuild. When Aleph Engineering picked up ongoing support in October 2025, we didn't ask for months to get oriented. We built the tools to understand the system safely, shipped a real fix within three days, and kept a full record of how we did it. That record is now the basis of a service we offer other businesses in the same position: Application Managed Services.
Discuss a similar challengeWASSERMELONI · APPLICATION MANAGED SERVICES3 days: taking over to a live fix in production.Ongoing support partner since October 2025.
3 daysfrom taking on the system to shipping a real fix in production — not a demo
17separate tools and systems brought under one support setup, so nothing was left unmanaged
272pages of plain documentation created, replacing years of scattered internal notes
112/112open questions answered by the outgoing specialist before they left — not walked out the door
Before we started: was this safe to take on?
A system that still mattered, run on thin documentation
Wassermeloni's operations run on two systems: an ERP handling bookings, courses, and finance, and a customer-facing portal built years earlier. Both had real documentation — but years of hand-offs had left it contradictory in places and out of date in others. Before agreeing to take on ongoing support, we checked the honest way: we tried to actually set the systems up from scratch and wrote down everything that didn't match reality.
23real gaps found between the documentation and reality
7serious enough that a new developer could not get a working setup at all
None of this was anyone's fault — it's the ordinary residue of years of real feature work, not a sign of neglect. But it's exactly the kind of thing a business needs to know before handing ongoing responsibility to anyone: what's actually documented, what's assumed, and what only lived in one person's head.
THE APPROACHWe didn't rebuild the system. We built what we needed to support it safely, first.A full rebuild is sometimes the right call — when the platform itself, not the surrounding process, is what's holding the business back. Here, the priority was continuity: the business needed the system to keep running and keep improving while someone new got fluent in it. If a bigger modernization ever becomes the right move, that stays a separate decision, made later, with evidence — not something bundled into ongoing support by default.
Taking over
Understanding the system, fast
272 pages, still maintained today
Years of scattered, contradictory notes became a single, searchable handbook covering how the system works and how to operate it — the reference every new person now starts from.
Before the expert walked out the door
When a developer who had worked on the system for years was preparing to leave, we ran a structured interview covering every gray area we could find, and got a confirmed answer to all 112 questions before their last day.
Ongoing support
Built to actually operate the system
Written down once, reused every time
Restoring a database safely, verifying a bug before fixing it, proving a fix works before it ships — the recurring parts of the job are documented once and followed the same way by every engineer, instead of re-learned from scratch each time someone new joins.
Nothing left to memory
All 17 of the systems and tools this work touches — the ERP, the portal, the documentation, the shared tooling — are unified under one support setup, so nothing depends on someone happening to remember where it lives.
Built for supporting more than one business
Aleph supports more than one client at a time. Our tools are built so credentials, data, and access for each client stay completely separate — by design, not by discipline alone.
Since then: keeping it running
Ongoing support, and safer room to change things
Since taking over, we've operated as the team's ongoing development partner — triaging incoming issues, shipping fixes, and keeping the system that tests and ships changes reliable, so problems get caught early instead of piling up. We also fixed a recurring reliability problem in that delivery pipeline itself, cutting out a source of delay and false alarms that had been slowing releases down.
One structural change stood out. Until recently, every proposed change had to be tested in a single shared environment — so only one change could be reviewed at a time, and everything else queued up behind it. We built a setup that lets several small changes be tested independently and safely, side by side, before anything goes live. It's a small piece of infrastructure, but it's the difference between careful, incremental improvement and either being stuck waiting in line or moving too fast to trust.
Evidence and limits
What we measured, and what's still a judgment call
Not every number above is equally solid, and we'd rather say so than let you assume otherwise.
What we measured
The number of systems, documentation pages, and the timeline above come straight from our own records — exact counts, nothing rounded or guessed.
What we observed, with a caveat
The recent increase in completed work overlaps with the reliability and change-process fixes described above, so we're not claiming every month looks like that one.
What we don't have a number for yet
Exactly how much time this saves against a typical hand-off, because we don't have a clean “before” case on this same project to compare against. The 23-gap story above is the closest real evidence we have of how much confusion a new developer usually runs into.
Your legacy estate
Does your business depend on a system nobody fully understands anymore?
That's the situation Application Managed Services is built for: an assessment first, to confirm we can safely support your system — then ongoing operation and small, controlled changes, without the risk of a rebuild you never asked for.
Ask about AMS