Internal tools and third-party services

So far, you have divided an application into two major parts: the frontend that users interact with and the backend that manages rules, data, and behind-the-scenes processing.

But most technology companies rely on additional software that customers never see, and two especially important categories are internal tools and third-party services.

These systems may remain invisible to the user, but they often play a major role in how the product is built, operated, and supported.

What is an internal tool?

An internal toolConcept · lights on your mapinternal toolSoftware created or configured for people working inside an organization: support dashboards, refund panels, moderation and reporting tools. Full applications with frontends, backends, and permissions; their users happen to be employees. is software created or configured for people working inside an organization rather than for the company’s customers.

Imagine that a customer contacts the coffee company because an order was incorrect, and a support agent may then need to find the order, review its status, issue a refund, and add a note to the customer’s account.

The support agent probably does not perform those actions through the same mobile app the customer uses and may instead use an internal dashboard built specifically for customer support. That dashboard is an internal tool.

Examples of internal tools

Companies may use internal tools for:

• Customer support
• Refunds and account adjustments
• Reviewing suspicious transactions
• Managing products and prices
• Moderating user content
• Monitoring orders
• Approving applications
• Managing employees
• Running reports
• Configuring features
• Investigating technical problems

A delivery company might have an internal tool for viewing every active delivery. A bank may have one for reviewing account activity. A social platform may have one for investigating reported content.

These tools are part of the product’s broader system even though customers never interact with them directly.

Internal tools are applications too

An internal tool may contain the same building blocks as a customer-facing product.

It can have:

• A frontend
• A backend
• Business logic
• Stored state
• Authentication and permissions
• Requests and responses
• Connections to databases and other services

The difference is its audience and purpose.

A customer-facing application helps customers use the product, while an internal tool helps employees operate, support, configure, or understand that product.

For example, the customer may see: “Your order has been refunded.”

Behind the scenes, a support agent may have clicked a Refund Order button inside an internal dashboard.

That internal action sends a request to the backend, which verifies the agent’s permissions, applies refund rules, updates the order, and communicates with the payment provider.

Why internal tools affect product planning

Building a feature often requires more than creating the customer-facing experience.

Suppose a team adds the ability for customers to schedule coffee orders. The customer then needs a screen for selecting a time.

But employees may also need tools to:

• View scheduled orders
• Change an order’s time
• Cancel an order
• Resolve scheduling conflicts
• Explain what happened when something goes wrong

This means the visible feature may require an internal operational experience as well.

Experienced product teams often ask:

• How will support investigate this?
• Can an employee correct a mistake?
• Who can view or change this information?
• What happens when the automated flow fails?
• Does the operations team need a dashboard?

The customer-facing experience is only one part of the complete product.

Internal-tool design still matters

Internal tools sometimes receive less design attention because they are used by employees rather than customers.

However, poor internal tools can create real costs.

A confusing dashboard can lead to:

• Slower customer support
• Incorrect refunds
• Data-entry mistakes
• Longer employee training
• Repeated manual work
• Security and permission errors
• Frustrated employees

Internal users may tolerate an imperfect interface because they need it to perform their jobs, but that does not make usability unimportant.

A well-designed internal tool can save substantial time and reduce operational risk.

Build, buy, or configure

Companies do not always build every internal tool from scratch.

They may:

• Build custom software
• Purchase an existing business tool
• Configure a platform for their workflow
• Add custom integrations to a purchased product
• Combine several tools

For example, a company might use existing customer-support software while building a custom panel that displays product-specific account information.

This is an early example of a recurring technical and business decision: should the company build this capability itself or use something another company already provides?

You will examine the build-versus-buy decision more directly later.

What is a third-party service?

A third-party serviceConcept · lights on your mapthird-party serviceA capability provided by an outside company that a product connects to and uses: payments, texts, email, maps, identity, AI. Borrowed running capability (unlike a package, which is borrowed code), gained at the cost of a dependency on the provider. is a capability provided by an outside company that a product connects to and uses.

The company building the coffee app may not want to create its own payment network, text-messaging infrastructure, mapping system, or email-delivery platform when it can instead connect to companies that specialize in those capabilities.

Examples might include:

• Stripe or Adyen for payments
• Twilio for text messages
• SendGrid for email delivery
• Google Maps or Mapbox for maps
• Auth0 or Okta for identity services
• OpenAI or another provider for AI capabilities

Treat the list as examples. A company can choose different providers or build some capabilities itself.

Packages versus third-party services

In Module 3, you learned about packages and libraries, reusable code installed inside a project, but a third-party service is different because the main capability runs on systems operated by another company.

Consider a payment integration. The coffee application may install a package created by a payment provider, and that package helps the app communicate with the provider.

However, the package itself does not operate the payment network. The application sends a request to the provider’s remote systems, and those systems perform the payment work.

The distinction is: a package is borrowed code that becomes part of your project. A third-party service is borrowed capability running on someone else’s systems.

Many integrations use both. The team installs the provider’s package and uses it to communicate with the provider’s service.

Why companies use third-party services

Third-party services allow teams to add sophisticated capabilities more quickly. A startup can accept payments without forming direct relationships with every bank and card network, send emails without operating large mail servers, and show maps without building a global geographic database.

This allows the company to focus its engineering effort on what makes its own product different.

Third-party services can provide:

• Faster development
• Specialized expertise
• Established infrastructure
• Security and compliance capabilities
• Scalability
• Documentation and support
• Features that would be expensive to build internally

This is another example of abstraction. The product uses a defined capability without managing all the machinery behind it.

The cost of depending on another company

Using a third-party service creates a dependency.

If the service becomes unavailable, the features depending on it may stop working.

If the payment provider has an outage, checkout may fail. If the messaging provider is delayed, confirmation texts may arrive late. If the map service changes its pricing, the product’s operating costs may increase.

Third-party dependencies can introduce risks involving:

• Outages
• Slow responses
• Price increases
• Usage limits
• Breaking changes
• Security
• Privacy and data handling
• Legal or regulatory requirements
• Features the provider does not support
• Difficulty moving to another provider

The company gains speed and capability, but it gives up some control.

A useful way to describe the tradeoff is: the company avoids building the entire capability, but now depends on the provider to keep it available, secure, and compatible.

What happens when a third-party service fails?

Imagine that the coffee app sends a payment request to its payment provider. The coffee company’s own frontend and backend may be working normally, but the payment provider may be unavailable.

The backend now needs to decide what to do.

It might:

• Show the customer an error
• Retry the request
• Ask the customer to try again later
• Use another provider
• Save the order as pending
• Alert the engineering team

This demonstrates why a product can fail even when its own code is not the original cause. Software systems are connected through dependencies, and one company’s failure can become another company’s customer experience.

Internal versus external systems

It is helpful to distinguish between internal and external systems.

An internal system is operated within the company or primarily used by its employees. An external system belongs to another company or serves users outside the organization.

The coffee product might include:

• A customer-facing mobile frontend
• A backend order system
• An internal support dashboard
• An internal analytics tool
• An external payment service
• An external email provider
• An external mapping service

Each system has its own responsibilities, users, data, and boundaries, and they must communicate in controlled ways, which is where APIs and integrations become essential.

Seeing the complete product

A “simple” coffee application may actually contain many connected pieces.

The customer uses the frontend to place an order, and the backend validates the request, applies business logic, and stores the order.

A third-party payment service processes the charge. Another provider sends the confirmation message. A mapping service helps locate the café.

If the customer contacts support, an employee uses an internal tool to view the order and possibly issue a refund.

The full system is one backend in the middle of everything:

The visible application is only the front door into a much larger product system.

The mental model to remember

An internal tool is software used by employees to operate, support, configure, or understand a product.

A third-party service is a capability provided through systems operated by another company.

A package gives a project reusable code. A third-party service provides remote running capability.

Internal tools often support the customer-facing experience behind the scenes.

Third-party services help companies build faster, but they create dependencies involving reliability, cost, security, and control.

You should now be able to look beyond the customer-facing application and identify the internal and external systems that help the product operate.