Skip to content
About

A small product with strong opinions about what it will not do.

Lewis works the dormant leads in a real-estate agent’s CRM over text. That is the whole product. Most of the engineering in it is about the things it refuses.

The problem

Every agent has a database. Almost none of them has been worked. Four hundred names, a notes column full of the specific reasons each of those people was once a lead, and no evening free to text four hundred people one at a time.

The value in that list is real and it decays. Somebody who paused in 2024 is going to start again, and whoever texts them in the right eight weeks gets the transaction. Nobody can know which eight weeks, so the only strategy is to still be there, which is exactly the thing a person with a live pipeline cannot do and software can.

The thing we got wrong first, and what it taught us

The first version was more capable and much worse. It would answer a question about a property, because it could produce a fluent sentence about one. It would read a “yes” as approval for whichever draft seemed likeliest. It would tell you a message had been sent when the phrase you used to approve it was one the code could not read, which, on an agent’s screen, is indistinguishable from a real send.

That last one is the whole education. The dangerous failures in this product are not the ones that look like failures. They are the ones that look like success.

So the rules moved out of the prompt and into code, and they moved from the model’s input to its output, because an instruction is checked by nothing and an output check runs on the turn nobody is watching. And the ones that matter most became refusals rather than warnings, because a warning in a queue is a thing people get through.

What Lewis is not

  • Not a CRM. It has no stages, no assignment, no pipeline reporting.
  • Not lead generation. It works a list you already own.
  • Not an MLS. It cannot know a square footage, a price or an availability, and it is built so that having the data would not change the rule.
  • Not autonomous by default. Every draft waits for a human, and the permission to stop waiting is granted in words and revoked the same way.

Where it is

Boston. The listings side of the product knows Boston neighbourhoods and Boston landmarks specifically, from a closed list rather than a geocoder: a geocoder always returns something, and what it returns for an ambiguous name is a confident answer about the wrong building.

How to judge it

Ask it to show you a message it refused to send, and the rule that refused it. That question separates products in this category better than any feature list does.

What we optimise for

Three things, in this order.

First

Do not embarrass the agent

Nothing goes out under a licence unread, and the categories that could cost somebody their licence are refused rather than queued.

Second

Say only what is true

No property facts, no derived travel times, no inferred budgets. Where Lewis cannot know something, the sentence says so.

Third

Then be useful

Within those two, work the list harder and more consistently than any person with a live pipeline realistically will.

Read next

Your book is already full of people who meant it.

Point Lewis at the export and he works it over text, every draft still waiting on your yes.