Internal tools and customer portals: planning the first release

Internal tools and portals rarely fail because the software was badly built. They fail because the first release tried to serve four departments at once, or because nobody decided who was allowed to approve what until the week before launch. A first release that does one workflow completely beats one that does six workflows partially, and it is a much easier thing to scope.

What counts as an internal tool or a customer portal?

Both are ordinary business applications with a narrow audience. An internal tool gives employees a purpose-built screen for work they currently do across email, spreadsheets and several systems. A portal gives people outside the company (customers, suppliers, tenants, partners) a controlled window onto information and actions that would otherwise arrive as phone calls.

The pattern to look for is a workflow where people already do the work reliably but spend most of the effort moving information between places. That is a good candidate. A workflow nobody agrees on is not a software problem yet. Our guide to build, buy or integrate covers deciding whether custom software is the right answer at all.

How do you scope a first release around one workflow?

Scope creep is rarely dishonesty. It is what happens when a brief is ambiguous enough that every reasonable interpretation produces another conversation and another feature.

1. Pick one workflow with one accountable owner. Not a department, a workflow. A named manager should be able to say whether a design decision is right.
2. Pick one user group. The people who do that work every day. Managers who look at a summary can wait for release two.
3. Write the release as outcomes, not features. "A leasing coordinator can record a maintenance request, assign it to a contractor and see its status" is testable. "Maintenance management" is not.
4. Write the out-of-scope list at the same time. Reporting modules, admin self-service configuration, mobile apps, multi-language support and bulk import tools are the usual candidates for later.
5. Agree what done means. Typically: the workflow runs end to end in production, the pilot group has used it on real work, no blocking defects remain and the agreed accessibility and security checks have passed.
6. Handle additions as change requests. Describe the request in writing, estimate the effect on timeline and cost, and get a decision before it enters the work. This protects the sponsor's budget more than it protects the developers.

Depth matters more than breadth here. A tool that handles one workflow including its exceptions gets used. A tool that handles the easy 70 percent of six workflows sends people back to the spreadsheet the first time something unusual happens. How to write a requirements brief a development partner can use goes further into getting this on paper.

How should roles and permissions work from the start?

Permissions are the single most expensive thing to retrofit, because they touch every screen and every query. Decide them before design.

Start with three or four roles, not a permission matrix. For most first releases that is something like requester, approver, administrator and, for portals, external user. Role-based access control grants permissions to roles rather than to individuals, which is why Microsoft's identity platform documentation describes it as the common mechanism for enforcing authorization in applications: you define app roles on the application, assign them to users or groups, and the identity provider emits them as a roles claim in the token your application checks.

Three rules save trouble later:

• Enforce permissions on the server. Hiding a button is presentation. The check belongs where the data is fetched and changed, so a crafted request cannot bypass it.
• Define roles on the application, not on directory groups alone. Microsoft's guidance is direct about the difference: app roles are defined in the app registration and move with the application, while groups belong to a tenant, so an application that authorizes on group identifiers breaks when it meets a different tenant.
• For portals, scope data by account, not by screen. A customer must only be able to retrieve their own records. That is a rule in the data layer, not a filter on a page.

Record who did what and when, at least for approvals, status changes and anything financial. It costs little during the build and is the first thing anyone asks for when a dispute arrives.

What do integrations and single sign-on actually require?

Two decisions here determine most of the technical risk.

Sign-in

For employees, use the company identity provider. Microsoft Entra ID supports federation-based single sign-on through SAML 2.0, a mature XML-based standard with broad enterprise compatibility, and OpenID Connect, a newer protocol built on OAuth 2.0 that is usually simpler to build with modern frameworks. Password-based and linked options exist for applications that cannot federate, which is useful during phased migrations. The benefits are practical rather than architectural: fewer credentials for users, central policy enforcement, and fewer password resets reaching the help desk.

Plan for joiners and leavers at the same time. Automated provisioning through SCIM, described by Microsoft as becoming the de facto standard for provisioning when used alongside SAML or OIDC, creates accounts when people join and deactivates them when they leave. Doing that manually is exactly the kind of task that quietly stops happening.

Customer portals need a different setup, because the users are not in your employee directory. Microsoft Entra External ID handles this pattern with self-service sign-up, sign-in with local or social and enterprise identities, multifactor authentication, Conditional Access policies and branded sign-up pages. Note that Azure AD B2C has not been available for purchase by new customers since May 1, 2025, so new builds start on External ID.

Integrations

Check feasibility before anyone commits to a date. For each system the tool must touch, establish whether there is a usable API, whether your license tier includes it, who administers the system, what the rate limits are and how good the data actually is. A first release that reads from an ERP and writes nowhere is a very different project from one that creates records in it.

Read before you write. Where the tool must write to a system of record, put it behind one narrow, documented operation with a clear owner, rather than letting several screens update the same data in slightly different ways.

How do you design with the people who will use it?

Involve the people who do the work in discovery and testing, and keep involving them. Three practices do most of the work:

• Watch the work, do not only ask about it. A walkthrough at someone's desk reveals the sticky note with the codes on it, the second browser tab, and the step everyone forgets to mention.
• Show something clickable early. A prototype produces better feedback in twenty minutes than a requirements document produces in a week. Change is cheap at that stage.
• Name your pilot users before you build. Three to five people who actually do the job, with time allocated to use the tool on real work and report back.

Agree the accessibility target in the brief rather than at the end. The Web Content Accessibility Guidelines have three conformance levels, A, AA and AAA, with WCAG 2.2 published in October 2023 and updated in December 2024, and later versions add criteria without changing the earlier ones. Public-sector and enterprise procurement often references a specific level, so pick yours up front: fixing contrast, keyboard navigation and form labels during design costs far less than retrofitting them.

Illustrative example: Consider a property management company with 40 staff handling maintenance requests by email and a shared spreadsheet. The first release covers one workflow for one group: a coordinator logs a request, assigns a contractor, records the quote and tracks it to completion. Owner-facing visibility, invoicing and the mobile view are on the out-of-scope list in writing. Staff sign in with their existing company accounts, three roles exist (coordinator, approver, administrator), and the only integration in release one is a read of the property list from the existing system. Two coordinators and one regional manager pilot it on live requests for three weeks while the spreadsheet is still maintained in parallel. The spreadsheet is retired only once the same volume has flowed through the tool for a full month.

What does a realistic release plan look like?

Two things belong in the plan from the beginning. First, decide how much history moves: migrating five years of records is often a larger job than the application itself, and starting fresh with read-only access to the old system is frequently the better answer. Second, agree who supports the tool after launch, how issues are reported and who can approve changes, because an internal tool with no owner degrades quickly.

How do you measure adoption, and what do you leave for later?

Accounts created is not adoption. Measure the work.

• Share of that workflow's volume going through the tool rather than the old route.
• Share of the target user group using it in a normal week.
• Time per task, compared with the baseline measured before the build.
• Rework, exceptions and items returned for missing information.
• Support requests, and specifically which screens generate them.
• The business measure the sponsor agreed at the start, such as turnaround time or unassigned work.

If the volume share stalls, the reason is usually a missing exception path rather than resistance to change. Ask the people who went back to the old way, and expect a specific answer.

What to leave for later: reporting and analytics beyond a simple list view, administrator self-service configuration, a mobile app when a responsive web page will do, multi-language support, bulk import tooling, notification preferences, and integrations with systems that are not in the first workflow. All of them are reasonable eventually, and none of them are what makes release one succeed. Off-the-shelf, no-code or custom software covers when part of the later list is better solved by buying something.

How Kastling approaches a first release

Internal tools, dashboards and customer or supplier portals sit within Kastling's Custom Solutions service, with or without AI. A well-defined brief can move straight from a free discovery call to a scoped proposal; broader operational work usually begins with a separately scoped paid audit instead.

The approach follows the principles in this article: understand the work before choosing technology, connect existing systems rather than replacing them, involve the people who will use the solution in discovery and testing, keep a named person in control of consequential decisions, and agree data access and ownership up front. Integration feasibility is reviewed (APIs, permissions, data quality, licenses) before commitments are made rather than after. Development is tested against real business scenarios, integration and training are part of delivery, and ongoing maintenance is available under a separate agreement that says what it includes.