Insurance platform · Employer-owned · Live production
ATI
Access Trust Insurance is a public insurance website and multi-role service platform developed at Achour Holding. I built its backend, content-management system, client, agent, and admin portals, and handled its production deployment. The platform supports proposal, claim, complaint, document, and meeting workflows.

My contribution
I worked on ATI at Achour Holding with Tayseer Laz, who primarily worked on the public-facing website. I owned the backend, the content CMS, the client, agent, and admin portals, and production deployment.
That scope connected the public website to the operational paths behind it: managing website content, receiving insurance requests and documents, routing work to staff, and giving each role an appropriate interface for following the request.
One platform, four working surfaces
- Public websiteManaged content and service entry points
The content CMS supports the public information layer, while forms and calls to action lead into the appropriate service workflows.
- Client portalRequests, documents, and status
Clients can move beyond a contact form into structured proposal, claim, complaint, document, and meeting journeys.
- Agent portalAssigned work and follow-up
Agents receive routed work and the context needed to continue a request without turning the public website into an internal dashboard.
- Admin portalOversight and configuration
Administrators manage content, users, assignments, submissions, and the operational settings that support the public and authenticated experiences.
Technical delivery
The central delivery problem was not adding isolated forms. It was carrying a request from a public entry point into authenticated, role-specific follow-up while preserving the information and documents needed by the people handling it.
Operational workflow
- 01 · EnterStart from the right service
A visitor begins with a proposal, claim, complaint, meeting, or information request through the public site or client portal.
- 02 · CaptureCollect structured context
The backend receives the request, relevant answers, and permitted supporting documents instead of reducing every journey to an unstructured message.
- 03 · RouteAssign operational ownership
The workflow directs the request to the appropriate staff path and keeps its status available to the roles responsible for follow-up.
- 04 · ContinueWork through role-specific portals
Clients, agents, and administrators see different interfaces around the same service journey, with each surface focused on its own responsibilities.
- 05 · OperateDeploy and maintain the full path
I handled production deployment and continued fixing the application around real content, email, storage, workflow, and release needs.
Delivery ownership
- Backend and workflow layer
- I implemented the server-side application behind authentication, submissions, routing, documents, email, and the shared operational state used by the portals.
- CMS and portals
- I built the content-management system and the client, agent, and admin experiences rather than treating the public website as the whole product.
- Production deployment
- I owned the deployment path and the production fixes required to keep the public website and authenticated workflows operating together.