When Does a Growing Business Need a Client Portal or Custom Application?

Growing businesses often reach a point where existing tools begin to feel strained.

Employees may be copying information between systems.

Customers may be emailing documents that could have been submitted through a structured process.

Teams may be tracking requests in spreadsheets.

Important information may live across several platforms that do not communicate well.

At that point, someone often says:

“We need an app.”

Maybe.

But a custom application should not be the first assumption.

The real question is:

“What is the business trying to accomplish, and what is the simplest sustainable way to support it?”

Sometimes the right answer is existing software.

Sometimes it is better configuration.

Sometimes it is integration or automation.

Sometimes a client portal makes sense.

Sometimes low-code can solve the problem.

And sometimes the business truly does need a custom application.

The decision should begin with the process and business requirements, not the technology label.

Start With the Business Process

Before discussing portals or applications, document what is happening today.

Ask:

• What process are we trying to improve?
• Who uses it?
• What information moves through it?
• Where does the process begin?
• What happens next?
• Where are the delays?
• Where is information re-entered?
• What requires manual follow-up?
• What causes errors?
• What requires judgment?
• What systems are already involved?
• What does success look like?

A vague requirement such as:

“We need a customer portal”

is not enough.

A stronger requirement might be:

“Customers need a secure way to submit requests, upload documents, review status, and receive updates without relying on email.”

That definition makes solution choices easier to evaluate.

Do Not Build Software to Fix an Undefined Process

Technology can automate a bad process just as easily as a good one.

If the current workflow is unclear, inconsistent, or full of exceptions, building software around it can make those problems harder to change later.

Before development, determine:

• whether the process is standardized
• where business rules exist
• which steps are actually necessary
• which exceptions matter
• who owns each stage
• which decisions require human judgment
• what should be automated
• what should remain manual

Sometimes the most important work happens before any application is built.

Existing SaaS Should Usually Be Evaluated First

Many common business needs already have mature software categories.

Examples include:

• CRM
• project management
• accounting
• ticketing
• scheduling
• document management
• e-commerce
• HR
• marketing automation
• customer support
• learning management

If a commercially available product meets most of the need without forcing the business into a poor process, buying may be more practical than building.

Advantages may include:

• faster implementation
• mature functionality
• ongoing vendor updates
• established support
• security capabilities
• integrations
• documentation
• predictable product roadmaps

The important question is not:

“Can we build this ourselves?”

It is:

“Would building this create enough business value to justify owning the solution?”

Configuration May Solve More Than You Think

A business may already own a capable platform that is not being used effectively.

Before replacing or rebuilding, evaluate whether the current system can support the need through:

• configuration
• forms
• permissions
• workflows
• dashboards
• notifications
• automation
• integrations
• templates
• custom fields
• extensions

Sometimes a “software problem” is actually an implementation problem.

The business may need a better-designed process inside an existing platform rather than a new application.

Integration Can Remove the Need for a New Application

A disconnected process may feel like an application problem when the underlying issue is that systems do not exchange information.

For example:

A website form may already collect the right information.

The problem may be that employees then manually copy it into the CRM.

A CRM may already contain the customer record.

The problem may be that another system cannot access the data it needs.

An application may already support the workflow.

The problem may be that notifications, approvals, or status updates happen elsewhere.

Before building another system, ask whether connecting existing tools would solve the real problem.

Read: Is Your Website Actually Supporting Your Business Goals?

When Low-Code or No-Code May Be Enough

Low-code and no-code platforms can be useful when the business needs more flexibility than standard software provides but does not require a fully custom engineering effort.

Microsoft's current Power Apps documentation, for example, describes low-code business applications that can connect to many data sources, support business logic and workflows, and be extended by developers when specialized capabilities are needed.

The broader lesson is not that every business should use Power Apps.

It is that there is now a meaningful middle ground between:

Buy standard software

and

build everything from scratch.

Low-code may be appropriate when:

• the process is reasonably well understood
• the workflow is business-specific
• the user population is defined
• integrations are supported
• the required experience fits the platform
• the business accepts the platform's constraints
• governance and maintenance can be managed

Do not present low-code as universally faster, cheaper, or easier.

When a Client Portal May Make Sense

A client portal may be useful when external users repeatedly need secure, structured access to information or services.

Examples may include:

• submitting requests
• uploading documents
• reviewing status
• accessing reports
• viewing account information
• completing forms
• communicating around a defined process
• retrieving approved files
• managing recurring interactions

A portal may reduce reliance on:

• shared inboxes
• email attachments
• repeated status requests
• manual document routing
• disconnected customer communications

But the portal still needs a clear business purpose.

A portal that simply reproduces information available elsewhere can create another system customers and employees must manage.

When a Custom Application May Be Justified

Custom software may become more reasonable when the required capability is:

• central to how the business operates
• materially different from available software
• difficult to achieve through configuration
• difficult to solve through integration
• strategically differentiating
• used frequently enough to justify ongoing ownership
• expected to evolve with the business

AWS's architectural guidance on build-versus-buy decisions emphasizes considerations such as business differentiation, opportunity cost, and vendor lock-in rather than assuming one answer fits every situation.

The key question is:

“Does owning this software capability create enough business value to justify building, operating, securing, and maintaining it?”

Custom Means You Own More Than the Initial Build

One of the most common mistakes in custom application decisions is evaluating only development.

The business also needs to consider:

• hosting
• security
• authentication
• authorization
• backups
• monitoring
• logging
• integrations
• data management
• testing
• accessibility
• support
• documentation
• upgrades
• dependency management
• bug fixes
• user administration
• vendor management
• incident response
• future enhancements

A custom application becomes an operating responsibility.

The cost and effort do not end at launch.

Think Carefully About Data

Applications and portals usually exist because users need to create, view, change, or exchange information.

That makes data design central to the decision.

Ask:

• What information will the system store?
• Where does that information originate?
• Is another system already the authoritative source?
• Who should be able to see it?
• Who can change it?
• How long should it be retained?
• Does it contain sensitive information?
• Does it need to synchronize with another system?
• What happens if synchronization fails?
• How will duplicate records be prevented?
• How will data be exported if the system changes later?

Poor data decisions can turn a useful application into another silo.

Identity and Access Matter More With External Users

A customer-facing portal introduces additional considerations.

The business may need to determine:

• how users register
• how identities are verified
• how passwords or other authentication are handled
• whether MFA is appropriate
• what users can see
• whether users can access only their own records
• how permissions change
• how accounts are disabled
• how administrators are controlled
• what happens when a customer's relationship ends

Authentication is not simply a login screen.

It is part of the security model.

Do not make unsupported claims that one authentication method is universally appropriate.

Integration Complexity Can Change the Decision

A proposed application may sound simple until the business identifies everything it needs to connect to.

Potential dependencies may include:

• CRM
• accounting
• payment processing
• email
• identity provider
• document storage
• scheduling
• ERP
• ticketing
• reporting
• data warehouses
• third-party APIs

Every integration introduces questions about:

• reliability
• authentication
• data mapping
• rate limits
• error handling
• monitoring
• vendor changes
• ongoing maintenance

A custom user interface sitting on top of six fragile integrations may not be a simple application.

Consider the User Experience on Both Sides

A portal or application may serve more than one audience.

External users may need:

• simplicity
• clear navigation
• mobile access
• status visibility
• useful confirmations

Internal users may need:

• review queues
• approvals
• search
• reporting
• escalation
• history
• administrative controls

Improving the customer experience while creating significantly more work for employees is not necessarily a successful design.

Both sides of the process should be considered.

Ask Whether the Process Requires Human Judgment

Not every step should be automated.

Some processes require:

• review
• discretion
• approval
• exception handling
• professional judgment
• customer conversation

A well-designed application should support those decisions rather than forcing them into rigid automation.

Identify where the system should:

• automate
• recommend
• route
• notify
• collect
• validate

and where a person should still decide.

Evaluate Vendor Lock-In and Portability

Every technology choice creates dependencies.

That includes:

• SaaS
• low-code platforms
• cloud services
• development frameworks
• custom vendors
• proprietary databases

AWS specifically identifies vendor lock-in as an important consideration in build-versus-buy decisions because switching later can involve financial cost, effort, and time.

Before committing, ask:

• Can we export our data?
• Who owns the code?
• Who owns the configuration?
• What happens if the vendor changes pricing?
• What happens if the platform changes?
• Can another provider support the solution?
• How difficult would migration be?
• What documentation will we have?

Avoid pretending lock-in can always be eliminated.

The goal is to understand it and make an informed choice.

Do Not Ignore Governance

Applications often start as small projects and become important business systems.

Governance should address:

• ownership
• access
• data responsibility
• changes
• vendor management
• security
• support
• documentation
• roadmap decisions
• cost
• lifecycle

Someone should know who is responsible for the system after launch.

“IT handles it” is usually not enough.

A Practical Decision Sequence

A growing business can evaluate the options in this order:

1. Define the process

What problem are we solving?

2. Review existing capabilities

Can a current system already support it?

3. Evaluate standard software

Does an established product meet the need?

4. Consider configuration

Can the requirement be achieved through better setup?

5. Consider integration or automation

Is the real problem disconnected systems?

6. Evaluate low-code / no-code

Would a configurable application platform fit the process and governance needs?

7. Evaluate a portal

Do external users need recurring, structured access?

8. Consider custom development

Does the business need a capability that existing options cannot reasonably provide?

9. Evaluate operating responsibility

Who will own, secure, maintain, support, and improve it?

This sequence helps prevent custom development from becoming the default answer.

Questions to Ask Before Building

Leadership should be able to answer:

• What business problem are we solving?
• Who will use the solution?
• How frequently?
• What information will it manage?
• What systems must it connect to?
• Is existing software available?
• Could configuration solve the problem?
• Could integration solve the problem?
• Could low-code reasonably support it?
• Do external users truly need a portal?
• What requires custom behavior?
• What security and access requirements exist?
• Who owns the data?
• Who will maintain the system?
• What happens when requirements change?
• Can we move our data elsewhere later?
• What happens if the vendor or developer is no longer available?
• Is this capability strategically important enough to own?
• What is the cost of not solving the problem?
• Are we fixing a real business constraint or simply adding another tool?

Signs You May Be Ready for a Portal or Application

A more tailored digital solution may deserve evaluation when:

• customers repeatedly request status or information
• employees manually coordinate recurring customer interactions
• email is carrying structured business processes
• spreadsheets are acting like databases
• information is entered into several systems
• existing software forces significant workarounds
• customers need secure recurring access
• manual errors affect service delivery
• disconnected systems are delaying work
• the business process has become stable enough to define clearly
• the capability has become important to customer or operational experience

These are signals to evaluate options.

They are not proof that custom development is required.

Signs You Should Probably Not Build Yet

The business may need more discovery before building when:

• the process is still changing constantly
• nobody owns the process
• requirements differ dramatically depending on whom you ask
• the main problem has not been defined
• a capable existing platform has not been evaluated
• integration options are unknown
• the data is poorly organized
• no one will own the solution after launch
• the business expects software to fix a management problem
• there is no plan for security, support, or maintenance

Building too early can turn uncertainty into technical debt.

The Goal Is the Right Business Capability, Not Custom Software

The success of a technology decision is not measured by how custom the solution is.

A standard SaaS platform may be the best answer.

A configured CRM may be enough.

An integration may remove the bottleneck.

A low-code application may provide the necessary flexibility.

A portal may improve recurring customer interactions.

A custom application may be justified when the capability is important, distinctive, and difficult to achieve another way.

The strongest decision is the one that solves the real business problem while creating a level of complexity, ownership, cost, and risk the organization can responsibly sustain.

Explore: Websites, Applications & Digital Experience

Key Takeaways

• •Define the business process and requirements before choosing a technology label.
• •Evaluate existing SaaS, configuration, and integration before assuming a new build is needed.
• •Consider low-code as a middle ground when standard software is too rigid and custom development is too heavy.
• •A client portal is justified by recurring, structured external access, not by novelty.
• •Custom software means owning hosting, security, maintenance, and upgrades, not just the initial build.
• •Understand vendor lock-in and data portability before committing to any platform.
• •The right decision solves the real business problem at a level of complexity the organization can sustain.

Sources and References

1. AWS Architecture Blog — Let's Architect — Understanding the build versus buy dilemma (source)
2. Microsoft Learn — Power Apps documentation (source)
3. Microsoft Learn — Get started building apps (Power Apps maker) (source)
4. Microsoft Power Apps — Power Apps overview (source)

Related Insights

Related Services