Free checklist Book a call →
Home/ Industries/ Enterprise Software

Industries

Product engineering and AI for enterprise software vendors

For vendors with a product already in the field, paying customers sitting on several versions of it, and a roadmap that keeps losing to support and upgrades. We build the next part of it, then stay on to run it.

Book a call → Get the CTO checklist

Where we help

What we build for Enterprise Software.

Product modernisation without a cutover

Framework upgrades, a data model that no longer fits, an interface built for a different decade. We take it a releasable piece at a time behind the existing screens, so customers stay on the working path until each new part is proven.

AI features inside a shipped product

Copilots, drafting and classification built into the product you already sell. Each is gated by a per-customer flag, so an account whose policy forbids it never sees the feature, anything sensitive waits for a human decision, and every action is recorded in a form a customer's auditor can read.

Version sprawl and upgrade paths

Accounts sitting three releases back because the last upgrade hurt. We map who is on what, write migrations that can be rehearsed and reversed, and make the upgrade something your support team can run rather than an escalation.

Per-customer customisation, contained

Forks and one-off branches cut for a large account, now carried forever. We move what we can into configuration, feature flags and extension points, so the next bespoke request does not become another branch to maintain.

Single-tenant, on-premise and hosted

The same product installed in a customer's own cloud, on their hardware, or run by you. We build the deployment and update path for all three, so a fix can reach an on-premise site without a consultant travelling to it.

Integrations, SSO and a public API

Single sign-on against whichever directory an account happens to run, exportable audit logs, webhooks, ERP and CRM connections, and versioned API documentation a customer's own developers can work from. These are the questions that stall a procurement review, so they are built once properly and reused for the next deal.

How it runs

Plan. Build. Run.

01

A 30 minute call

Bring the version numbers: which releases are still in the field, roughly how many accounts sit on each, and which of them were forked for one customer. We also ask who has to sign off an upgrade at those accounts. No charge, nothing to prepare.

02

Fixed scope, timeline and price

The scope names the releases the work has to reach and the deployment shapes it must survive in, hosted, single-tenant or on-premise, because that is what actually moves the number. Dates and cost are settled in writing first, and any later change is quoted on its own.

03

Build against every supported release

Each piece merges behind a per-customer flag, and its tests run across every release line you still stand behind rather than only the newest. Nothing goes near a customer install until it has passed on the oldest version you have promised to keep alive.

04

Ship to customers, then run it

The first release goes to one or two accounts that agreed to take it early, is watched through a full reporting cycle, then rolls out along the installed base version by version. From there the same engineers keep it alive and write to you once a month.

Why infoloop

We do not hand over and leave.

  • We stay on after the releaseWe carry the support burden we created. When an account three versions back raises a ticket about something we wrote, it reaches the same engineers, not a desk working from a handover document written the week they left.
  • We work in code we did not writeWe are comfortable starting in a product whose original authors have left. Before proposing to change an awkward part, we work out what it does and which accounts lean on it, because a decade of behaviour that particular customers depend on is rarely written down anywhere.
  • Enterprise-scale domain softwareWe built a machinery ERP: multi-site, role-heavy, and wired into the systems already running the business. Deep domain software with real users on it is the normal job here, not a stretch.
  • AI that reaches productionThe fintech support copilot we built handles live tickets and we are still tuning it every month. That is the bar an AI feature clears here before it appears in something your customers have already paid for: switchable off per account, recorded, and reversible.
  • One number, not an hourly meterYou get two figures and neither moves without your signature: one to build the thing, one each month to keep it running. Nothing is billed by the hour, so what you put in the plan is what turns up on the invoice.

What you get

Every engagement includes these, in writing, before work starts.

  • A written scope, timeline and fixed price agreed before any code is written.
  • Feature flags so a change can be enabled or reversed per customer, without a release.
  • Rehearsed, reversible data migrations, tested against a copy of production first.
  • Automated tests and CI checks that run on every pull request we open.
  • Runbooks, architecture notes and credentials held in your own accounts.
  • A monthly report on the metric we agreed to move, and one recommended next step.

Who this is for

Three situations where this is the right call.

Your customers sit on four different versions

Every upgrade has hurt someone, so accounts were left where they were, and support now maintains behaviour that stopped shipping years ago. You need an upgrade path that is rehearsed, reversible, and something your own support team can run.

A big account has asked for AI in the product

It surfaced in a renewal conversation with one of your larger accounts and now it is on a slide. Nobody internally has run a model in front of paying users. You want approvals, a recorded trail and a per-customer off switch, and one team answerable for it once the feature is in the field.

The product sells and nobody dares touch it

It works, the revenue is real, and the people who built it have moved on. Every small change turns into a negotiation about risk, and the platform underneath is drifting out of support. You want custody of it back before a deadline forces the decision.

Proof

Software we built, and still run.

Machinery ERP, rebuilt and run

Read it →

Questions

What buyers ask us first.

How is an engagement priced, and what does it look like?
Two figures, both settled before anyone opens an editor. The build is quoted as a scope with dates against it rather than as a day rate, so a change request becomes a separate quote you approve instead of a line that appears later. Keeping the software running afterwards carries its own monthly figure, sized to what we look after. Where the codebase is old enough that nobody inside your company can say with confidence what a given module does, we sell a short paid assessment first, since nothing about legacy work can be costed honestly down a phone line. That written assessment belongs to you whatever you decide to do next. The call that begins all of this takes half an hour and costs nothing.
Will you work in our existing codebase, or does it all get rebuilt?
Your repository, your branch conventions, your CI, and pull requests that go through whatever review your team already runs. We do not open with a rewrite. A product that has been sold for years carries behaviour particular customers depend on and nobody documented, and discarding it means rediscovering all of it through support tickets. Where a component genuinely has to be replaced, say a data model written when there was only ever one deployment, or a platform whose vendor has stopped issuing security patches, we scope that component by itself, agree it with you, and stand the replacement up behind the existing screens so the rest of the roadmap is not held hostage to it.
Our customers are spread across old versions. How do you handle upgrades?
First we map it: who is on what, what was customised for them, and which of those changes can move into configuration instead of staying a branch. Then upgrades are built as steps that can each be released and reversed, with data migrations rehearsed against a copy of a customer database before the real run. Releases go to a pilot account first, get watched, then widen across the base. The aim is an upgrade your support team can run on a Tuesday afternoon, not one that needs an engineer on a call with every account.
How do you add AI to a product enterprise customers already rely on?
Narrowly, and behind a switch your account managers control. We pick two or three jobs where the rules are already written down somewhere, restrict what the feature may reach to exactly the systems those jobs need, and require a human decision on anything that moves money or alters a record a customer might later have to justify to an auditor. Everything the feature does is recorded. Because one feature has to be acceptable to accounts with very different policies, that switch is per customer rather than global, and an account that has said no simply never sees it. Our fintech support copilot is built this way. We read its automation and error rates every month, and its remit widens only when those hold.
Can this work if our product runs on-premise or in customer tenancies?
Yes, and it changes what gets built rather than whether we take it on. Deployment and update paths are designed for every environment you actually ship into, so a fix can reach a single-tenant install without a consultant travelling to site. For AI features it matters most: the model, the data and the logs can stay inside the customer's own boundary where their contract requires it. We work in your accounts rather than ours, so access can be revoked at any point, and we develop against masked or anonymised data instead of live customer records.
What happens after the release ships?
We carry on supporting it across the versions it is genuinely installed on, which for a vendor is the harder half of the job. That covers alerting on the environments we can see, fixes against agreed response times, security and dependency patching applied to each release line still under support rather than only the newest, and a steady trickle of small improvements instead of work that happens only after an outage. Once a month you get a written account of what changed, what the numbers did, and what we think should come next. One figure, sized to what we look after, and we hold the software we run at 99.9% uptime. Your repositories, your cloud accounts, runbooks written as we go, so ending the arrangement with notice costs you nothing but the notice.

Related

You might also need.

Legacy App Modernizations

We take on software we did not build, and make it maintainable again.

See more →

Enterprise applications

ERP, system integration, workflow automation and the APIs that hold them together.

See more →

AI & Advanced Tech Solutions

Agents and copilots that do real work in production, with guardrails and rollback.

See more →

ISVs & Technology Companies

Senior capacity that joins your team and ships, without a hiring cycle or a handover cliff.

See more →

B2B SaaS

Multi-tenant product work, support copilots, and the retainer that keeps releases shipping.

See more →

AI Startups

Getting an AI product out of the demo and into production, with guardrails and a rollback path.

See more →

Tell us the part of the product nobody wants to touch.

Bring the release matrix and the accounts you have been afraid to upgrade. Half an hour later you will have a written scope, dates, one figure to build it and one figure a month to keep it standing.

Book a call → Get the CTO checklist
Book a call Checklist