One person is the system
If a named individual is the only reason something keeps working, that is not a staffing problem. It is an architecture problem, and it is fixable.
Engineering consultancy · Malaysia
We fix the systems your business runs on, not the ones it shows off.
The scheduled jobs, the deployments, the data moving between teams, the parts customers never see — and never notice until they break. Mancube is hired to make those boring, and to leave your own people able to run them.
§01
Four reasons people call us
If one of these is recognisable, the conversation is worth having. If none of them quite fit, §06 sets out where we fit and where we would bring somebody else in.
You are told it cannot go on the internet
Regulated, government, defence or industrial work rules out most of the market. Systems that run with no connection at all are a specialism, not a setting.
Nobody can price the decision
Build or buy, migrate or stay, one platform or four. If the argument has run for months without a number attached, the missing thing is a measurement.
The bill grew and the reason did not
Cloud and vendor costs that nobody can attribute usually mean the environment is not described anywhere. That is recoverable.
§02
Ten kinds of work, and how you would judge each one
Every engagement is agreed against a measure before it starts. The last column is the one that matters — it is what we would both look at afterwards to decide whether the money was well spent.
What we’re hired to do
The situation
What you get
How you’ll know it worked
Workflow automation
Work that has to happen on a schedule is held together by scripts, and one person knows why. When it fails at 3am, it fails silently.
Those jobs rebuilt so they retry themselves, can be re-run safely, and tell you what happened.
Failed jobs are visible the same morning, and re-running one is safe.
Systems that run offline
A regulator, a customer or a security team has told you this cannot touch the internet — and most software quietly assumes it can.
Systems that install and run with no internet connection at all, on your own hardware.
It passes your security review, and it still works when the network is cut.
Release and deployment
Shipping a change is a nervous event. It takes a person, a checklist, and a good day.
An automated path from change to production, and a rollback that has been practised rather than hoped for.
Time from approved change to live, and whether a rollback has been rehearsed.
Moving off something
You are leaving a cloud, a region, or a product that is being discontinued — and nobody can say what will break.
The move planned, executed and written down, with a way back at every stage.
A cutover date that holds, and a documented way to reverse it.
Consolidation
Four teams built four versions of the same thing. Nobody agrees what a customer is, and every report disagrees.
One system the teams actually adopt, without freezing everyone else’s work for a year.
Teams retire their own version, and the numbers stop disagreeing.
Cloud setup and cost
The cloud bill grows and nobody can explain which part. Rebuilding the environment from scratch is unthinkable.
The whole environment defined in code, so it is reviewable, repeatable and attributable.
The bill breaks down by team or product, and the environment can be rebuilt.
Proof of concept
Someone has proposed a build. You need to know whether it works before committing a year of budget to it.
One question answered with something working, in weeks, built to be thrown away without regret.
A number against the criteria you set before we started — including a clear no.
Making it faster or cheaper
It is slow, or expensive, and the last three attempts to fix it were guesses.
The cause measured before anything is changed, then the change, then the before-and-after side by side.
The specific figure you care about — response time, throughput or monthly spend.
Building the software itself
You need something that does not exist yet, and it has to be correct, small and maintainable by your team afterwards.
The system built, in your repositories, with your engineers able to change it.
Your team ships a change to it without us.
Developer productivity
Good engineers spend their days waiting — on builds, on environments, on someone else’s review.
The waiting removed where it is measurable: faster feedback, local environments, documentation generated from the code.
How long from writing a line to knowing whether it works.
None of the above promises a number. It names the measurement we would agree up front, so the result is checkable rather than a matter of opinion.
§03
Why you would believe any of that
Consultancies are hard to judge from outside. So rather than references you cannot check, here is software we built and gave away — twelve finished products, eleven of them free and open for anyone to inspect, published under a licence that lets you keep them forever.
12 products finished and released11 given away, free and open46 posters, every figure from a real measurement11 of 12 run entirely on your own hardware
Why that is the evidence and not a brochure. Anyone can describe experience. Very few consultancies will hand you the actual work and invite you to take it apart — including the parts that did not go well. Each product below has a page of its own, and each of those pages publishes results that are unflattering as well as good: a competitor that is four times faster on one measure, an index of ours that fails its own accuracy target, a change that made a system slower before it made it faster.
That is the standard we would apply to your work too. If a number is uncomfortable, you get it anyway.
Eleven of the twelve run on your own hardware. They are single files you copy and run — no account, no licence server, no data leaving your network, and several of them work with the internet disconnected entirely. That matters if you are regulated, air-gapped, or simply tired of software that stops working when a vendor does. The exception is doneyet, which is a hosted service; its Business and Enterprise tiers add custom hosting and bring-your-own-cloud when the data plane has to sit inside your own account.
Moving and shaping data
dagron
Runs scheduled work reliably. Replaces a pile of scripts and a cron job with something that retries, resumes, and can be re-run safely. Installs as one file.
v0.3.0
shapeshift
Turns messy exports into tables you can query. Takes the ragged data one system produces and lands it in the format your analytics tools already read, without a database in between.
v0.1.2
lakeleto
Look inside a data file without a data platform. Opens large analytics files on a laptop to see what is actually in them. Nothing is uploaded anywhere.
v0.1.4
covenant
Stops one team silently breaking another’s numbers. Checks data as it crosses between teams, so a change upstream is rejected at the door instead of quietly corrupting a quarter of reporting.
v0.1.0
Governing and running AI systems
mcpdef
Controls and records what AI agents are allowed to do. Sits between your AI tools and your systems: nothing runs unless it is explicitly permitted, and every attempt is written to a tamper-evident log an auditor can read.
v0.2.0
recall
Stops you paying twice for the same AI answer. Remembers previous answers and reuses them when a near-identical question comes back. Tells you honestly when your traffic would not benefit.
v0.1.1
forge
Runs very large AI jobs on cheap hardware without losing work. Spreads a big batch across machines that can be taken away at any moment, and finishes the job when they are.
v0.1.2
evald
Tells you whether an AI change made things worse. Records what your AI features did and tests them against your own examples, failing the release only when the drop is real rather than noise.
v0.2.0
loregraph
Keeps a record of why things were decided. Reads the working notes AI coding tools already leave behind and links each decision to the exact code and moment it produced.
v0.1.1
mergestro
Checks AI-written code by running it, not reading it. Tests what an AI change actually breaks before a person is asked to review it.
v0.5.0
Access, security and operations
eggrd
Puts a lock on an application you cannot change. Adds sign-in, rate limits and encryption in front of software you are not allowed to modify — often the fastest route through a security review.
v0.3.1
doneyet
Answers “is it done yet?” without asking anyone. Tracks long-running work and alerts when a signal never arrives — not just when something errors. Hosted service; Business adds bring-your-own-cloud. Not open source.
live
§04
Every claim on a wall
One poster set per product. Every figure on them comes from a real measurement in that product’s own code — including the results that do not flatter us. Worth two minutes if you want to see how we argue with evidence.
Click any poster for a larger version. The full-resolution originals are 2800×4200 and live with their products.
§05
Three ways to start, and what each one commits you to
Start at the smallest one that answers your question. Each ends with something running in your environment and written down well enough for your team to keep — not with a slide deck.
A · days · fixed price
Review
Use it when: you suspect something is wrong but cannot say what, or you need an independent read before approving a budget.
- You get written findings, ranked by what they are costing you, with the measurements attached
- Commitment ends when the document arrives — it is yours to act on with or without us
- Fixed scope and fixed price, agreed before we start
B · weeks
Proof of concept
Use it when: a decision is stuck because nobody knows whether the thing would actually work.
- You get one question answered with something working, against your data, in your environment
- Commitment is capped — success criteria are agreed in writing first
- Built to be discarded. A clear no is a successful outcome and is charged the same
C · months
Build and hand over
Use it when: the decision is made and the work needs doing properly the first time.
- You get the system built and running, with your engineers able to change it
- Commitment is staged — and the handover assumes we leave, because eventually we do
- Everything in your own repositories. Runbooks written from real incidents, not imagined ones
Pricing is quoted per engagement once the scope is clear. We do not quote a day rate against an undefined problem, because that is how projects end up costing three times what anyone expected.
§06
Where we fit, and what we do about the rest
We are not the right answer to everything, and pretending otherwise wastes your money before it wastes ours. Here are the honest limits — each one with what we would actually do about it, because “we cannot help you” is rarely the whole truth.
You need hands, not a decision
If the work is already understood and you need people to execute it for a year, a staffing firm is cheaper and faster than we are — and we will say so. What we can do first is turn the unknowns into a specification precise enough that whoever you hire can work from it, and stay available for the decisions that come up mid-build.
It is a website or an app people look at
Design and front-end product work is somebody else’s craft and they will do it better. We build the part underneath — the data, the interfaces it calls, the systems it depends on — and work alongside your design team, or introduce one. You do not have to choose between us.
You want somebody to own it long term
Every engagement is built so your team can take it over, and we will tell you when that point arrives. That is not the same as walking away: we can stay on in a support arrangement for as long as it is useful. The difference is that it stays your choice, because the ability to take over is already there.
You are not sure which of these you have
That is the most common starting point, and it is a fine one. The shortest way through it is a review — days, fixed price, written findings — which usually settles what the work actually is before anyone commits to a build.
If none of this quite describes your situation, say so in a sentence and we will tell you plainly whether it is ours to take.
§07
Tell us what is broken
A paragraph is enough. What the system does, what it does badly, and what would have to be true for the problem to be over. You do not need to know the technical answer — that is the part we are for.
info@dagron.dev
WhatsApp @lucheeseng
Useful to include
- What the system is for, in your own words
- Roughly how many people depend on it
- Whether it can reach the internet, or must not
- What would count as this being fixed
Practicalities
English and Bahasa Malaysia. Based in Malaysia; engagements run remote, on site, or inside your own network where the work requires it.
First response
You get an honest read on whether this is work we should take — including when the answer is no, or when a review would settle it more cheaply than a build.