From our work
Two digital insurance brokerages, two different engineering jobs
EasyInsurance in Pakistan and LuckyTruck in the US took different routes to selling insurance online. The team now at Rubix Labs handled the engineering for both platforms. Both launched and sold insurance. Here's the part we can explain from our own work: how the software connected each customer's journey to the people and systems behind it.
EasyInsurance started with a person choosing cover
EasyInsurance brought health, travel, auto and life insurance into a marketplace. A customer could explore a category, compare plans and continue toward a purchase, with a route to claims assistance afterward. Our engineering covered the marketplace experiences and integrations behind those journeys.
Look at the portfolio image above. The categories share a front door, but the questions behind them can't all be the same. A travel purchase needs a different conversation from a health-plan comparison. Keeping those journeys recognizable as one product doesn't mean forcing every product into one form.
If we were planning a marketplace today, we'd look for the parts customers could use across categories, such as navigation and account access. We'd leave room for the business owners to define each product's questions, plan details and insurer-dependent steps. A consistent design can accommodate those differences.
EasyInsurance has its own engineering team today. The live site has continued to evolve, so our case study describes our earlier delivery rather than claiming every feature you can see now.
LuckyTruck also had to work for the people behind the quote
LuckyTruck focused on commercial trucking insurance in the US. Our work connected the customer experience with operations interfaces, Salesforce and Zoho quote workflows, carrier integrations, documents and AWS services. The published engineering account covers selected work from 2021 to 2024.
For a customer, requesting a quote is one task. For the product, that request involves account information, vehicles, drivers, documents and a carrier-specific journey. An operator may already have useful information in a CRM. The engineering has to connect that working environment to the customer journey.
Our integration chapter shows the range of that work: Salesforce components and jsforce, Zoho embedded applications, service endpoints and browser automation served different parts of the platform. Those details matter because an embedded CRM tool, a service call and an automated application journey need different permissions and maintenance. A carrier name alone doesn't describe the connection.
The document work included signing, driver-license extraction and review, and motor-carrier data. AWS provided the delivery platform across containers, serverless services and databases. The case-study chapters separate those responsibilities so you can look beyond the homepage.
The same label hid different product decisions
A shopper comparing insurance categories and an operator looking at a fleet record can need quite different things from the next screen. Both may be working toward a policy purchase, but the information they already have and the job they're trying to finish differ.
Here's a simplified way to compare the journeys described in our public cases. It maps product responsibilities, not the clients' private architecture or exact database schemas.
| Part of the journey | EasyInsurance marketplace | LuckyTruck trucking platform |
|---|---|---|
| Starting context | A customer exploring an insurance category | A customer or operator working with a trucking account |
| Information to organize | Product-specific questions and comparable plan details | Account, vehicle, driver and supporting document information |
| Connection to complete | The selected plan and its insurer-dependent purchase steps | The CRM record and its carrier quote workflow |
| Work after the initial choice | Purchase progress and a route to claims assistance | Quote status, documents and operations follow-up |
A sale leaves work for the product to do
Both businesses used software to sell insurance. The engineering brief also included what people needed around the transaction: comparisons and claims assistance in the marketplace, or CRM work, documents and follow-up in the trucking platform. Those parts belong in the product discussion early.
Imagine a fictional customer who completes a payment, then comes back because they can't find their policy document. A successful-payment screen doesn't answer that question. The product needs to distinguish the payment record from the insurer's issuance state and show the customer how to get help. The exact sequence depends on the product and insurer; this is an example for planning, not a client incident.
That's the kind of distinction we'd put in front of the business team while drawing the journey. What has actually happened? What is still waiting on someone else? Which person can resolve it? The insurance specialists own those decisions and authorities. Our job is to make the software represent them clearly.
The businesses moved on, and so did the engineering
Both businesses were later acquired, and our team moved on to help other businesses with their insurance technology. That's part of our account of these projects. We handled the engineering; the public case studies explain the scope of that work.
For us, that history is a reason to show the actual product work. A reader should be able to trace the marketplace journey or open the CRM integration chapter and understand our contribution. We don't treat an acquisition as proof that a particular architecture or technology choice was responsible for the business outcome.
And the software keeps changing. EasyInsurance now has its own engineering team. LuckyTruck's current product may differ from the period our case covers. That's normal for a product that carries on after the original delivery team moves on.
What we'd bring to your insurance product
These projects gave the team experience with both a multi-category marketplace and a specialized trucking workflow. At Rubix, we'd start a new conversation by asking which insurance journey you're building and what already exists around it. A marketplace launch, a CRM extension and a document-heavy operations tool can need very different engineering work.
You can inspect the full EasyInsurance and LuckyTruck cases below. If you're planning a digital brokerage, tell us who needs to use it and what they should be able to complete. A short outline is enough for the first conversation; keep customer records and credentials private. We can help work out what belongs in the first release and which systems it needs to connect.
