Viewery, in hindsight.

Timeline

• 6 November 2025Viewery Ltd incorporated in London.
  A prototype existed by the end of the month and a website by December.
• 16 January 2026Repository opened: Next.js, Convex, two engineers.
  Properties, price history, calendar and a self-generating demo branch by the end of the month.
• February – March 2026Voice feedback, SMS, two-way calendar sync, vendor reports, dashboard.
  458 commits in eight weeks. Selling throughout, on designs, then prototypes, then the MVP; a designer hired and the front end rebuilt when agents made it clear that rough costs the meeting.
• Spring 2026The Renters' Rights Act takes over agents' attention.
  YouTube videos, demos and about a thousand cold calls fill the gap. Discovery keeps pointing at database enrichment and nurturing.
• 27 April 2026Buyer enrichment and feature inference land.
  The buyer profile becomes the product; feedback becomes one of four inputs.
• 8 May 2026Outbound voice agent: ring the buyer, qualify them, update the profile.
  The embeddable demo widget shipped the same day.
• 25 May 2026Last commit.
  The pivot took about two months on early models; the money for further rebuilds ran out.
• 13 July 2026Trade press coverage.
  The Negotiator, Property Soup, PropertyWire. Zero inbound.
• August 2026This write-up.
  Company still registered; the product switched off.

01Where it started

In 2025 a couple of friends were selling their homes, and both were ringing their estate agent every few days to find out what had happened. Had anyone viewed? What did they think? Was the price right? The agent usually didn't know, because the buyers who had viewed had stopped answering the phone.

I had spent about five years in property technology by then, as Product Director at OneDome and later Head of Product at Realyse, and the pattern was familiar. Agents are not short of data. They are short of time, and the tools they have don't do much with the data on their own.

The bigger idea was a data play. Whoever holds a live, structured picture of what buyers actually want, branch by branch, holds something neither the portals nor the CRMs have. But a bootstrapped company can't start there. It needs a wedge: a use case narrow enough to build properly on a small budget, painful enough that agents would let a new vendor in, and shaped for what AI is good at, which is turning things people say into things a system can use.

Viewing feedback met all three. The pain was already in the industry press: one in six vendors change agent while their home is on the market, and the most common reason is not knowing what is going on. Feedback after viewings is collected by hand, chased by negotiators who have no time, ignored by buyers who have already moved on, and what finally reaches the vendor is thin and often softened. That is unfair on the vendor, and it costs the agent both the sale and the instruction. And it is almost entirely spoken: buyers say what they think on the doorstep and nobody writes it down.

When I started talking to agents about it, the numbers behind it were bigger than I expected. A typical branch has somewhere between three and ten thousand buyer records. Most people register, get a few matches, perhaps one viewing, and then go quiet, and nobody has the hours to find out why. Within a couple of weeks of registering, a buyer's profile is already out of date. Feedback was the way in; the database was the prize.

I incorporated Viewery Ltd on 6 November 2025, built a prototype that month, put a website up in December, and had two engineers working in a repository by the middle of January.

02What we built first

The first version did one thing, on purpose: it collected feedback after viewings. The most useful information in a sale is what a buyer thinks in the ten minutes after they walk out of the property, and almost none of it gets captured. Buyers won't fill in a form, negotiators don't have time to chase, and vendors get told that people are thinking about it.

So we made it easy. The branch calendar was synced, so we knew when a viewing had finished. The buyer got a link to a page in the agency's own branding, and a voice agent asked what they thought. It took about a minute, there was no typing, and they could stay anonymous. The transcript was turned into sentiment, price resistance, fixable issues and any offer mentioned, and that rolled up into a report for the vendor with a recommended next step.

01 What the buyer sees, on their phone, after a viewing

app.viewery.ai/properties/…#feedback

02 What the negotiator gets back a minute later

We built it on Next.js and Convex with Vapi for voice, and we built quickly: 219 commits in February and 239 in March, about a fifth of them opened by an AI coding agent working from GitHub issues. By the end of March there was a dashboard, a properties board with price history and vendor-risk flags, branded PDF reports, calendar sync in both directions, and a demo branch that generated its own data so an agent could try it without talking to us first.

app.viewery.ai/properties

That speed had a price. When I started, the coding models that make a solo, end-to-end build realistic today hadn't been released, so the repository was set up and built properly by two engineers. It cost about £20,000, which was most of the bootstrap budget. It was the right call with the tools available at the time, and it is not a call I would need to make now.

Vendors liked the reports a lot, because for once they were being told the truth. Negotiators were less sure. It made a job they were already doing badly a little easier, but it didn't earn a fee and it didn't bring in new business. Feedback turned out to be something agents would happily take for free rather than something they would pay for.

03The pivot

What the feedback did give us was a buyer profile that got better every time the buyer spoke to the agent. Not "three bedrooms, £600–800k, N1" but a garden being essential, a loft conversion mattering, the kitchen at Church Street being too small. That profile was worth more than the feedback itself, so in April we rebuilt the product around it.

Buyer enrichment went in on 27 April. By 8 May the outbound voice agent could ring a buyer, qualify them and update their profile. The product became four automated sequences: qualification calls for new registrations, feedback calls after viewings, check-in calls between viewings, and a viewing suggestion whenever a new instruction matched a profile. The suggestion went straight into the branch calendar for a negotiator to approve.

app.viewery.ai/properties/19-hemingford-road

By the end of May it was a complete system. The screens are on the front page. Briefly, what it did:

• Matching. When a new instruction came in, the buyers who fitted it were already listed against it, with the features that matched and the ones that didn't.
• Qualification. Preferences from the call, weighted from must-have to dealbreaker, with the line the buyer actually said next to each one.
• Outreach. Every text and call to a buyer, in order, with the transcript, so a manager could see what had been said.
• Pipeline. Each buyer sat in a sequence, so you could see who was due a check-in and who had gone quiet.
• The boring parts. Calendar sync both ways with Google and Microsoft, buyer pages in the agency's branding, the GlueDog CRM integration, and a demo branch that set itself up.
• Listings. Each instruction with its sentiment, price resistance and vendor risk, so a branch manager could see how the whole book was being received on one screen.
• Feedback. The buyer's own words on each feature, the agent's note next to them, and a sentiment reading between the two, all from one call.
• The vendor report. Price perception over time with buyers' quotes on the chart, the highest offer against asking, and a suggested next step, in the agency's branding and ready to share.

The pitch was the one on the front of this site: your buyers are going cold, we bring them back. We priced it at £119 a month per branch plus £5 per booked viewing, with no contract, sitting alongside whatever CRM the branch already used.

The last commit was on 25 May 2026. By then the money for further rebuilds had run out.

04Going to market

We tried to sell from the first week, before there was much to sell. First on designs, then on clickable HTML prototypes, then on a working MVP with no design system. That round taught us something fast: agents expect a mature, finished-looking product, and a rough one costs you the meeting, however good the idea. So we hired a designer, rebuilt the front end properly, and went out again.

Then the Renters' Rights Act took over the industry's attention. Through the spring every agency we spoke to was busy preparing for the biggest change to lettings in a generation, and a pitch about buyer databases was not what a principal wanted to hear about that month.

We used the time to make content: product videos on YouTube, a self-serve demo branch, written walkthroughs, with outreach running alongside. I made about a thousand cold calls myself. They taught me two things. Getting past the office administrator to a decision maker, even just to make the case, is a skill in its own right. And the market is oversold to: a typical branch is being pitched by two or three vendors at a time, most of them selling AI of doubtful value. We could not break through that noise without a concerted effort with proper sales skills behind it, and those are not skills I have.

The industry side was taking shape too. I had built the connections a company like this needs: an integration with GlueDog, which plugs into the agency CRMs, and a contract with Realyse to give buyers market-level data as an incentive to take the call. Both were real and both made the product better once an agency had said yes. Neither did anything to get the yes. They sat downstream of the problem, and the problem was upstream, at the front door of the branch.

Meanwhile the discovery feedback was consistent. Database enrichment and buyer nurturing landed better than viewing feedback, so we pivoted. It took about two months, longer than it should have, because the models we were building on were early and the same bugs had to be fixed over and over, and because by then the money to keep rebuilding had run out. By the time the new product was ready, the competition had already taken the early adopters.

In July the trade press ran the story, in The Negotiator, Property Soup and PropertyWire, with the arithmetic I had used in every call: reactivating 2% of a 5,000-record database gives you 100 active applicants without spending anything on marketing. It brought zero inbound.

05The competition

Nobody beat us in a direct comparison, and for most of the period we were the only ones showing this exact product to agents. Three kinds of competitor arrived from three directions, each with something we couldn't get in time: people on the ground, data, or the agency's trust by default.

Sidekiq

Sidekiq doesn't sell software so much as a service. Their team designs, builds and runs AI agents inside an agency: a receptionist that answers calls around the clock, a reactivator for the dormant CRM, a feedback-and-reviews chaser after viewings, and back-office automation, connected to Reapit, Alto, HubSpot and Salesforce. Their customers' testimonials are rarely about the technology. They are about the team being patient and hands-on, and fitting the system around how the agency already worked.

Our whole roadmap was one of their service lines, and the part they add around it, the implementation and the person on the end of the phone, was the part agencies valued most. We were selling something the branch would have to run itself. They were selling something the branch could hand over.

Homesearch

Homesearch is an established company with data on the whole market and a long list of agency clients. Their ReContact product solves the problem we were pitching, which contacts in your CRM are worth a call today, from a different starting point. Because they can see the whole market, they know when one of an agency's old contacts has become active again without anyone having to ring them. The CRM stays as it is and Homesearch tells you who to call first.

Our version needed a conversation. The buyer had to answer a call from a number they didn't know, talk to an AI, and be honest with it. Homesearch's signal came from data they already held; ours depended on people picking up the phone. And where we had letters of intent, they had case studies with numbers in them, a Winkworth franchise booking dozens of valuations in a month, a Birmingham group tripling its direct enquiries, all backed by an implementation programme with 30- and 90-day reviews.

The CRMs

The third one settled it. Over the spring and summer of 2026 the CRMs themselves shipped what we had been selling as an add-on. Alto, owned by Zoopla, which signed an agreement with OpenAI in April, launched round-the-clock lead qualification that books viewings into Alto diaries. Reapit announced a voice-first copilot with portal pre-qualification and viewing booking. Street.co.uk shipped an AI call handler. Each of them already had the customers, the data, and a product team whose job was to make a bolt-on unnecessary.

A feature inside the system a branch already uses will beat one sitting next to it unless the one next to it is much better, and by the middle of 2026 ours wasn't much better. It had just been earlier.

06Why we couldn't beat them

The honest version is that we identified the problem first and lost on execution, specifically on go-to-market. Six reasons, in the order I'd weight them.

1. Early meant raw. We sold on designs, prototypes and an MVP without a design system, and learned that agents judge the demo as if it were the product. A rough interface cost us meetings we didn't get back, and by the time the rebuilt version was ready the first impression had been made. In a small industry first impressions travel.
2. The trust barrier. Estate agency is a relationship business. Asking a principal to let an AI from a company they'd read about in the trade press ring their buyers is asking for a lot of trust, and asking them to hand over their buyer database to a name they had never heard of is asking for more. Nobody shares their data with a no-name, and becoming a name costs money in advertising that we didn't have. Sidekiq bought that trust with people on the ground. Homesearch had it from years of clients. The CRMs had it by default. I was trying to earn it one discovery call at a time.
3. The CRMs' promises. Agents didn't have to choose us over a shipped feature. They only had to wait for a promised one, and waiting is free. Once Alto and Reapit had announced qualification, booking and voice, our pitch became "why not wait?", and I didn't have a good enough answer.
4. A sales motion I ran alone, without the skills. The letters of intent and the warm pipeline were real. Turning them into paying branches needed the things trained salespeople do: getting past the gatekeeper, relentless follow-up, objection handling, a pilot plan with a date on it, a negotiation about price, and the stamina to keep going through weeks of silence. A thousand cold calls into a market that two or three AI vendors were already pitching taught me how much of that I lacked. I could open conversations; I didn't close enough of them, and I didn't have the budget to hire someone who could. The companies that won had dedicated commercial teams.
5. Money to outlast the cycle. Agency sales run branch to principal to group and take months. Surviving that, and hiring the commercial team it needs, takes investment. The competitors had it. Viewery was bootstrapped; the first build and the rebuild took most of the money, the pivot took the rest, and the runway ran out at about the point the product was ready to be sold properly.
6. Timing we didn't control. The spring we needed agents' attention was the spring the Renters' Rights Act took it. Nobody's fault, but it pushed our selling window back into the months when the competition was arriving.

The focus was right. One week after I approached Street Group to suggest an acqui-hire, their outbound comms were leading with exactly our use case. I don't know whether one caused the other, and it doesn't matter: a CRM group with a sales team behind it had looked at the same problem and decided it was the thing to sell. What they had and we didn't was the commercial backbone, and people with the right background running it.

Underneath all of that is a simpler statement. This was a solo founder with a product background, split across product, engineering, design, sales, marketing and fundraising, and spread that thin it landed too thin everywhere. The product side still worked: the problem was right, the build was fast, and what three people shipped in five months stands up. The commercial side needed someone who had done it before, and I didn't have the budget for that person.

We were first to the use case and last to the sale. The focus was right; a solo founder spread across everything lands too thin.

07What I'd do differently

1. Bring a commercial co-founder, or make sales the first hire.

   In a trust market a product founder can find the problem and build the thing, but someone who has sold to this industry before has to run the pipeline from day one. I would not start another B2B company without that person.

2. Look finished before you look early.

   In this market the demo is judged as if it were the product. Design isn't a later phase; it's the price of the first meeting. Get it right before the first demo, not after the fifth.

3. Earn trust with people before software.

   For the first twenty accounts, run it as a service: set it up, make the first calls, sit in the Monday meeting. Productise what everyone asks for twice. Sidekiq's model is right for this market.

4. Treat the incumbents' roadmap as a competitor.

   "Why not wait for your CRM?" needs an answer on the homepage, with a number in it, before any agent asks. If there isn't one, the window is shorter than it looks.

5. Put the money into selling, not the repository.

   In early 2026 the build took two engineers and most of the bootstrap. With the current generation of models, the same product is a fraction of that for one person, which changes the maths for a solo founder: the build is no longer the expensive part, the six to nine months of selling are. Budget for those before the first line of code.

6. Treat press as a credential, not a channel.

   The July coverage brought zero inbound. In this industry a story in the trade press is something to send after a call, not a source of calls.

08Thanks, and what's next

To the agencies who opened up their CRMs and told us the truth about their databases. To the two engineers who built all of this in five months. To the advisors who kept us honest, and to GlueDog and Realyse, who signed when it would have been easier not to.

What I'm taking from it: the part of building a company I'm good at is finding a real problem, deciding what to build, and shipping a complete product quickly with a very small team. The part I underestimated is the commercial machine it takes to sell into a trust-based industry against incumbents, and I now know exactly what that machine looks like and who needs to be in it. I'm also building differently. With the current models an end-to-end product is realistic for one person, so on my newer projects the engineering budget goes to the market instead of the repository.

Viewery Ltd still exists; the product is switched off. If you're working on the dormant-database problem, email me. And if you're hiring a product lead who has done this end to end and learned the expensive lesson already, I'd like to talk.

Dmitry Meltsov, London, August 2026 · LinkedIn