CASE STUDY · LOW-CODE / NO-CODE PLATFORM DEVELOPMENT
Launching a client-facing portal using a low-code framework in 3 weeks.
- 3 weeksLaunched in 3 weeks
- 22%Support emails down 22%
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
A client portal with login and integrations to existing systems. Clients sign in, see the status of their work, download documents and raise requests. The portal reads from the systems the team already uses, so nobody types updates twice.
- 1Clients emailed for updates.
- 2Account managers spent part of every day answering "where are we on this?" by searching internal systems and replying by hand.
- 3Answers differed depending on who replied.
- 4Clients had no way to see their own documents or request changes without writing in.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01In the pilot, one client saw a status that was a day out of date
The portal was caching data from a source system for longer than we realised. We shortened the cache for status fields, added a "last updated" time on every panel, and set an alert for when a sync failed. That made staleness visible to clients and to the team, and stopped it turning into a trust problem.
- PROBLEM 02That made staleness visible to clients and to the team, and stopped it turning into a trust problem
- PROBLEM 03A second hurdle appeared in security review
The client's IT lead asked what would happen if a client user changed an ID in the page address. We tested exactly that, and found one list view that trusted the interface instead of the data layer. It was fixed the same day, and we added the check as a standing test in every release.
- PROBLEM 04We also moved the portal's service accounts to narrower permissions and rotated their credentials, so a mistake in one integration could not reach another system
03 · THE PROCESS
How we ran it.
- 01Week 1
agreed scope with the sponsor and account managers. We chose the five or six questions clients ask most and built only for those. We also confirmed which systems held the truth for each answer.
- 02Week 2
built login, status views and the integrations. Two account managers tested daily.
- 03Week 3
pilot with a small group of friendly clients, fixes, a short guide for clients, and launch.
- 04Step 4
A short stand-up three times a week, and a shared list of open items.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Account managers point clients to the portal first and use email for real conversations.
- NOW 02
New client onboarding includes a portal login on day one.
- NOW 03
The team reviews portal questions each month to decide what to add next, instead of guessing.
- NOW 04
Someone on the client side of the business now owns the portal as a product, with a small backlog and a regular release rhythm.
- 3 weeks
Launched in 3 weeks
- 22%
Support emails down 22%
05 · WHAT WE BUILT
How it works.
- A low-code framework with built-in authentication for external users, kept separate from the internal staff directory.
- Read-only integrations to the existing systems through their APIs, using service accounts with narrow permissions.
- A thin data layer between the portal and source systems, so a slow or unavailable back-end does not break the page.
- Each client sees only their own records, enforced at the data layer and not only in the interface.
- Password reset, session timeouts and activity logging set up from the start.
- Uploads scanned and size-limited before they reach internal storage.
- Monitoring and handover
- We left the team with a simple dashboard showing logins, failed syncs and the questions clients asked most. A named product owner on the client side took over the backlog. Account managers got a one-page guide on supporting a client who cannot log in. We stayed on for a short support window after launch to fix small issues, then stepped back once the weekly issue list was empty.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Clients emailed for updates. Account managers spent part of every day answering "where are we on this?" by searching internal systems and replying by hand. Answers differed depending on who replied. Clients had no way to see their own documents or request changes without writing in.
- What did Brandsmashers build?
- A client portal with login and integrations to existing systems. Clients sign in, see the status of their work, download documents and raise requests. The portal reads from the systems the team already uses, so nobody types updates twice.
- What were the results?
- Launched in 3 weeks; support emails down 22%.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
