A new module inside an existing portal
At an insurance technology provider, I worked in a three-person team on a broker portal that was already in production. The platform supported the process from contract signing to submitting applications to insurance carriers. Architecture and senior development were part of my responsibilities over 20 months.
Within that environment, a support chat went from concept to production in two months. The portal extension included a dedicated Node.js API backend alongside the existing TYPO3 platform and a frontend built with Vue.js. Responsive design was a requirement from the start. Development of the platform continued in parallel, including additional insurance carrier integrations.
Those two months describe this particular project. For another portal, the effort depends on the required functionality and the foundations already available. My main conclusion for similar initiatives is to define the first useful workflow and its boundaries early.
Describe the workflow before listing features
“We need a chat” leaves considerable room for interpretation. It could mean a quick question for support, a conversation that remains available over time, or an entire system for managing service requests.
For a comparable initiative, I would first describe a workflow: a signed-in user asks a question, someone responsible takes it on, both can continue the conversation, and they can tell when it is complete.
That workflow provides a basis for assessing the initial scope. Does it already require attachments, automatic assignment across several teams, or integration with a ticketing system? Those capabilities may be necessary. Each should follow from the actual work people need to do.
These are planning recommendations for a new project. Users and support staff should decide together which additional capabilities their tasks require.
Clarify the boundaries with the existing platform
A separate backend component creates room for design decisions. It also needs clear connections to the application around it.
Before implementation, I would establish how the chat recognises an authenticated user, who may access each conversation, and where the authoritative conversation history lives. Ownership of changes matters just as much: if the portal changes its user management, who checks the effect on the chat?
A short, shared description of the interfaces is useful here. It should explain which information crosses each boundary, which component owns it, and how failures become visible. An additional backend helps only when those responsibilities remain understandable.
Node.js and Vue.js were part of this project. For a .NET platform, I would equally consider the team's existing skills and operating practices. This example is no reason to introduce the same stack into every environment.
Keep the scope small and complete the core workflow
A small initial feature set still needs to support the chosen workflow reliably. I would define acceptance around concrete situations:
- An authorised person can open a conversation; an unauthorised person cannot access it.
- Reloading the page restores the expected conversation state.
- When sending a message, the user can tell whether it was accepted or another attempt is needed.
- On a narrow screen, the input, history, and status remain usable.
- Outside staffed support hours, users understand what response they can expect.
These are checks I would agree with a team today. They are not a complete technical specification, but they reveal decisions hidden behind an apparently simple interface.
Unclear feedback directly affects behaviour in a chat. Someone who cannot tell whether a message arrived may send it again or pick up the phone instead. Understandable states therefore belong to the core functionality.
Plan how support will operate the service
Technical deployment marks the start of the support team's use of the feature. Before launch, I would establish who monitors new conversations, how handovers work, and who makes decisions during an incident.
Conversation content also needs consideration: what information should users provide, who needs access, and how long is the content needed? The answers become requirements for implementation and operation.
For rollout, I would also describe how to disable the new feature if problems arise and which contact route remains available. The existing portal must be able to continue performing its other tasks.
These decisions need time in the project plan. Leaving them until development is complete simply moves the work into the launch phase.
What carries over to other projects
The result was a production-ready support chat extending a live platform. It does not establish a fixed delivery time for other projects. The transferable question is how a new module meets a specific need while fitting into existing workflows.
For your next extension, I would start with one page: who uses the feature, which workflow must work completely, which interfaces it touches, and how the team will recognise that it is ready to operate.
Once these points are clear, the effort can be discussed much more concretely than it can from a long wish list.
I help companies plan and implement new capabilities within existing web and .NET platforms. In a free introductory call, we can discuss a useful initial scope for your project.