Forge. Software forged to take the heat.

Bad development leaves you with software that can't take the heat.

We never leave our clients burning.

Talk to an engineer

Forged to take the heat.

Forged to take the heat.

We build software that has to hold, and we fix software that didn't.

Forge is the engineering arm of the m-anant group. m-anant works out the answer, Weave designs it and we build it.

Some people come to us with something new to make. Others come because a system they rely on has started failing in front of their customers, or a vendor has gone quiet and left them holding it. We take on both, and we hold both to the same bar: software that stands up to the load it will really carry.

Group
m-anant Weave Forge
Arm
Engineering
Base
Singapore
Heat is how we show status. Cold iron is idle, ember is live, orange is under strain and white-hot has failed.
  1. Idle
  2. Live
  3. Strain
  4. Failure

Something to build, or something already burning.

New build

You have a product, a platform or an internal tool to make, and you want it made once. Before the first line of code we work out what it has to carry, what it connects to, how it fails and who runs it after launch. Then we build it to that.

New builds

Rescue

Something in production is failing, or you've inherited a system nobody can explain. We get access, find what is breaking and stop the damage first. After that we fix the cause, so the same fire doesn't start again next month.

Rescue and stabilise

Software rarely fails in the parts anyone demos.

The heat arrives as a traffic spike on launch day, a database that quietly fills up, a supplier's API that stops answering at 2am, or the one engineer who understood it handing in their notice. We plan for these before they arrive, and we test for them before you go live.

A simulated system diagram: users, an edge network, an API, a database and a third-party payment service. As simulated load rises, the database fills, the payment supplier stops answering and the API fails under unbounded retries. The system is then rebuilt with a cache in front of the API, a queue in front of the payment supplier and retries capped at three, and it holds.

We never leave our clients burning.

Most of it is unglamorous work, done properly.

  • Load

    We find out what it has to carry, then test it past that.

  • Failure

    Anything that can fail has a fallback, and nothing live moves until rollback has been proven.

  • Security

    Access, secrets, data handling and dependencies get reviewed while we build.

  • Handover

    Documentation, runbooks and dashboards your team can read without us in the room.

  • Upkeep

    Backups that have been restored at least once, alerts that reach a person, patches on a schedule.

On a move of thirteen hotel and restaurant websites, rollback and disaster recovery were tested in the first month, before a single site moved.

See the approach

AI writes a lot of the code. An engineer answers for all of it.

We use AI to build because it is fast and, with the right person reading it, accurate. It drafts code, tests and screens in hours. A senior engineer decides what gets made, reads what comes back and signs off every line before it ships.

There's a popular idea that a powerful enough tool removes the need for a skilled driver. We'd put it the other way: AI is the car and the engineer is the driver.

Made
with AI
Read
by a senior engineer
Signed
every line, before release
AI in production

It leaves us cool enough to hold.

A lot of software is handed over still hot, half-documented and understood only by the people who wrote it. When they leave, the business is left carrying the heat.

We hand over a system your team can run. The code, the servers and the accounts sit in your name. You get the runbooks, the monitoring, the known limits written down and a team that has been walked through it. If you want us to stay on and run it release by release, we can. If you'd rather run it yourselves, it is ready for that.

Engineering support
  • Codeyour repository
  • Accountsyour name
  • Runbookswritten
  • Monitoringlive
  • Known limitsstated

Told from the build.

Each project in the group is told by every arm that worked on it. These are the engineering side: what we built, how we made it hold and what it does now.

  • Off the vendor, live in six days

    A legal marketplace taken back from the vendor that ran it. The morning test failed, two blockers were fixed by midday and it went live on the client's own domains that afternoon.

    6daysdecision to cutover

  • A live platform, rebuilt in parts

    A CRM and loyalty platform moved from one large codebase to modules around one customer record, built so brand programmes could move across in waves.

    8modulesaround one core

  • Thirteen sites, each on its own

    Hotel and restaurant websites moved off shared servers onto their own machines in three waves, with rollback proven before the first move.

    4·4·5sites a wavethree waves

  • Made with AI, checked by people

    A consumer app rebuilt with AI in the making and every screen checked against the research. We now run it release by release.

    Every screenchecked against the research

See all the work

The first call is with an engineer.

Tell us what you're building or what's failing. We'll ask the questions a build needs answered early: what it has to carry, what it talks to, what happens to the business if it stops and who runs it afterwards. For a rescue we look at the system itself before we suggest anything.

You then get a short written plan with the risks we see, the shape of the work and what happens in the first two weeks. If we think you don't need us, we'll tell you that too.

  1. 01A call with an engineer
  2. 02We look at the system
  3. 03A written plan
  4. 04The first two weeks

System down right now? Choose "Something is failing" on the form and tell us what you're seeing, or write to forge@m-anant.com.