12 Common Modules in Custom Software Applications

Your project may be replacing spreadsheets, connecting disconnected systems, automating a manual process or giving customers access to a new service. Whatever the goal, the visible workflow is only part of what needs to be built.

The supporting modules are what make the application usable day to day. They also contain many of the decisions that affect estimates, security and the cost of future changes.

Related: See how scope and uncertainty affect the budget in our guide to Custom Software Pricing Models.

What is a software module?

A module is a defined area of functionality within an application.

Planning a module does not mean it must be included in the first release. It means understanding whether the application is likely to need it and avoiding decisions that would make it difficult to add later.

Here are 12 modules that appear in a large share of custom software projects.

Authentication confirms who is using the application.

For a small internal system, this might be a basic email and password login. Other applications may require:

• Sign-in with Microsoft or Google
• Multi-factor authentication
• Password recovery
• User invitations
• Single sign-on
• Sessions across several devices
• Access for external customers or contractors

The login screen itself is usually straightforward. Most of the decisions sit around it.

How are accounts created? Can users register themselves, or must an administrator invite them? What happens when an employee leaves? Should access expire automatically? Does the application need to follow a company's existing identity policies?

Authorization decides what that user can see and do.

Authentication and authorization are separate concerns. A user may be signed in correctly while still having access to only part of the application.

A business system might include several roles:

• Employees can create and view their own requests.
• Managers can approve requests from their teams.
• Finance users can access invoices and payment data.
• Administrators can manage accounts and system settings.
• Customers can see information belonging to their organisation.

Permissions often become more detailed as a project develops. Access may depend on a role, department, location, project, record owner or the current stage of a workflow.

These rules should be discussed early. Adding a few roles later is usually manageable. Reworking an application that assumed every user could access everything is a much larger job.

Multi-tenancy allows one application to serve several separate organisations, teams, branches or customers.

Each organisation is treated as a tenant. Tenants may share the same application while keeping their users, settings and data separate. This model is common in SaaS products, client portals and platforms used by several business units.

For example, an inspection platform may be used by 50 companies. Each company should see only its own sites, employees, reports and documents.

Multi-tenancy affects more than the database. It can influence:

• User accounts
• Permissions
• Branding
• Subscription plans
• Reporting
• Integrations
• Notifications
• System administration

A product does not need multiple paying customers to benefit from this structure. The same approach can separate regional offices, franchises, departments or client accounts.

"Users need to upload files" sounds like a small requirement.

It can mean anything from attaching one image to a record through to managing thousands of contracts, certificates or technical documents.

Useful questions include:

• Which file types are allowed?
• How large can files be?
• Who can open or delete them?
• Do files need categories or tags?
• Should previous versions be kept?
• Do documents expire?
• Can users preview files without downloading them?
• Is virus scanning required?

Files may also need to appear in search results, reports, notifications or approval workflows.

The storage button is only one part of the module. The surrounding rules determine whether users can find and manage those files later.

Payment functionality can cover one-off purchases, recurring subscriptions, invoices, refunds, deposits or usage-based charges.

Even a standard payment provider integration requires several decisions:

• What is being charged?
• When should payment be collected?
• Which payment methods are accepted?
• What happens when a payment fails?
• Can customers change or cancel a subscription?
• Are invoices created automatically?
• Does payment data need to reach the accounting system?

Subscription billing introduces its own lifecycle. Plans can begin with a trial, renew, fail, pause, change price or end. Invoices and payment status must remain consistent throughout that process.

The right scope depends heavily on the business model. An internal operations system may only need to display invoices from another platform. A SaaS product may need full subscription management.

Notifications tell users that something has happened or requires their attention.

Common channels include:

• Email
• SMS
• Mobile push notifications
• Notifications inside the application

A useful notification module needs more than a message template.

The system must know what triggers the notification, who should receive it and whether it has already been sent. It may also need delivery logs, retries, user preferences and different templates for each organisation.

Too few notifications leave users unaware of important changes. Too many train them to ignore everything.

It helps to classify them during planning:

Messaging keeps conversations connected to the work they concern.

This could be a comment thread under a support ticket, a discussion attached to an order or a full chat system between users.

The simplest version may contain text comments and timestamps. A broader implementation could include:

• Attachments
• Mentions
• Read status
• Group conversations
• Search
• Editing and deletion rules
• Email or push alerts
• Links to records inside the application

Keeping communication inside the system gives users more context than a separate email chain. Someone opening a case, order or project can see the relevant conversation alongside it.

It also raises questions about access. A comment visible to internal staff may need to remain hidden from the customer attached to the same record.

Most business applications do not operate alone.

They exchange information with accounting software, CRMs, calendars, payment providers, warehouse systems, mapping tools, identity providers and other services.

The visible requirement may sound simple:

Connect the application to our CRM.

The project still needs to define:

• Which information moves between the systems?
• Which system owns each piece of data?
• Does data move in one direction or both?
• How often should synchronisation happen?
• What happens when one system is unavailable?
• How are duplicates and conflicts handled?
• Who can see integration errors?

Integrations often become essential to the surrounding business process. Once a workflow depends on data flowing between systems, the rules for ownership, synchronisation and error handling matter as much as the connection itself.

Some information should appear as soon as it changes.

Examples include:

• Live operations dashboards
• Delivery and vehicle locations
• Stock availability
• Chat messages
• Task assignments
• Collaborative editing
• Progress of long-running jobs

Real-time functionality allows the application to send an update to connected users instead of waiting for them to refresh the page.

It is useful where several people are working with the same fast-changing information. It is unnecessary for many administrative screens.

Choosing where real-time behaviour matters keeps the application responsive without adding complexity everywhere.

An audit log records who did what and when.

It might show that:

• A user changed an order status.
• A manager approved a request.
• An administrator edited someone's permissions.
• A document was replaced.
• An integration updated a customer record.
• A payment was refunded.

This history helps with support, accountability and compliance. It also resolves ordinary workplace questions.

When a value looks wrong, the team can see whether it came from a user, an import or an external system.

The scope should be clear. Some applications only need a readable activity timeline. Others need a protected audit record containing previous and new values that users cannot edit or delete.

Reporting turns stored data into information people can use.

This may include dashboards, tables, charts, downloadable reports or scheduled summaries.

The difficult part is often defining the figures.

Two people may use the word "revenue" while referring to different things. One means invoices issued. Another means money received. A third subtracts refunds and tax.

Before building a report, the team should agree on:

• What each metric means
• Which records are included
• Which date is used
• How filters work
• Who can see the results
• How often the data updates
• Whether the report can be exported

Operational reports also change as teams begin using the application. Early versions should focus on decisions users need to make rather than filling a dashboard with every available number.

Imports help move existing data into the application. Exports let users take information out again.

Both are easy to underestimate.

A data import may need to:

• Match spreadsheet columns to system fields
• Validate dates, amounts and required values
• Detect duplicates
• Show errors without rejecting the entire file
• Update existing records
• Record who performed the import

Exports have their own requirements. Users may need CSV files for analysis, spreadsheets for finance, PDFs for customers or structured data for another system.

Permissions matter here too. Someone who can view a small selection of customer records should not automatically be able to export the entire customer database.

Import tools are particularly valuable during onboarding. Without them, teams may spend days entering data manually before they can begin using the new system.

Plan early, then build in stages

Few applications need every module in their first release.

An internal tool may start with authentication, permissions, file uploads and a basic report. Payments and multi-tenancy may never be required.

A SaaS product could need account separation and subscription billing from the beginning, while leaving advanced reporting for a later phase.

Early planning is about identifying likely needs, not building a framework for every possible future idea.

A useful exercise is to classify each module as:

• Required for launch
• Likely to be needed later
• Unlikely to be needed

That short discussion can reveal dependencies before development begins.

For example, reporting may be scheduled for phase two, but the application still needs to capture the right data during phase one. Multi-tenancy may be planned for later, but early decisions about user accounts and data ownership can determine whether that expansion is straightforward.

Modular architecture can make future changes easier, provided the boundaries between parts of the system are clear.

Questions to ask before development starts

You do not need a technical specification for every module on day one. You should be able to answer a few practical questions:

1. Who will use the application?
2. Will users belong to different companies, teams or sites?
3. Which roles need different access?
4. What files will users store?
5. Which existing systems must connect to the application?
6. Which actions should be recorded in the activity history?
7. What information needs to update immediately?
8. What reports will people use to make decisions?
9. How will existing data enter the system?
10. What data may need to leave it?

The answers affect estimates, screen designs, data structures and the order in which features should be built. Choosing a partner who asks these questions early is part of the process too, and our 7-step strategy for choosing a reliable software development company covers how to evaluate that.

FAQ: Common custom software modules

Summary

The main feature explains why a custom application exists. These supporting modules determine how well it works once people start using it.

Use the list during early planning. Decide what is needed now, what is likely to come later and what the application can safely ignore.

You can build the product in stages. The foundations should still account for the direction it is likely to grow.