Building Entitle Guard: my journey

I am Venkatesh Arunachalam, founder and CEO of Entitle Guard. We are now preparing to raise our first round of capital, and before I do that I want to write down honestly how we got here.

This is not a success story yet. It is an account of two years of building, getting things wrong, changing direction and learning from the market, from friends and from family. If you are thinking of starting something later in your career, some of it may be useful.

Where it started

I have spent more than twenty years in technology and consulting, most of it as a product manager and later running consultancies. That work took me across real estate, commerce, governance and financial services. I built products for other people and advised them on theirs, and I was good at it.

In 2024 I started a digital consultancy. At the same time I kept coming back to one problem I had seen in every one of those sectors. Something is bought, a promise comes with it (a warranty, a guarantee, a certificate, a legal right), and then the paper trail scatters. Receipts fade, documents sit in someone’s inbox, and when something breaks nobody can say quickly who is responsible or what the owner is owed.

Entitle Guard is what came out of that. It is the product of my experience across those sectors rather than a sudden idea. I was over forty and under no illusion that I could do everything quickly. Being a consultant product manager and being a founder turned out to be very different jobs.

The first idea was too big

The first version was a consumer app. You photograph a receipt, the app reads it, stores it and tells you what warranty and consumer law cover you have and who to call. Very quickly I was describing the whole life of a purchase: installation, use, repair, resale and disposal, with retailers, manufacturers, installers, repairers and recyclers all connected.

That was my first mistake. A single, simple action (scan a receipt) was carrying an enormous promise. I ran surveys and studied competitors, which was the right instinct, but I was trying to solve many problems that people only have once in a while, before I knew which one would bring them back.

The business side became clearer in 2025. A large electronics brand showed interest in reducing its customer service costs, and that taught me something important: a business has a real economic reason to put this information in front of its customers. We documented the whole system, worked on the pitch, and reached the final round of Techstars. Looking back, I spent a lot of energy on decks, names and architecture before I had evidence that anyone would use the product again and again.

Finding the business that needs it

The shift that mattered was moving the work of capturing information from the consumer to the business. Asking people to scan every receipt means asking them to do a chore before they ever need the benefit. If the information comes from the merchant at the point of sale, it arrives already complete. That led to our Shopify integration and a retailer portal.

Then came construction. A builder handing over a new home already has to assemble the appliances, warranties, manuals and certificates and pass them to the buyer. It is a natural moment with a clear owner, and the homeowner joins at the same time. By late 2025 we were writing detailed requirements for builders: every item in a bill of materials tied to a property, documents attached at item level, and ownership that moves cleanly when a buyer changes.

Those small details taught me more than any strategy session. Editing a property, transferring it to a new owner or removing an entitlement are not polish. They decide whether the record can be trusted after the first upload.

Building more than I should have

In early 2026 I pushed the product upstream into the builder’s daily operations: projects, pricing, construction activities and approvals. I named it EG BuildOS. The reasoning was sound, because if documents are captured during the build, the handover pack builds itself. But I was starting a second product while the first was still young, and I was now competing with tools builders already use every day.

By March we had a consumer app, a builder app, an AI voice receptionist, a receipt reader, an AI service and a new BuildOS build, across seven codebases. The early stages were built with a vendor in India, then an AI developer in Australia, and much of the rest I built myself, increasingly with AI coding tools.

The cracks were ordinary but real. The development app expected a sign in service we had never set up. The AI receptionist went in circles on some calls. The support chat was not good enough to demonstrate. Uploaded files sat on a single server with no backup, and some code still lived in a personal account. None of these was dramatic. Each one taught me that a working demo and a dependable service are different things.

What the market taught me

From April 2026 the platform stopped being something I designed and became something I sold. The market corrected me quickly, and mostly for the better.

Customers do not arrive with clean data. One of the first larger builders wanted us mainly for support but had two years of incomplete records and no full customer list. We built a simple web form so homeowners could register themselves when they contacted the builder. Later I found myself converting builders’ spreadsheets into imports by hand. Onboarding is part of the product.

Developers and builders are often different companies. I had assumed one organisation did both. In much of Australian construction one owns the project and another builds it, so the platform had to separate them, with each seeing only what it should.

The law is local. I prepared a demo for a builder in another state using New South Wales rules that do not apply there. It was an uncomfortable moment and the right lesson. We now hold compliance rules for every state and territory, and the platform knows which apply to each home and on which date.

Sell what the builder owes, not what the software does. For months I talked about digital handover packs. The conversation changed when we started with liability: statutory warranties, a personal duty of care and up to ten years of exposure after handover. Builders listened because it was their problem, described in their terms.

Speak plainly. My natural language is complex and suited to investors. Builders, trades and homeowners need everyday words. We stopped saying “entitlement” to consumers and started saying cover and protection.

Keep pricing simple. I went through several pricing models before settling on a model a builder can say yes to without a procurement process.

One record, many markets

The idea that held everything together was simple: one record per home or asset, created once at the point of sale or handover, and kept for life. Once that record worked for builders, the same pattern fitted other places.

Two builder customers also worked in commercial construction, so we added commercial projects, where the obligations are contractual and run as an annual safety compliance cycle rather than a warranty period. Solar came from my own home. Two installations produced eight documents from four different systems, none linked, with manuals and certificates missing. If that was my experience, it was everyone’s. We added solar installers, then a rental flow for tenants, owners and their agents.

International interest taught me a harder lesson. A large online marketplace in India told us, through a friend, that warranty compliance simply was not a pain for them. Rather than force the pitch, we reframed it as a service their sellers could buy. Test a market against the pain it actually feels, not the one you hope it feels.

The people around me

I did not do this alone. Kannan Hariharan of Australia Digital Ventures has incubated Entitle Guard and helped me in every part of it, from the pitch deck to strategy to the hard questions I would rather have avoided. His reviews were direct, and the product and the story are better for them.

Friends opened doors I could not have opened myself, including the conversations in India and Malaysia, and told me plainly when an idea was not landing. I learnt from my family as much as from customers, and they kept me grounded through the long stretches.

The team today is small: a product manager growing into the role of chief product officer, a fractional CTO, an advisor and a salesperson who has already brought in builders. Each of them has changed how I think.

What I would tell myself in 2024

• Start narrow. Pick the one moment where someone already has to hand over information, and make that moment excellent.
• Let the business capture the data. Do not ask the customer to do the work before they feel the benefit.
• Talk about the customer’s problem in the customer’s words, not yours.
• Get the boring things right early: backups, code ownership, a single source of truth for your numbers.
• Treat your own assumptions as the first thing to test. Mine were usually too optimistic.
• Ask for help sooner. The people who helped me most were happy to, and I should have asked earlier.

Reading that list back, I notice something uncomfortable. Most of these are points I made to founders myself, as a consultant, and often with confidence. It is never easy to eat your own dog food. Advice is simple to give from the outside. When it is your own product, your own money and your own time, every shortcut looks reasonable in the moment, and you only see the pattern afterwards.

The purpose has not changed since 2024. People should know what they are covered for and get it when they need it. Everything else, the products, the segments, the language and the pricing, has changed because the market taught me to change it. I am grateful for every one of those lessons, including the expensive ones.

Where we are in October 2026

Today Entitle Guard is live across builder, trade, merchant and commercial portals, a business mobile app and a consumer app on both app stores, with AI that reads documents, checks compliance by state and answers questions by chat and voice. Builders are signed under contract and paying, and five builders and four trades are on the platform. We run remote first and keep costs lean.

We are raising a seed round to build a proper product team and a sales and marketing function. The reason is honest: for two years, too much has depended on my own time. I have written requirements, reviewed code, converted customer data, recorded videos, priced, modelled and pitched, often in the same week. The next stage needs more hands than mine.