Search sections, tools, talks, links, and local actions.
Builder, operator, advisor
[SURFACE 01]
Customer truth, AI systems, measurable work
Arjun Kannan
I build AI products and operating systems that turn customer truth into decisions people can defend.
The thread through my work is simple: people keep telling companies what is broken, but the signal usually dies before it becomes a decision. I build the missing system between the conversation and the work.
ResiDesk is the current version. Before that it was outcome-based lending at Climb Credit and advisor tools at BlackRock. Different rooms, same basic job: make the facts useful to the person who has to act.
I care about AI when it makes that loop faster and more honest: hear the customer, preserve the context, give the team leverage, and still leave judgment with the person who owns the outcome.
Start with the operating map and the deployment room. The useful pattern is how I find the customer truth, turn it into a system, and keep score after launch.
Advisor or partner
Start with the advisory fit. I am most useful when the problem is real, the team is close to a customer, and the next decision needs sharper context.
Evidence reader
Start with the proof brief and evidence ledger. They put the claims, outcomes, press, talks, and source links in one place.
AI team
Start with AI lab fit. The point is not a louder demo, it is a repeatable way to turn frontier capability into customer work.
I build systems that turn customer truth into work.
That has shown up in housing, lending, and wealth tools: take the messy thing people are already saying, keep the context intact, and make it useful to the person with the next decision.
02 / Builder proof
Outcomes, not just opinions.
Climb grew from $1 million to $300 million in annual loan volume. A BlackRock advisor product reached $40 million ARR in its first year. ResiDesk applies the same loop to resident operations.
03 / Public proof
The work has outside receipts.
TechCrunch, Law360, HackerNoon, TechTimes, BuiltWorlds, and 20for20 cover the same pattern from different angles: useful AI is a system design and adoption problem.
Advisor fit
[MODULE 04]
Where I am useful to founders
Useful when
The customer truth is there, but the company is not organized around it yet.
I am helpful when a founder has signal from customers, sales, support, pilots, or field work and needs to turn it into sharper product, narrative, deployment, or hiring decisions.
01
Find the real wedge
Separate the painful job from the impressive demo, then make the first repeatable motion smaller and clearer.
02
Make GTM less vague
Turn messy customer language into a story buyers can repeat internally without flattening the technical truth.
03
Stress-test adoption
Ask what has to be true on a normal Tuesday, when nobody is watching and the team just needs the work done.
04
Keep the score honest
Name the outcome, the owner, and the evidence before the team mistakes motion for progress.
Now
[MODULE 05]
What I am building right now
[UPDATED 2026-05-07]
ResiDesk is the current proof of the thesis.
Most of my attention is on ResiDesk. We help property teams answer residents, understand the building context behind each message, and show owners the pattern while there is still time to act.
Looking for
Owners and operators who already know the inbox is signal.
The best conversations start with teams who already care. The hard part is volume: no one can read every text, review, ticket, and survey by hand and still turn the pattern into owned work.
Writing about
The question after the answer.
AI gets interesting when it changes the next task: who handles it, what they know, how fast they can move, and whether the customer has to explain the same problem again.
Not useful
AI that stops at the answer.
If nobody owns the next step, nobody trusts the answer, and nothing changes afterward, the demo was probably the whole product.
How I think
[MODULE 06]
The operating map
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 do not mistake a clean demo for something people use 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
Show me the actual job.
I do not learn much from abstractions by themselves. Give me the work, the stakes, the strange 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
Move the task forward.
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 carry context.
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 07]
How I make AI survive deployment
The interesting part of AI is not the model demo. It is whether you can walk into a real organization, find the painful workflow, build the right harness, and get the work to change without breaking trust or making a team slower.
Operating thesis
Frontier AI matters when the customer's workflow changes.
I am useful where research, product, sales, and the customer's actual work all have to meet. That means finding the job, designing the system, proving it works, and making adoption visible.
01Find the real workflow
Talk to the people doing the work. Watch what they do when the system is slow, strange, or politically hard.
02Name the value path
Separate novelty from money, time, risk, retention, capacity, or trust. If nothing changes, the deployment is theater.
03Design the harness
Pick the model last. First decide the context, tools, permissions, evals, review points, and the handoff into the existing day.
04Ship with proof
Run the ugly cases. Show misses. Measure whether the work moved faster, got safer, or reached the right person sooner.
05Turn field learning into GTM
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 ARRAdvisor product, first year
$300MAnnual loan volume at Climb
100+Startup investments and operator reads
AI lab fit
[MODULE 08]
Where I can help a frontier AI team
If a lab is serious about enterprise adoption, the hard part is not just showing capability. It is translating capability into workflows customers trust, budgets they can defend, and systems that feed the roadmap.
The job I would want
Lead the bridge from frontier capability to customer value.
I am not trying to be a generic AI evangelist. I am useful when the room needs technical taste, customer truth, commercial judgment, and enough operating scar tissue to know when a deployment is not ready yet.
01
Enterprise workflow discovery
Find the narrow place where AI changes the work, not the slide. Talk to the buyer, the user, and the person who will be blamed if it breaks.
02
FDE operating system
Turn deployments into a repeatable practice: scoping, staffing, evals, security review, rollout, proof, and field learning back to product.
03
GTM from field truth
Help sales and marketing say the thing that is actually true: the workflow before, the system after, the buyer's reason to care, and the proof.
04
Executive translation
Make the C-suite version legible without flattening the technical truth. I care about the number, the risk, the owner, and the follow-through.
Resident messages
[MODULE 09]
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 default 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 job has mostly been the same in different settings: find what the customer is actually saying inside a messy process, then build the shortest responsible path to a real decision.
Resident experience
7%
Reported renewal and rent lift when resident feedback got into decisions earlier.
Climb Credit
$1M → $300M
Annual loan volume growth after treating student outcomes as product data, not marketing copy.
Advisor tools
$40M ARR
Advisor-facing analytics product taken 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.
Evidence ledger
[MODULE 12]
Claims with receipts nearby
Product leadership
Built products with measurable adoption.
BlackRock advisor tools reached $40 million ARR in the first year. Climb Credit grew annual loan volume from $1 million to $300 million after using outcomes as product data.
I write when the consensus feels too smooth. Most pieces come back to the same question: 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, I have a hard time caring 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 harness, not just the model.
The model is one part. Context, tools, guardrails, evaluation, and the handoff into someone's day decide whether it matters.
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 16]
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 move it.
What have I built before ResiDesk?
I worked at Climb Credit and BlackRock. At Climb, I helped grow annual loan volume from $1 million to $300 million. At BlackRock, I built 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 / Reading guide
Build a path through the site.
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.
