The central IT backlog is built for enterprise priorities, not every business unit’s process.
Central IT teams at large companies are usually committed to platform rollouts, infrastructure, security work, and the programs the executive team has ranked highest. A claims process in one division, a pricing approval flow in one region, or a service team’s intake queue rarely makes the list, even when the business unit can describe the problem clearly and has budget set aside to solve it.
The work does not disappear while it waits. Teams build it themselves in spreadsheets, shared mailboxes, and departmental tools that someone configured once and nobody in IT recognizes. Information is rekeyed between the ERP, the CRM, and the service desk, approvals live in email threads, and a single analyst often holds the logic that keeps the process running from one period to the next.
That pattern creates a risk the company eventually has to deal with. A tool built outside IT tends to lack single sign-on, an audit trail, backups, and a support path, so it becomes a finding in an audit or a security review. A properly scoped application built with an outside team can solve the business problem and close those gaps at the same time.
Bring IT and enterprise architecture in before deciding how to build.
Going around IT rarely works for long. The business unit usually sponsors, funds, and scopes the initiative, but IT or enterprise architecture decides where it can run, how it signs users in, which integration patterns are allowed, and who supports it after launch. Engaging them at the start turns a potential veto into a set of clear requirements the outside team can design for.
A short written brief helps that conversation. It describes the process, the people involved, the systems of record the workflow touches, the data it handles, and what success looks like for the division. IT can then say which standards apply, whether an existing platform should be extended instead, and which internal owners need to review the design before any build begins.
Sometimes that conversation shows the right answer is configuration of an existing platform such as ServiceNow or Salesforce, handled by a team IT already uses. When the need sits between platforms, or the platform would need heavy customization to fit, a custom application beside the systems of record is often the cleaner choice and easier to support.
Treat security review, vendor onboarding, and procurement as part of the work.
Enterprise security teams review any vendor that will touch company systems or data. Expect questionnaires about access control, encryption, data handling, incident response, and subcontractors, and often an architecture review of the proposed application itself. An outside team that has written down its architecture, data flows, and hosting plan before the review starts makes the process far less painful for everyone involved.
Vendor onboarding and procurement follow a separate path. Most large companies contract through a master services agreement with a statement of work for each phase, and the business unit sponsor usually has to shepherd the paperwork through legal, procurement, and finance. Starting that process as soon as the scope is agreed keeps it from holding up the first phase of work.
Access during the build should follow least privilege. Engineers sign in through the company’s identity provider, such as Okta or Microsoft Entra ID, receive only the access each task needs, and lose it at handover. Production data is used only where agreed in writing, and test environments use realistic but non-sensitive records wherever the security team prefers that approach.
Connect the application to the systems of record instead of copying them.
A business-unit application almost always depends on data held in enterprise platforms: orders and materials in SAP or Oracle, accounts in Salesforce, tickets in ServiceNow, people and cost centers in Workday. Each of those systems should stay the record for its data, with the application reading and writing through supported APIs or the company’s existing integration layer, such as MuleSoft or Azure Integration Services.
Copying records into a separate database may seem simpler at first, but it creates a second version of the truth that drifts from the original. Reconciliation becomes a recurring job, and audit teams will reasonably ask which figure is correct. Agreeing on which system holds each record, and how conflicts are resolved, is one of the most valuable decisions in the design.
Approvals and audit trails deserve the same care. Approval rules by amount, region, or role should be written down and tested, and every decision should be logged with who acted and when. Designing roles, approvals, and logging with the company’s audit and security teams means the application supports the internal control framework they already work within.
Plan the handover and support model from the first scope.
The application will outlive the initial project, so decide early who supports it. Some companies want the internal team to take it over completely, with the outside team available for later phases. Others prefer ongoing support from the outside team alongside IT. Either works, provided it is agreed during scoping and reflected in how the application is built and documented.
A useful handover includes the source code in the company’s repositories, architecture and data flow documentation, runbooks for deployment and common incidents, automated tests, and a walkthrough with the people who will support it. Deploying into the company’s cloud tenancy and pipelines from the first release makes that handover a formality rather than a migration project in itself.
Baybloom builds business-unit applications of this kind for large private and public companies, scoped in writing with the sponsoring division and IT. The enterprise companies page describes the typical first release, the systems involved, and the questions business units ask before starting, and the systems integration page covers connecting to ERP, CRM, and service platforms in more detail.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project