My role
HomeMatch AI is a seeker-paid AI agent that ranks Dutch home listings on a seeker’s hard and soft wishes and explains each recommendation. My part was the business model, pricing, economics and alternatives considered. That meant answering the question the team could postpone: even if the agent works, who pays for it, how much, and what is left after costs? I started with a business view of the idea and expected the technology to be the hard part. The harder part turned out to be capturing the value.
Deciding who pays
We had three options: a seeker subscription, a success fee or agencies paying for better-matched applicants. I chose a seeker-paid subscription of €24.99 for 30 days, and this was my own decision. Home search is intensive but temporary, so an annual plan did not fit the customer journey. A 30-day pass also lets people search heavily without paying per query.
Before this project I saw pricing as deciding how much customers will pay. Rejecting the alternatives taught me that the payer also shapes the product. If agencies paid, a recommendation could favour the paying agency over the seeker. That would undermine our claim that HomeMatch works for the seeker, which is the trust problem from Session 7. A success fee aligned incentives better, but the lease happens outside HomeMatch, so we could neither observe or attribute it (Session 4). Pricing, I learned, decides whose interests the product serves.
Where my first estimate went wrong
My economics slide began with a cheap-model assumption. I put the AI cost at about €0.50 per user per month, so contribution was roughly €15.70 per user after VAT and other costs. My headline said the LLM was cheap to scale.
Then I checked which model our prototype actually runs on: Claude Opus 5.5, a top-tier model with far higher token prices. I recalculated with its published prices and my own usage assumptions of 25 listings screened per day, including thinking tokens. The AI cost rose to about €14 per user, roughly thirty times my first number, and contribution fell to €1.84 before listing-access costs. I rewrote the slide. The new headline says the LLM can erase the margin, and cost controls make the model viable.
What surprised me was that I had treated model choice like a performance question. It is also a cost-structure decision and it changed my section more than any strategic argument did. Session 4 says AI adds variable inference costs to the classic information-goods logic, but I only took that seriously once I saw it in my own numbers.
I then modelled three levers: filtering listings before the model sees them, using a cheaper model for a first pass, and batching non-urgent screening. Together they lift contribution to about €14, a 70% margin. These are assumptions we have not tested, and I have not checked whether a cheaper model ranks soft wishes well enough. The other cost lines (hosting, maps, payments, support) are also illustrative.
Pricing: what my evidence did not prove
For the price, I used existing alert services as a benchmark. Customers already pay around €29.95 per month for these services, so I saw this as evidence that people are willing to pay for help with housing search. Because I believed HomeMatch offered additional value through ranking and soft preferences, €24.99 seemed like a reasonable starting price. However, I later realised that this only provided a market benchmark. It did not prove that customers valued HomeMatch itself at €24.99. Looking back, this was one of the main weaknesses in my analysis. If I could do the project again, I would test willingness to pay directly instead of only using market benchmarks.
The evaluation results sharpened this, even though I was not the person who carried out the testing. Our main assumption was that HomeMatch would find more relevant homes and do so faster than manual search. The results showed that HomeMatch was much faster for renters, but the average relevance score was exactly the same as manual search (both 4.36). For buyers, HomeMatch was even slower in the test. This mattered for my business-model section because the case for paying €24.99 becomes weaker if the product does not yet produce better matches. It made me realise that the business model depends directly on the evidence behind the value proposition. We therefore became more careful in the final recommendation and stopped claiming that HomeMatch already produces better matches. Before charging a premium based on better fit, we would first need evidence that the improved version actually produces better matches.
I also underestimated customer acquisition. A successful user finds a home and stops paying, so success creates churn. About two paid months give roughly €25 of contribution, which caps what we can spend to win a user. Access to listings is another dependency, because platforms and agencies control the supply.
What I learned from collaboration
We divided the project into different parts, but the sections were more connected than I expected. My pricing depended on the target group. My economics depended on technical choices made in the prototype. The choice of who should pay depended on the trust argument from the ecosystem analysis. The evaluation then affected whether the value proposition behind my business model was strong enough. We also had no major external feedback on the proposal, so we had to challenge many assumptions ourselves. Internal deadlines helped, but fitting everything into 15 slides forced us to decide together what was really important. I learned that dividing tasks is useful, but everyone still needs to understand how the different parts connect.
How my view of AI and strategy changed
The project changed how I think about AI and business strategy, I initially thought the AI functionality itself would be the main source of differentiation. By the end, I understood that the technology itself is only one part of the strategy. The future-market analysis made me realise that competitors can gain similar AI capabilities, so a lasting advantage has to come from what surrounds the technology like access to listings, relationships, outcome data and trust.
My main learning point from the project is therefore that AI strategy is not mainly about finding more things for AI to do. It is also about deciding where AI creates real value, whether that value can be proven, who should pay for it and whether the business can keep enough of that value over time. If I did the project again, I would measure real token usage from the prototype from the start. I would also test willingness to pay and acquisition cost earlier and check my cost assumptions against the actual system. That would have made the strategy less dependent on what we think users value and more dependent on what the evidence actually shows.
