We repair fragile software in private equity portfolio companies, connect the systems of acquired businesses, and add AI features where they help.
We inspect the existing code, interfaces, and operating dependencies with the company team. The first release addresses a specific problem, such as a failed order handoff or an approval process managed by email.
We inventory applications, dependencies, data ownership, interfaces, and release practices. The map shows which components can be extended, which carry unacceptable operating risk, and which assumptions need a technical test.
The first release makes one visible improvement, such as an approval screen, a dependable integration, a repaired workflow, or a controlled AI feature. The records, calculations, and actions users depend on keep working while we change a defined part of the system.
We expose approved functions through an or connect them to external tools and AI platforms, using MCP or WebMCP for specific permitted actions where that fits. Identity, authorization, validation, and audit records stay the application’s job.
We document data mapping, reconciliation, access, , monitoring, and ownership, and test both the cutover and the old way of working. A release backlog explains the dependencies and how later changes will be accepted.
With the company team, we review the repository, hosting environment, dependencies, integration contracts, representative records, and recent failures. We confirm code ownership, access rights, and deployment authority before estimating a release.
We write acceptance cases from existing behavior and operators’ examples, then test a thin path through the hardest dependency: an API, a migration, an approval step, or an AI evaluation. The result confirms or changes the proposed architecture.
We release an agreed slice with a monitored cutover and a way to roll back, then reconcile records and completed actions. We train users and hand over operating knowledge before an old component is retired or the pattern is extended.
Illustrative workflow, not a client result. A platform and a new acquisition use separate order systems, and staff copy customer and job details between them.
We map customer, location, service, and order identifiers, and confirm which system owns each field and what an amendment or cancellation means. Similar field names do not prove matching definitions.
An approved order status moves through the best supported interface, using stable identifiers and a record of confirmed updates. Before volume increases, we test a duplicate event, an out-of-order amendment, an unavailable system, and a partial update.
An operational integration makes the next action dependable. Comparable portfolio reporting also needs effective dates, acquisition boundaries, source reconciliation, and agreed metric definitions. We plan those data requirements alongside the application change.
A sponsor can set priorities, but each portfolio company needs its own business owner, technical owner, and reviewer. Before release, we agree who holds code and deployment access and who handles integration upkeep, model changes, incidents, and support. Reusing a pattern in another company does not give either company access to the other’s data.
Yes. We can take on a defined assessment or release alongside the company’s team. Before changing anything, we agree on repository access, review standards, who makes architecture decisions, who can deploy, and who owns the software long term.
Only when it improves a specific task. The more pressing problem may be data access, reliability, or an ordinary integration. We keep AI features and their testing separate from financial calculations and fixed business rules.
Not necessarily. An existing may be enough. We start from the external tool, AI platform, or user workflow that needs access. MCP and WebMCP can expose suitable tools to AI platforms that support them, but they do not replace authentication, permission checks, or acceptance testing.
Yes, for most of it. Discovery, workflow reviews, software delivery, and acceptance testing can run through remote sessions and controlled access to your environment. Watching the work in person or meeting a security requirement may need an on-site visit. We agree on participants, access, time zones, and any visits during scoping.