Search sections, tools, talks, links, and local actions.
Founder, operator, builder
[SURFACE 01]
Residents, context, decisions
Arjun Kannan
I build software for places where customers are already saying what is broken, but the work is not getting to the right person.
Most companies already have the customer telling them what is broken. The problem is that the message dies in an inbox, spreadsheet, ticket queue, or meeting before anyone owns the next step.
ResiDesk is where I am spending most of my time now. Before that it was outcome-based lending at Climb Credit and advisor tools at BlackRock. Different rooms, same basic job: get the facts to the person who has to act.
I care about AI when it shortens that loop: hear the customer, keep the context, help the team move faster, and leave judgment with the person who owns the outcome.
We help property teams answer residents, understand the building context behind each message, and show owners the pattern while there is still time to do something about it.
Looking for
Owners and operators who know the inbox is not just support.
The best conversations start with teams who already care. The hard part is volume: nobody can read every text, review, ticket, and survey by hand and still turn the pattern into work someone owns.
Writing about
What happens after the answer.
AI gets interesting when it changes the next task: who handles it, what context they have, how fast they can move, and whether the customer has to explain the same thing again.
Not useful
Answers with no owner.
If nobody owns the next step and nothing changes afterward, the answer was probably the whole product. That is not enough.
How I think
[MODULE 04]
The notes behind the work
When I am deciding whether a tool is worth building, I come back to the same loop: talk to the customer, make the work visible, take load off the team, and check whether people use it the next morning.
01 / Customer
Talk to the customer.
That is still business 101. In housing, the hard part is hearing enough residents without making one person read everything by hand, then getting the pattern back to the team that can change the building.
02 / Context
Give me the actual job.
I do not learn much from abstractions by themselves. Give me the work, the stakes, the weird edge cases, and the person who has to live with the outcome.
03 / Adoption
Demos are not adoption.
I learned this early at BlackRock. A prototype can win the room and still lose to the spreadsheet the next morning. The test is what people reach for when the meeting is over.
04 / AI
Shorten the distance.
I do not need AI to do the whole job. I need it to move a task from stuck to nearly done while the person still owns the call.
05 / Trust
Keep judgment where trust matters.
Residents trust the product because there is a human team behind it. AI should make that team faster, better informed, and less buried.
06 / Team
Hire people who can find the shape.
The best builders can walk into a messy situation, find the few facts that matter, and move without waiting for a perfect script or perfect spec.
AI deployment
[MODULE 05]
What has to be true before AI is useful
The interesting part of AI is not the model demo. It is whether you can walk into a real organization, find the painful job, and get the work to change without breaking trust or making the team slower.
Operating thesis
AI matters when the customer's day changes.
I am useful where research, product, sales, and the customer's actual work have to meet. That means finding the job, designing the system around it, proving it works, and making adoption visible.
01Find the real job
Talk to the people doing the work. Watch what they do when the system is slow, strange, or politically hard.
02Name what changes
Separate novelty from money, time, risk, retention, capacity, or trust. If nothing changes, the deployment is theater.
03Design the system around it
Pick the model last. First decide the context, tools, permissions, evals, review points, and the handoff into the existing day.
04Test the ugly cases
Run the ugly cases. Show misses. Measure whether the work moved faster, got safer, or reached the right person sooner.
05Turn field learning into product
The best sales material is what survived deployment: the real objection, the before state, the adoption metric, and the story the buyer can repeat.
$40M ARRBlackRock advisor analytics, first year
$300MAnnual loan volume at Climb Credit
100+Startup investments and founder reads
AI field notes
[MODULE 06]
What AI teams still have to solve after the demo
The hard part is not showing capability. It is getting the model into a customer's day in a way they trust, can budget for, and can explain when something goes wrong.
Field note
Find the work, prove the model helps, and make the owner visible.
I have watched a good demo lose to a spreadsheet. I have also seen hidden information become a real product when it reached the person making the decision.
01
Customer-work discovery
Find the narrow place where AI changes the day, not the slide. Talk to the buyer, the user, and the person who will be blamed if it breaks.
02
Deployment practice
Make deployments repeatable: scope the job, staff it, test it, review risk, roll it out, and bring field learning back to product.
03
Sales from what survived
Help sales and marketing say the thing that is actually true: what changed, why the buyer cared, what broke, and what proof survived the rollout.
04
Executive translation without theater
Make the executive version legible without flattening the technical truth. I care about the number, the risk, the owner, and what happens next.
Resident messages
[MODULE 07]
How a resident text turns into building work
[STEP 01 / LISTEN]
Start with what the resident actually said.
A useful system starts with ordinary stuff: the broken washer, the pet-policy question, the Wi-Fi complaint, the package-room mess, the first sign someone may not renew.
I grew up around research, so the obvious path looked academic. I studied applied physics at Cornell because I liked real systems, messy measurement, and problems where small details could change the answer.
Software came in sideways. I was in an electron microscopy lab and wrote code to make a magnetic-noise setup faster. It saved hours almost immediately. That was the moment software stopped feeling separate from the real work.
The industries changed. The job did not. At BlackRock, it meant making institutional tools usable for advisors. At Climb Credit, it meant underwriting against outcomes. At ResiDesk, it means helping housing companies hear residents clearly enough to act.
Physics
Software became the lever.
I wrote a tool in an electron microscopy lab to speed up a magnetic-noise setup. It saved enough time, fast enough, that software started to look like leverage instead of coursework.
BlackRock
Real stakes sharpen the interface.
I came back six months later, re-interviewed, and moved to New York. It taught me that interface quality matters a lot more when real money sits behind the decision.
Climb Credit
Outcomes changed the product.
Instead of asking who looked safest on paper, we asked what happened to earnings after the program. That pushed outcomes into underwriting, product, and data, and annual loan volume went from $1 million to $300 million.
ResiDesk
Housing should know its customer.
Residents tell buildings what is working and what is not every day. The work is making that clear to the owner, useful to the operator, and less annoying for the person living there.
The settings changed, but the job stayed similar: find what the customer is actually saying inside a messy process, then build the shortest responsible way to act on it.
ResiDesk customer result
7%
Reported lift tied to getting resident feedback into decisions earlier. I keep the source context close because this number needs it.
Climb Credit
$1M → $300M
Annual loan volume growth while outcomes became part of the product, data, and underwriting conversation.
Advisor tools
$40M ARR
Advisor-facing analytics product I worked on from zero to $40 million ARR in its first year.
We help rental-property owners and operators understand what residents are asking for across renewals, rent, maintenance, and staffing. The product earns its keep when it changes what happens next: who owns it, what context matters, and whether the work gets done.
We underwrote against a different question: not who looked safest on paper, but what happened to a graduate's earnings. That forced outcomes into the product, data, and underwriting.
The job was turning institutional infrastructure into something advisors could use with clients. Same information underneath, built for the moment when someone had to explain, compare, and decide.
Receipts
[MODULE 10]
Claims with receipts nearby
Product leadership
Worked on products where adoption had numbers.
BlackRock advisor analytics reached $40 million ARR in the first year. At Climb, annual loan volume grew from $1 million to $300 million as outcomes moved into the product and data work.
I write when I have questions. Most pieces come back to the same test: does this help someone finish the real job, or did we just make the demo easier to sell?
If a tool does not help someone finish a real task sooner, with less context loss, it is hard for me to care about it.
Understand the job first.
If you do not know what someone is actually trying to do, you are probably just rearranging the screen.
Build the system around the model.
The model is one part. Context, tools, guardrails, evaluation, and the handoff into someone's day decide whether it changes anything.
Demos lie by omission.
What matters is whether people still reach for it mid-work, mid-mess, with no audience and no demo to grade.
FAQ
[MODULE 14]
Questions people actually ask
What AI systems do I actually build?
I build AI around real work. At ResiDesk, that means helping property teams answer residents, understand what is happening in the building, and get the right issue to the person who can do something about it.
What have I built before ResiDesk?
I worked at Climb Credit and BlackRock. At Climb, I helped annual loan volume grow from $1 million to $300 million. At BlackRock, I worked on a retail analytics product that reached $40 million ARR in its first year.
What do I usually write and speak about?
I usually come back to the same things: agents, evaluation, product loops, and what separates a strong demo from something people still use on a Tuesday afternoon. Housing makes the point concrete because the customer is already talking.
What is my view on AI?
I care less about whether something looks impressive and more about whether it helps someone make a better call. That usually means getting the context right, testing what good looks like, and keeping a human close enough to stop the system from automating the wrong thing.
I have invested in more than 100 startups and mentored through Techstars. I tend to back founders who are close to the problem, close to the customer, and honest about what they do not know yet.
Generic advice is free now. The useful version is specific: here is the customer, here is the constraint, here is the ask, here is the next decision.
Runs in the browserNo server requiredFalls back cleanly
01 / Browser AI visual lab
Local visuals ready
Turn the site into working pictures.
Pick a view. The graphic is deterministic and runs anywhere. If the browser has a local model, it can add a sharper read on the proof, fit, or adoption pattern.
02 / Ask this site
Checking browser AI
Ask a question. Get an answer from this page.
The answer uses the copy, talks, writing, proof sections, and links on this page. If your browser exposes local AI, the tool can try that too. Otherwise it uses a small local retrieval engine.
Try asking about ResiDesk, founder advice, evidence, BlackRock, Climb, writing, or useful AI.
03 / Conversation map
Start with a real question.
04 / Find the relevant bits
Pull the sections that answer your question.
05 / Transcript lens
Pull the useful parts out of a talk.
06 / Useful AI test
Paste an AI idea. See if it earns its keep.
07 / Tuesday test
Stress-test the demo against a real workday.
Pick a demo claim and a customer environment. The simulator shows what has to be true before the thing survives Tuesday afternoon.
Run the test to see demo risks, workday pressure, and the adoption check.
08 / Resident messages
Generate a small building readout.
09 / Pattern highlighter
Show the pattern inside the page.
Highlights the words I keep coming back to: customer, context, measurement, follow-through, trust, and demo.
10 / Design check
Check whether the page is doing its job.
I like making the design explain itself before I call it done. This checks the page on direction, hierarchy, detail, function, and whether it actually helps a reader.
11 / Next pass
Pick the next thing to fix.
Pick the part that feels weakest and get a concrete pass to make next.
