Palpable

https://www.youtube.com/watch?v=7v5-p5hblnM

We have decent flow - but only 0.5% conversion

After 1 week, we have a sense of our flow. We can normalize it to infer we get 1 paying customer for every 203 website visitors.

Some of this is probably the $100/mo price we had for the first 5 days.

But none of our numbers are that bad on their own.

How do we get more website flow - Not Ads!

We have already taken steps to improve conversion from download to subscription. Namely, we offered a lower price tier with longer trial period.

But really, we need some flow to our site.

I decided to check out Google Ads. Based on our industry and location, we can expect to pay up to $5.26 per click.

Plugging it in, each paying customer is going to cost us about $1,000.

That means, to break even with our $25l/mo subscription, we need the average customer to stay on the platform for 48 months.

Seems like a bit of a stretch.

What should we do? Chip away at the metrics...

These stats don't suggest a silver bullet. We'll need to get flow through free sources (socials, content). We'll need to find better conversions at each step. Maybe we fin d a way to optimize CPC.

Better insights next week.

On Day 4 of launch for Palpable AI we hit unit profitability.

We were worried because we use three AI services for: 1) our core agent; 2) graph storage; 3) TTS.

If you look below, you see we have ~60% unit profit margins.

This is only because of Anthropic's release of Haiku 4.5 last week.

It is 1/5 the cost for the same F1 score (eval performance) and 1/3 latency.

I admit I started the day feeling glum.

There are so many jobs that need doing to build real traction. More marketing, more service levels, more features. Or, maybe none of those. Maybe I need a better value proposition, or better copy... see, easy to get focused on the enormity of it all.

But on a whim, I decided to check the stats expecting to see some sign-ups and free-trial use. Instead I saw...

Revenue!

Suddenly everything felt a bit lighter.

Same amount of work to do, but now it all seems possible.

Milestones like these matter!

Whether it's VCs, or co-founders, or employees, they implicitly see each milestone as a major reduction in risk:

1. Tech risk (product works)
2. Launch risk (product gets in front of paying customer)
3. Commercialization risk (founder can get revenue for product)

Yes, yes. Many more steps to de-risk. But we're getting there.

Most of us completely misunderstood "The Lean Startup". We all thought of it in terms of coming up with and validating ideas. Partly because that's as far as most of us ever got (me included).

In fact, Lean Startup is almost entirely about monitoring your flow metrics.

The thrust is: if you can see the mechanical flow of users going from impression to download to purchase... you can figure out the exact next action to improve outcomes.

The above dash gives the idea. You can't see it but we have 5 purchases. 3 are people I know, so call it 2 sales from pipeline. That means our sales conversion rate from download is 10%.

That's high, on one hand, because the price is $100/mo but it is exaggerated because there is a 3-day trial. We'll likely see a drop.

Armed with this, what step in the pipeline can we get the best ROI on?

The big drop off is from download to purchase. So it's time to reduce price.

I can do so in two ways for now:

1. Tailor price by region - right now everything is based off of USD, and the dollar is too strong for most other countries

2. Add a more limited version

I'll do both of these by Monday

When a launch flops - blame the marketing person?

Yesterday we launched Palpable AI with some generous encouragement... and not much else. As in, very few customers.

Partly this was a marketing glitch. My idiot marketing guy forgot about a web-component that read as "Coming Soon" on most peoples' phone.

I would FIRE that marketing guy except that he's me. And I'm the only one here. So I'm stuck with him for now.

But even without that, we have another big problem with launch: a very high price.

Price plays a role in launch response too!

One other contributor to our tepid day-1 customer count is our high price. Palpable costs $100/mo. Our rationale on price was: "yes, we're 5x more expensive than any iOS app... but we're 1/100th the price of a human personal assistant." We're banking on customers noticing the latter, more than the former.

Realistically, though, customers probably won't care about our clever pricing logic. Does that wreck our justification?

The genius of the "price higher" wisdom from Indie Hackers

If you listen to a lot of IH podcasts (which you should), you'll be familiar with the idea that technical founders "always price too low." Courtland and Channing give some compelling logic for this:

1. technical builders undervalue the tech because it's easy for them;

1. many tech founders follow an open-source ethos;

2. the big one: founders always have a moment where they realize they should raise prices.

When I'd hear this I would always promise to be different: "I will launch with a higher price, even if it feels uncomfortable."

So here I am.

What's missing from the "price higher' story

I'll admit to noticing an unstated pattern in all these "price higher" discussions.

Each "price higher" story stars a successful founder, not a failed founder. In the story of their success they started with a low price.

Yes, yes, they might come to regret that choice in some vague "I could have gotten more" sense. But how would they really know? The real subtext of all these stories is that, as an early founder, you're figuring things out as they come.

That is all to say that, maybe the low price at the start was a feature, not a bug.

A sidenote: I think on similar lines whenever I see an article like: "The 3 Most Common Regrets On Your Deathbed." In one sense, it is interesting people have common regrets when looking back. In another sense, that doesn't mean those people are fully 'correct.' You have very different circumstances and incentives when you're awaiting death. That might not be as applicable as we think. Put another way, it's a classic case of hindsight bias.

The decision to go "freemium" - matching your growth engine

I always find it hard, as a founder, to separate the universal startup advice (go talk to customers) from everything else (ads or word-of-mouth).

A freemium offering is squarely in the "it depends" category.

For example, if you have network effects, you have to have a freemium option. Heck, you have to have a free option. Acquisition is all that matters at first.

In contrast, if you're a quantum deeptech like my previous employer (SQC), freemium is horrible. Each sale is so expensive. Plus, you're only doing sales to prove to investors you can be commercial. Until you are unit profitable, there is no point trying to grow customers that much.

AI Tokens are Expensive - Losing to Competition is More So

The main aversion I have to freemium is the price of AI tokens. Right now, typical token usage for a user on Palpable is $50/mo. It can easily go higher. As a bootstrapped founder, that's a startling number. Our $100/mo has to cover both the $50/mo and the free-trials who drop out. Going freemium would only exaggerate the issue.

What's more, Palpable's base case does not scream "freemium" — we have a premium product without network effects. We need to spread either by word-of-mouth or paid acquisition. In normal times we might cater to rich, early-adopters who tout the product and seed a following. Our growth could lag some quick-and-dirty flameouts but we would win on trust and brand over time.

The problem: we're not in normal times, we're in a Wild West cat tornado led by Sam Altman and Elon Musk.

No one in AI right now, can claim to have a moat. There is nothing stopping Anthropic and OpenAi from doing what you do better and cheaper. The only reason they are not doing what you're doing is because they haven't gotten around to it yet.

The only way to survive them is to get far enough ahead, create a brand in your niche, and then wait it out while they fight one another (or acquire you). At some point, as a side-effect to this competition, they will cut prices on models that do enough of a good job, that our startups can all hit profit.

Until then, survival means growth and growth means freemium.

So how do we survive?

Kiss your IH Channing Interview Goodbye - Freemium Requires VC

Most of you will see where this goes. When you couple the expense of tokens with the need for freemium, the math just doesn't work for bootstrapping. Slow, organic growth is off thet able. Fast burn is the game. Unless you have a couple exits lying around, that means you need funding... fast.

Whereupon the only group who understands your risk/reward profile and, by implication, can value you appropriately, is a VC. It's not a philosophical position. It's just the math of cause-and-effect.

And so, that's where we seem to be headed: avoiding competition => brand position => big following fast => freemium => high token-cost => VC

Palpable's low-key goals for the week

1. Grab Haiku 4.5, which Anthropic promises is both cheaper and faster, for the same performance

2. Release a freemium version of Palpable

3. Go on IH and YC Founder Match... because speed is now the game

4. Check-in on Friday

It's hard to believe but today we open Palpable AI to early access (https://palpable.io)

A low-key big deal - The AI for one's daily life

Palpable is a voice-driven "Pal" that can...

• sort your emails

• manage your calendar

• order dinner

• post to your socials

It has a persistent memory and already supports many popular "skills" including Outlook, Gmail, Notion, and Fetch (for browsing)

While a lot of AI still focuses on builders, Palpable wants to remove admin from your daily life. In our own usage we saved hundreds of hours in just a few months.

Who needs vibe coding when you can do vibe admin instead?!

Sounds great, how did we get here - 4th time's the charm

The journey started a year ago, when I quit my job at a top quantum computing company to focus on my own AI projects.

We had three duds over the last year:

• Enthoosa - A B2B process-mining AI: required too much education

• BoardInsight - An AI for managing Board Papers: got some traction, but was mainly a way to learn RAG

• JustPost.io - A simple, cross-social posting tool: an excuse to learn reactive UI

Each of these projects taught me a lot about the AI tooling space and the market. It's possible these just needed more time, marketing, and iteration but the reality was, they never felt all that inspired.

Discovering MCP: The oddly powerful little protocol

In early March, I decided to build a simple MCP Server for Outlook. I could tell Anthropic was excited by their new protocol but no one seemed able to articulate why. I figured a hands-on exploration would help me understand.

Then, in just 2 weeks, I had an email assistant that was already working better than the human version. That put it 10x beyond all the digital assistants I've tried over the last decade (and 100x beyond duds like Siri and Alexa).

This wasn't due to any clever programming on my part. The power is an unexpected and emergent property of MCP.

To that point, most agentic systems (think n8n) asked humans to build the workflow while the AI was meant to handle key decisions. The approach was looking a lot like RPA. Each capability required its own flow and the only way to extend capability was to pile flows on top of each other. The whole thing was fragile and a nightmare to maintain.

MCP flipped the approach. The LLM would orchestrate the workflow using tools. Workflows could break free of the rails. An infinite number of paths were now possible, perfectly orchestrated for the task at hand.

If workflow flexibility was all MCP did, it would still have been a big deal!

But MCP had another trick waiting.

LLMs like their context... "in context" - how MCP is killing agentic workflows

A funny thing happened when you gave routing over to the LLM: accuracy went up 50%!

In the old n8n, workflow approach, the LLM only had the context explicitly provided by the workflow. The LLM couldn't see the broader query thread. It couldn't tell that its last tool call caused an error. It didn't know about the web search the user just made it run.

In other words, the LLM had none of the context a real human assistant needs to know what's going on. No wonder they produced such lousy results.

It was this observation that made early MCP converts so evangelistic. It's also why so many agent-builders backlashed against the hype.

The MCPers were seeing magic. The LLM could finally take actions at better-than-human accuracy, with very little effort for the developer.

Any workflow builder, to that point, was right to be skeptical. This new behavior was just to subtle to be understood from a protocol doc, alone.

At first, we didn't know what to do with this powerful little agent. The MCP server required Claude Desktop and it was immediately clear MCP Servers would become a commodity.

For this reason, I actually moved to other projects. I still used my Pal on a daily basis. It was just so magical. It created file folders, managed my calendar, and even booked the occasional dinner reservation.

I just couldn't figure out a way to differentiate it from any other Claude + MCP combo.

Bitter-sweet inspiration - blindness and productivity

That's when I saw a "Request for Startup" from Tyler Bosmeny of YC. He wanted an AI agent that worked with "Just. My. Voice." Instantly, I knew that was it.

You see, by unfortunate coincidence, my mom had just been diagnosed with macular degeneration: an eye disease that causes progressive blindness in old age. It's a genetic disorder that afflicts most of my family and promises to get me when I'm older. Knowing my mom would soon start that same path of decline we saw with other relatives, got me thinking about alternative computer interfaces.

Because she is such an avid casual gamer, I had been fixating on pointer inputs. It was only after Tyler's video that I connected the dots.

Screens and keyboards are a workaround for bad UX?

At first it seems unlikely that voice-AI could be a big deal. We all experienced the hype and backlash when Siri and Alexa first arrived. Surely, we learned, you need a screen to get any real work done.

Not so fast. Screens and keyboards solve a very particular problem. They let the user carefully confirm the data being entered into and sent back by a computer. Why do we have to be so careful? Because, until last year, computers required very precise inputs to do anything. Change one letter in a url and you're on a site you can't show to your mom.

GenAI changed this equation. We see it in funny videos of vibe coders yelling commands at their agents. When the inputs can be fuzzy, voice reclaims it rightful position in the input/output hierarchy.

Move over vibe coding, introducing "vibe life."

Palpable AI was born - Time to Apply to YC (punchline: we got rejected)

As soon as I heard Tyler's video, I knew I had to try and submit it to YC. We only had 2 weeks to the deadline and my server was still, well, a server. I needed an app, and a voice.

At this point you just imagine a montage consisting of red bull, ChatGPT queries, and bad SwiftUI coding. I spent a full 3 days just trying to get my iPhone to stop hearing itself when it was talking.

In the end, we made the deadline with a full, working demo. Time to claim our place among the YC hopefuls! Except not.

It was around this time I noticed that Tyler's RFS was actually for the prior batch. YC had already accepted a delightful little email assistant named April who was just about to start taking pre-orders. In truth, we also made some rookie errors on our application that probably would have worked against us. Too much back-story, a hint of MBA-speak. Old habits die hard.

In the end, we didn't even get a phone interview. No big deal. It was a great forcing function for getting our demo done. Now we needed to get into the hands of some customers.

To validate Palpable, I became a personal assistant - doing things that don't scale

While I loved my little AI Pal I was not yet convinced anyone would care. I knew it would take a few months to get it truly multi-user. I didn't want to waste time if users just expected another Alexa. I needed to validate!

So, I became a Personal Assistant! More correctly, I offered people 24/7 phone access to me, with the promise that I would discreetly help them manage their email and calendar. For two weeks people paid $50 an hour to wake me from 3 different timezones, just so I could clear out their inbox or set up a meeting.

In the end, clients loved it. They loved the 24/7 access and they especially loved such service at 1/100th the cost of a human PA.

In fact, it was the intensity of their response that made me know I had something... because, in truth, I was giving them some of the worst personal assistance ever!

Humans are good at what they do - that's a problem for AI

Never doubt the skill of a good PA. It was one of the hardest jobs I've ever taken on.

That's because it is all one big information asymmetry. Your client knows everything about herself. They know who all the players are. They know the purpose of that meeting invite. The know the right level of formality to use with each colleague. As a new PA, in contrast, you know nothing. Almost by-definition, everything you do in those early days is completely wrong.

The most salient example of this came when I replaced a work meeting with a meeting for a contact listed as "Mom". It turned out that "Mom" was actually the client's personal trainer who had recently taken to nagging them to go to the gym. Thus the sarcastic contact name: "Whatever, MOM!" By booking "Mom" I had inadvertently signed my client up for an unwanted gym session. Whoops!

Like I said, being a good PA is hard... and yet, not beyond the powers of the right AI.

Not All Jobs Work With AI (ahem, coding)

Most of the clients I advise on AI are struggling with their projects. The main reason? They chose the wrong task for AI.

The most controversial example is coding. We all got distracted by the fact that an AI can write a giant block of code and get it 95% correct. Your average developer can't do that. So maybe we can get rid of the developers, right? Right???

The problem is, that 5% the AI got wrong, will elude the AI forever. The more you ask the AI to fix it, the worse things get. It's either missing some context, it has the wrong mental model, or it just can't reason with enough cause-and-effect. It needs a human to rescue it.

In contrast, those same developers who struggle to hit 95% accuracy, they can find the fix—every time. It might take them more time to figure it out than if they had written the code themselves (thus harming the ROI of the AI project), but every developer will get the answer eventually. This truth may fade over time but it's the current state of AI coding.

AIs thrive with jobs that require flexibility and a good memory

AI coding fails because it still requires a high degree of precision. If the AI doesn't understand the variables being passed around, it won't figure out a fix.

In fact, it is precisely because a PA job requires ambiguity that it works so well with AI. For example: if I tell my Pal to create some email folders, there is no precisely right answer. Some answers are slightly better than others. For example, "Newsletters" makes a better name than "Newsletters from Spotify". But even in the latter case, everything can keep on working. I could tell the AI change the name and, more broadly, not to be so specific. Done!

This works particular well with MCP. As you'll remember, MCP allows for an infinite number of workflows. That's just another way of saying it can work with infinite ambiguity. The user can control the degree to which the MCP takes advantage of that ambiguity (you don't want it to have delete access for important tax documents, for example). But in general, an AI PA doesn't need to be perfect. It doesn't even really need to be better than a top-shelf PA. It just needs to be better than you!

Announcing Palpable AI - An AI Pal that is better than humans

In retrospect, it was total luck that we used MCP to build a mail assistant. It is the use-case that best showcases the power of this new technology. At the end of the day it's primarily a task about routing. Routing emails, routing calls, routing a person to meetings.

Add in some persistent memory and you have a world-class PA, for 1/100th the cost.

Tiny examples include:

1. Calendar management - the AI can follow meeting preferences that no human could ever manage ("30-minute meetings, except on Tuesday, unless it's a full moon...")

2. Email filing - an AI can read 10 emails in seconds and have them filed in minutes... it's slower than other computer tasks but 10x faster than a human

3. Attention to detail - the AI doesn't get tired or bored. After 100 emails it still noticed the todo items hiding at the bottom of one particular request.

Does the AI do everything perfectly? Not even close! In one early test I had to cringe when the AI sent a chummy sounding email to a company lawyer. Luckily, no harm done and we eventually found ways to avoid such mishaps.

It turns out, though, perfection isn't the bar. A human PA doesn't hit perfection. They just need to be better than their client. And as I found out during my validation experiences, I'm a fairly rubbish client!

Thank you for your support - please try Palpable

I've taken a lot from this community, lurking over the last few years. I appreciate all your stories and insights. Please give Palpable a try and let me know what you think.

Lots more work to be done!

(App Store Link) - Free 3-day Trial

Just got security approval from Google's chosen CASA firm.

I was going for a Tier 2 approval which allows my app to use sensitive Gmail scopes (like delete mail).

The security assessment took ~2 weeks comprising:
1. Code scanning - I'd upload code, they'd flag issues, I'd fix it and retry
2. Security practices questionnaire - they asked questions and then would ask for evidence when my answers needed more proof
3. Pen testing my app - I momentarily freaked out when I saw someone actively trying to hack me in the server logs... then remembered I had paid for this
4. Write up the approval letter

I still have to wait up to 5 days for Google to approve after they receive the letter.

I'm enjoying this "can't launch" downtime because it gives me an excuse to work on some "dev lifestyle" aspects of my app.

I was supposed to launch last Friday but am waiting on Google app approval (I use sensitive gmail scopes).

The delay gave me the excuse to add some 'no regret' launch features.

For example, anyone using an MCP Client should consider adding Fetch (an all-purpose web surfer tool).

It gives broad assistant capabilities like ability to check weather and driving directions.

Three months ago we did a POC of an AI assistant that was better than any assistant I've worked with... human or otherwise.

I knew it had promise when I hit inbox zero for the first time in a decade. I knew it could be magic when it did that, better than I could. It created folders, sorted by categories I was too lazy to separate. All in minutes, not hours.

Problem was: it was still just a dumb MCP server connected to a local version of Claude.

Then we had the idea: make it more like a phone call with your own PA.

In a week, we had a prototype that proved the idea.

Could we launch? Did we have an MVP? No. We had a demo. A single-user, local-only, totally manual demo.

So we started building. I hoped to be done in a month. It took 2. But we're finally ready.

Tomorrow we launch https://palpable.io