I started the Unfair Advantage series to sit down with solo founders and hear how they built and sold something people actually wanted. And the question I kept coming back to was how they got to their first hundred.

First hundred sales, customers, boxes, whatever their hundred happens to look like. So it seemed only fair to name the series after it.

My hope is that somewhere in these stories you find something you can use. A strategy, a tactic, something. So, if you are an early-stage founder, help me sharpen what I ask. When you get to the end of this, if there is something you still want to know from the founder I interviewed, drop it in the comments.

Let’s goo!

For ten years, Nomiki Petrolla, was the go to person for startups when they wanted to turn their idea into a real product. And in all that time, she never once worked for a woman.

She ran a fractional product practice out of Columbus, Ohio, sitting between the founder and the engineers and making sure that the thing actually shipped. She helped these startups make millions of dollars, close hundreds of raises, get exits, and get acquisitions.

The closest thing she saw a woman in charge was a cofounder married to the male founder.

“She was brilliant! And she still wasn’t the one leading.”

Nomiki has four kids, three of them daughters. And she wasn’t going to spend another decade helping men build products while the women stayed out of the picture.

So she built Theanna to fix that. Theanna is a platform built to help non-technical women founders go from an idea to a million dollars in revenue.

As of today, Theanna has 300+ female founders on the platform, building something they are proud of.

Selling The Idea

When word travelled that Nomiki had stopped taking client work, women founders FLOODED her linkedin DMs wanting to hire her.

But she didn’t want that.

“I’m expensive. You shouldn’t be hiring me to do the work for you, because at that stage you actually need to know how to do it. And if you hire me to do that for you, you’re actually going to put yourself in a compromising position as the company grows.”

She decided to teach them instead.

PDS Lab, launched in August 2023, was a six-month accelerator that charged $6,500. 43 women went through this program where Nomiki taught the 6-step framework that she had created from her experience of building products.

And it worked wonders!

One founder built and launched her MVP on no-code tools, won $10,000 at a pitch competition, and hired her first employee. Another, landed corporate partnership with a firm that had 400 stores. Someone else built a cybersecurity platform while holding down a full-time job.

Nomiki didn’t have to teach the framework. She could have just built the platform first and sold access to it.

But she chose to test the theory with the least complicated version of the product that still delivered the expected outcome.

Most founders building a tech product assume that the MVP has to be a technical platform. Something people can “play around” with. But that’s not always true.

The question you need to ask is what’s the fastest way to get somebody to pay you for the outcome you are promising. A platform is one way you deliver that outcome. But there are other ways. You could have a service, a cohort, a training, a newsletter, or something else entirely.

Teaching forced her into a mandatory conversation with her buyer. She saw exactly which step confused people, which questions came up, and where somebody was about to give up.

We think that the goal is downloads. But that means nothing. A thousand people can download something. Whether they will use it depends on how much you already know about their process.

Selling a service or a consultation is a very cheap way to find that out. Because by the time you build a product, you already know where the churn lives, and what you need to do to avoid it.

Soon, PDS Labs stopped working though. In a good way.

“It was exhausting, because I was coaching all the time. There’s a cognitive load that comes with one on one that software doesn’t have.”

And it was time for the next phase.

She only had 43 customers and barely any distribution.

“I believed that women do best building companies together. That was the core thesis. And I had to prove that I could build a community before I built the software.”

But she knew who she was targeting: women, non-technical, building tech products they want to sell.

Building A Waitlist

The best way, at least today, to build a waitlist for a consumer tech product is content. But our attention is divided. People literally scroll a video in less than 3 seconds.

So how do you go about it?

Nomiki’s answer was volume. Volume and consistency.

She started posting about her journey of building Theanna. What she was shipping, who she was working with, the mistakes, and the lessons.

The thing about founders posting content is that “the founder content” sells. Everyone wants a day in your life. They want to know what you have learned. They want to know how you’re doing it.

But for most founders, that’s not the right content to start with.

For Nomiki, however, it was PERFECT. Her buyers were women founders interested in learning how Nomiki was building her business. So every time she posted, she was talking to her buyer.

“If you’re a woman building software…”, “If you’re a woman with a tech idea…”, “If you have an idea and you don’t know how to get started…”

So her content strategy didn’t work only because of volume. It worked because:

1. She was customer 0 who was just a little ahead of others

2. She knew who she was talking to

3. Every single video was directed at her buyer

By launch day, she had roughly 950 women waiting to subscribe to Theanna.

On launch day, 500 of them created a profile. This happened only because the waitlist was made of her exact buyers. And 60 days later, 100 of them were paying customers.

So if content is how you plan to build distribution, remember:

A hundred interested buyers are worth more than a thousand followers who are never going to buy anything.

Patchwork Products

I have been following Nomiki since she started posting videos. So I went into this interview, very much a fan girl, already knowing most of her story. The one thing I have learned from her is that she validates fast and ships before she’s ready.

PDS Labs existed to test whether her idea has any legs.

The first version of her product was her framework taught to an LLM. A very informed wrapper. But a wrapper that was running on her knowledge and tools and prompts.

And it worked in orders of magnitude beyond any of the polished products I have seen.

And now Theanna 2.0 is the product she wanted to build all along.

But had she started with this fancy version, she would have maybe built the wrong thing or would take longer to get to $230k+ in ARR.

So if I had to boil this whole thing down to one nugget, it would be this.

Start with the most patchworked version of your solution that you can stand and get it in front of your users. Don’t spend months or even days making it look polished. And don’t try to build the thing that exists in your head.

“The mental hurdle people need to get over is from ‘I have this idea’ to ‘I believe I can do it’ and actually doing the thing they say they could do. Most people do not cross that hump. They stay in this, ‘Oh, what if, let me tinker a bit..” phase and then they stop because they couldn’t find the users.”

If you’re a non-technical woman building in tech, I genuinely recommend Theanna.

And if you like founder content, follow Nomiki on Instagram. She shares candid details about everything she’s building and everything she’s learning.

If you have a question for Nomiki that I didn’t ask or answer here, drop it in the comments. If I don’t know the answer, I’ll go and ask her and come back to you.

P.S. Next Tuesday I am sharing the playbook and strategies used by 11 consumer tech startups to get their first 100 customers. Some come directly from founders and some from my research. So make sure you are on the list!

Subscribe now

Join Table for One | Other Articles

I grew up watching Rosey from The Jetson’s cook, clean, fold the laundry, and have a whole personality while she was at it. (I don’t know how niche that reference is but she was a robot maid on a cartoon).

But what I actually got is a chat window that can write a 900-word essay on how to correctly fold a fitted sheet and then wait for me to go do it myself. So while I wait for AI to give me the actual help I need… I will have to make do with what it can do right now.

I use claude skills to run almost everything in my life. They analyze my Substack. Run my job search. Read my inbox every morning. Plan my meals. Watch specific industries for news.

You get the picture.

A few of them run continuously on their own, a few act when a file changes, and a few of them sit there waiting for me to call on them.

Building a skill is easy but building a good skill is nowhere close to it.

The first few that I built could not give me repeatable results. But the recent ones not only give perfect results but they learn with every run and even work with other skills.

P.S. I am calling skills working with other skills as Tasks and this is my petition to Anthropic or Open AI to use let me coin this term!

Building Better AI Helpers

So what is a skill? By definition, a skill is a folder with a plain text file in it, and that file tells Claude/ChatGPT how to do one specific job the same way every single time. You write the instructions in ordinary English and save it in a SKILL.md file. Your AI reads it and any other documents you reference to execute tasks on your behalf.

I am a religious Claude user but whatever I explain below works with ChatGPT too.

Subscribe now

Do Before You Build

This part isn’t just mine. It comes directly from Anthropic’s guide to building skills for Claude.

Complete at least one run of the task in a simple chat.

Work through the problem with your AI using simple prompts and as you go, you will notice that you naturally hand over context, explain your preferences, and describe the workflow. You have to keep track of what information you repeatedly provide to the chat. That should become your context files.

What works best for me is to do the task 2 to 3 times and keep a note of every single thing I had to correct. Let me walk you through how I built the meal planner skill.

Before I even thought of a skill, I started a chat and told it this:

Then I ran this process on the same chat for 2 runs. Two runs of feedback, corrections, and approvals later, I had a decent understanding of what I needed to make this into a skill.

Design The System

Designing the skill is more than telling Claude what you want it to do. Designing means understanding the context required for this skill to perform, building a workflow for proper execution, identifying conditional dependencies, and cutting steps across the various commands.

A skill need not be a single entity that only does one thing. It can be complex.

For instance, I have a skill that edits my substack articles after I write them. But it is split into 3 commands: /substack-article-revise, /substack-article-structure-edit, /substack-article-final-edit. All three have different functionalities and require different context.

The logic for your design should come straight out of your runs. What did you correct? What did you have to repeat? Where did the chat go wrong?

Those should act as your specifications. The things that you have to repeat become context files, the things you correct become rules, and the things where the AI gave you a wrong output confidently become examples.

When I was use the meal planner chat, Claude kept on suggesting improper quantities. It kept finding recipes that were elaborate in ingredients and time. It couldn’t update what was in my pantry as easily. It ignored cost.

Every one of those issues helped me create the right files. Quantity mismatch led me to create a detailed portion size file that tracked what I actually used, how much it made, and how long did it last. I also created a live pantry file that updated when I accepted a recipe. The last one was a feedback loop that allowed me to say “the miso salmon was good but it took 60 minutes instead of 40.” So the skill would get better with every use.

But every skill you design doesn't have to be elaborate and doesn't need the same amount of freedom.

Anthropic frames the process of designing a skill as managing the degrees of freedom. How much depth and freedom you need to give to your skill depends on the expected outcome.

If you can achieve the same outcome via multiple routes, then you need to give the skill just some direction and a lot of freedom. But if the outcome has a serious chance of failure, then you need depth. You need guardrails, workflows and even examples.

Built It Elsewhere

Most advice I see on the internet for creating a skill is to use the same chat window to create and “package” your skill. And that is some of the worst advice I have ever heard.

The last time I built a skill inside the same chat window, the one that I had been using as a test ground, it backfired! Hard. That skill inherited almost every wrong action and decision, making it impossible for it to deliver the results I wanted.

So now I split the actual building into two steps. First, I go to the original chat window for a brief. I ask it to share the outcome we want, the decisions we made, the information we used, and the feedback we gathered along the way. Second, I open a new window and share my design, workflow, context files, rules, and examples (basically everything we created previously) along with the brief.

This helps me build a clean file that gets all the correct conclusions but not the detours.

Best Practices

The structure I just shared gets you a skill that works. Now the best practices below are the ones that unlock GOD MODE!

Order The Actions

Some skills have a sequence that they need to follow and some don’t. The meal planner has no sequential workflow as such. But my Substack skill and my Reddit skill do, and they have to run specific tasks in a specific order.

For the Reddit skill, it has to go through setup, daily scan, and a maintenance pass. In that order. Because if the skill runs them out of order then the output is worthless.

So when you come across a similar situation, write that order in the file itself as named phases or steps with rules for each and every phase. And make sure you define how the skill can know that an action is finished.

Keep A Log

Once you run something enough number of times, you naturally start to notice flaws. You think of better ways, easier ways to execute the same thing.

Version control is the single most important thing that helps me upgrade a skill without breaking it.

It might seem like an overkill to have “version: 2.3.1” for something that is used just by you. But, trust me, when your skill starts behaving differently and you can’t remember what you changed, version control literally saves you.

Build A Loop

Every skill should have a feedback loop. Not something you notice and then fix but something the skill notices and fixes.

Basically you need the skill to run the check, fix what failed, and run again to test. This, in my opinion, is the entire difference between a skill built by an amateur and one built by a professional.

Most of my skills now can run regression analysis on themselves. They have test cases, a matrix of good vs bad output, and a file to keep track of what was tested, what was changed, and what was the result.

A skill alone if fine. But somewhere in the last month I stopped building single skills. Now, I build Tasks. A task, the way I am describing it, is a collection of two or more skills/agents working with each other. They hand work to one another and even trigger each other when a particular action is taken.

I’ll share how I go about building those soon.

Until then, tell me how many skills/agents you use? Do you have any favorite ones?

“I don’t think I can ever be a solo founder.”

I’ve had a lot of conversations about solo founding and nobody has ever said this to me so plainly. I mean… everyone wants to believe that they could do it by themselves.

So I asked her why she thought that.

“I am a visionary,” she said. “Given how chaotic and spontaneous I am, I could never sustain a startup alone!”

It was a fair point and I didn’t have an answer for her then. But I do now.

The Benefit Of Being A Visionary

The best thing about being a visionary is that you can be at the cusp of a market that other people won’t see for years.

You connect things that don’t obviously belong together.

Your tolerance for risk is pretty high. When data proves an assumption wrong, you can creatively redesign the strategy, business model, and basically everything without fear.

You also have a relentless level of optimism that comes in handy when two years into being the founder, the novelty has worn off, the numbers haven’t moved as much lately, and you still have to handle the unglamorous work.

Where It Breaks

But I see her point. I understand exactly what she was worried about.

The Execution Gap: When you are so focused on the five-year version of your startup, the boring, daily work, can get a little sidetracked.

Nobody To Say No: You generate ideas faster than the team can execute them, and with no co-founder to stop you, you pivot every few weeks. This results in a product that is either a Frankenstein version of what you wanted to build or is nowhere close to the problem you started with.

Too Much In Love With Your Idea: The high risk tolerance and deep optimism can sometimes combine into a bit of stubbornness. You fall for your own idea so completely that you stop hearing what the users are telling you. You see only what you want to see and build something nobody asked for.

Scaling Before Required: The moment you have capital, you try to scale your startup assuming it has already become the startup of your vision. Hiring, marketing, office space, infrastructure. All of these might start to seem like necessary expenses but you don’t even have product market fit.

So the real question is: How can you keep the five-year vision in your head without letting it eat the weeks in front of you?

The Locked Tiles

When I interviewed Jen Yip for the Unfair Advantage piece to learn how she bootstrapped Lunch Money for seven years, she described building the product like looking at a video game map. She wanted to only see the tiles that were already unlocked while the rest of the map stayed dark until she had enough “experience points” to unlock it.

She wasn’t planning ten moves out. She was just looking at the next one.

And this, in my opinion, is the best advice for a visionary. In fact, I believe, this is exactly how every early-stage founder should think. Obviously you should know where you are going and you need the big picture. But you should never fixate on it.

Before you have concrete evidence that people want what you are building, you simply can’t operate off what you want the company to look like a year from now. Because you don’t actually know whether you’ll be there in a year. Your job, your only job, is to survive the next month.

So… Can A Visionary Be A Solo Founder?

I believe all founders have to be a bit visionary.

And I have hit every one of the issues on some level. I’ve been fixated on the 5 year vision. I have radically changed paths. And I have spent money on things I shouldn’t have when the only job in front of me was finding product-market fit.

So yes, I do think that a visionary can be a solo founder, as long as they know where they leak and they plug it with other people or maybe even AI. Three things that can close those gaps.

Hire Your Opposite

Your first hire should be the person who can turn your chaos into coherence. You want someone detail-oriented and priority-driven, the kind of person who has probably already built their own productivity system.

They own timelines and project management. They hold you to the deadline you set back when you were feeling ambitious.

At Shezaar, my first hire was an engineer and he was as detail-oriented as they come. Every week, we had a standing meeting to discuss product feedback and I used to bombard him with insane amounts of information. He would take a few hours and then come back to me with a proper structure.

If you can’t afford someone like that yet, you can always build a version of them. I have a chief of staff now that I built with Claude. Throughout the day I send it voice notes, whatever’s in my head at the time, and it turns them into organized tasks and keeps track of what I still owe people.

Find Advisors Who Are Blunt

You want advisors who have either been founders themselves or know execution well enough to spot when you are drifting. And you have to give them the explicit permission to be blunt otherwise people tend to be polite.

I had three people who did this for me and those conversations saved me from a lot of mistakes.

Build Your Village

The case for a co-founder is that there’s one person on the team who can tell you no and who’s genuinely incentivized to do it. None of your employees will. Advisors sometimes might, if you’ve given them room but you can’t call on them often. So most days there’s nobody whose interests are tied to stopping you.

The closest replacement I have seen are other founders who are roughly at your stage.

Right before my first pitch competition, I met two female founders who were gearing up to pitch too. So we formed a little group. We met on Fridays and practiced with each other. We kept the ritual going even after the pitches were over. Some days we would just rant about our day. On others we would bring the problems we were stuck on and discuss the solutions.

That group became the informal board I never appointed.

So if you are a solo founder, I urge you to find this. Find the people you can ask stupid questions. The ones who can tell you that you are about to make a mistake because they have made it themselves 3 weeks ago. The ones who share their wins and their losses with you.

Having people like that to rely on is a dream, and it’s why I am building Table for One.

Anybody can be a solo founder now. You don’t have to fit in a box to be one. All you have to do is understand your weaknesses and plan for them.

What do you think?

Subscribe now

Join Table for One | Other Articles

I have wasted weeks of my time, my engineer’s time, and my startup’s money building the wrong thing.

Not because I was building in an echo chamber. Not because I wasn’t conducting enough customer interviews. Because I wasn’t using the information I already had properly.

Let me explain.

The case for user interviews is that it keeps you close to the problem of the people who are actually going to pay you.

And the standard advice on how it should go is as follows:

1. Define your hypotheses and your open questions

2. Find your ideal target customers

3. Build rapport, focus on behavior, find more information about their problems and do not disclose the product

4. Synthesize your findings

5. Identify the features required for your MVP

Now for whatever reason, there are hundreds of thousands on videos and articles on conducting the interview. From how to find the people to what to ask. But you can hardly find anything on the synthesis of the information you get during the interview.

And I see most founders, including me, get this wrong. We think we are not biased. We try not to think about the solution or the features we cooked up in our heads. But we are wrong.

Our biases do creep in!

After reading forty minutes of transcripts and seeing the comments that sound like agreement, we choose to let them stay with us. We miss the thing she said she does. We miss the confused questions she asked. We even miss the hesitation she had to pay for a solution. And We draw a conclusion from what we want to notice.

Getting Users To Talk Is The Easy Part

Understanding what exactly they need is more difficult.

No matter what you do, you cannot achieve this result via a form. On a form people fill in what you put in front of them, so you can write the most open ended question in the world and still only hear back about the thing you already thought to wonder about. Your blind spots stay exactly where they were.

The ability to synthesize the right information from your user interviews is a serious skill. If you can do that, you can see which hypothesis actually moved and which open questions are still sitting there.

It could be the difference between building something people use and something they seem excited about but don’t actually want.

Capture What You Heard

So how do you “synthesize information” from the interview? What do you even look for? What do you need to update?

Well I am sharing what I know, what I have done, and what has worked for me. I am not claiming to be an expert in this. So do not come after me!

Okay… You have 40 minutes of transcripts. Now what?

If you go through it looking for the bits that agree with you, you WILL find them. And users are not trying to mislead you. They are just polite or helpful or genuinely clever. So the information they give you is something you want to hear.

Usually I try to avoid these typical signs:

• The polite comments like “I would definitely use that”, “I could see myself paying for it” or something similar that promises a payment in the future. Unless they already pay for something of a solution in time or money, the promise doesn’t mean anything.

• The helpful comments that suggest a feature like “Oh you should build a dashboard” or “Can we click a picture of the fridge.” Some of them are genuinely helpful but some of them could be enthusiasts. You need to be able to differentiate.

• The expert comments without context like “oh yes this is a problem” or “someone should solve it.” These people could have seen the issue and their thoughts could help you. But if this person is not the end user, then their support might not mean as much.

The entire job of synthesizing the transcripts is basically to understand:

• Which hypotheses are getting stronger

• Which open questions are getting answered

• What evidence am I collecting

• And what evidence do I still need to get

But a few interviews in when you are frustrated and can’t think straight, things can get a bit muddled up.

But lucky for us, we can train AI to do this job! We can make it an unbiased synthesizer of information. So the thing I am going to show you today is how to train Claude or ChatGPT to do the unbiased pattern recognition for you.

Build It Yourself

Everything below is a step by step method that you can use in either Claude or ChatGPT. I personally prefer Claude over ChatGPT. But you do you!

You do not need to know how to code. You just have to paste the instructions in the box into your chat/code terminal.

Step 1: Building The Brain

Before you build any skill, you need a company brain.

Don’t worry I am not asking you to build anything convoluted. Just a simple structure to store your information and to give the skill a place to drop the documents it creates.

This image is the exact snapshot of how I had structured my startup brain. You don’t have to create all the files. All you need to create are the folders.

A few rules to follow when you create a brain:

1. Store everything as an MD file. MD files are plain text files your AI can open, read and rewrite without a conversion step in between. The file size is small and it saves you a lot of tokens as compared to a pdf.

2. Fix the filenames. It is a boring rule but a bit of structure right now goes a long way when you have tons of information to deal with.

3. Number the files you save. Number your interview transcripts like “interview-01-sam.md” or “interview-01.md.” A level of organization will genuinely help you a lot later on.

You can also paste this instruction in Claude Code/codex or claude cowork to create it for you:

Step 2: Creating The Skill

Now moving onto the skill itself. This is the one that reads the transcript and tells you what moved.

So paste this in:

I always add an interview step in the skills I make. It might feel like boring admin work but if you do not have a brain folder or a way to give specific context, getting your AI to interview you is always a good idea.

Step 3: The Rules

These are important for this skill. It will keep it honest and reliable even when you want to process more information.

Feel free to add your own rules in the script too:

Step 4: The Difference Between Good And Bad

Most people that make skills don’t really focus on the output. They create the skill and then try to fix it once something breaks. That is one way to do it. Another way that I like is to already define what a good vs bad output is.

So this way you skip the initial back and forth.

You can even ask the AI to write its own examples for good and bad so that you can grade them.

Step 5: The First Run

The best thing to have before the first run is a list of hypotheses and a list of assumptions. It is important for the skill to know what it is that you what to understand.

Once everything is set up, drop your transcripts in the interviews folder and run the skill.

This article is a part of an AI Workforce that I am building for early-stage founders. Every Tuesday, I will share a functional task that makes your job easier. Below this is a ready to use task file. This file gives you three things: the interview synthesizer, the validation dashboard (so you don’t have to read MD files), and the persona builder (so you know what kind of people you are catering to). It is available to all the paid subscribers and it is the first (of 55) tasks from the AI Workforce Map.

Ready To Use

Above this was the instruction to build one skill. But we are not building skills.

A task, the way I have structured it, is the whole job rather than one step of it. The task, Capture What You Heard, sits inside Validate The Idea and has three skills in total.

1. The Interview Synthesizer. The one I wrote about above. This skill sharpens your hypotheses, answers what it can, collects evidence for you and files all of these things for you to see.

2. The Validation Dashboard. This dashboard is a way to see your validation journey. The output generated by every skill in Validate The Idea can be seen here.

3. The Persona Builder. It groups the people you talked to based on their behavior and their triggers so that you can start to see past demographics.

This is one of the 55 tasks that I am building. The next one is Study Your Competition. It is also a package of three but it has one agent and two skills.

If you build it and something breaks, reach out. And if there are some tasks that you want me to build for instead, tell me!

We have 250+ new subscribers join Table for One in the last 4 days. I am SPEECHLESS and extremely grateful! Thank you!!

Now, I believe that being a solo founder especially in the early stages is an incredible advantage! And this series is the case for it, one founder at a time. For each article, I sit down with a solo founder from backgrounds as far apart as I can find, and we dig for the edge each of them built on. What did they do to get to where they are?

Somewhere in these stories is a founder who started exactly where you are. And I am hoping their story hands you the courage to start yours! 🩷

Let’s goooo!

The manufacturer was locked in, the scent approved, the website rebuilt, and some money already spent, when Alisha decided not to launch the perfume.

Months of her life had gone into it and she still decided to walk away.

Why??

I’ll tell you.

But first, let me tell you how Beauty in Balance started.

Making Room For The Thing She Loved

Alisha graduated a semester early. That handed her something most people never get, nine months before her job started. Nine months with nothing claimed.

So she chose to finally give her passion some real time. The thing she’d loved since before she can remember and the thing her career had been quietly squeezing out for years without asking. For her, that meant dance. She got on a plane to teach workshops across the country, ten workshops with two hundred people over four months.

“And I think that was, this first realization that there is a whole career in the arts.” - Alisha

We all live by a simple, unspoken script. Study hard. Find a good job. Work till you’re sixty. Retire. Our passions get a worse fate than side characters in a horror movie.

On the tour, she kept meeting people trapped in that exact script. A real craft on one side, a career that paid the rent on the other, and an unspoken rule that you should focus on one.

She started calling it The Land Of The Or.

“You are a dance teacher or you are a consultant. But never both.” - Alisha

Feeling the strong desire to prove that people can be both, Alisha started to post on Instagram. What was supposed to be a place to share her own passion soon became a platform for other creatives. Beauty In Balance is now at 1,500 members online, with 2,000 people reached in person, and averaging around 700,000 impressions a month.

And it’s just over a year old.

Listening Before Building

Her first members came from the dance tour itself. She went back to everyone who’d taken her classes to see if they were following their passion full-time.

Most weren’t. But what surprised her was how many of them looked shocked to learn she wasn’t either.

A room full of people who’d built real skill in something they’d been told to keep as a hobby, all assuming the woman running the workshop had already made it her job. And soon she saw a pattern.

Nobody in that room lacked the skill to go full time.

What they lacked was a way to get paid for it that didn’t feel like busking.

People pay to learn dance. People pay to watch a good performance. So demand was never the problem. What was missing was the infrastructure to make a creative skill pay the way a corporate skill does. Or even remotely close to the way a corporate skill does.

Beauty in Balance became a creative collective built around what she now calls the infrastructure that never existed. The Power of AND, a real curriculum, sold to the institutions who wanted access to creatives with real followings.

NYU Stern. UC Berkeley Haas. Brands like NUDESTIX and TikTok. Conferences all the way to SXSW.

She could have kept pursuing dance on the side. She could have found a group that practiced on weekends.

Instead, she listened. She listened hard, to what people like her wanted but couldn’t say out loud, and built the thing nobody had built yet.

The Discipline To Question

Somewhere along the way, Alisha thought her community needed a product line, starting with a signature scent.

But building a community is really about selling a point of view, and when taste is the product, founders can sometimes ship things only they want.

So she stopped and asked herself:

“Is this the right time to launch a perfume? Am I rushing into this decision?” - Alisha

And she realized she was about to take something that existed only in her own head and push it onto her community.

She killed the perfume because she didn’t want to do that. She wanted to take the time to find out what these people actually wanted and needed first.

Every founder eventually finds out how easy it is to build one more feature, offer one more thing, launch one more SKU. The only real constraint is your imagination. So the actual question comes down to necessity. Whether the new thing does your existing customer any good, or whether it’s just something you wanted to make.

And I’ve made the same mistake.

One time I thought it would be really cool if I could tell my users the exact chemicals in their clothing. Nobody had asked for that feature. But I thought my users would really like it.

So I spent a whole week down a research rabbit hole trying to build that database.

That is how most of us are. We build in a bubble, on top of a stack of assumptions we never bothered to question.

But we need to interrogate our thinking. We need to ask ourselves… Does this feel rushed? Is this actually needed right now? Do I have enough information to be making this call at all?

That is the habit worth building. Not the discipline to ship. The discipline to question.

Niche Is Never A Problem

The Chicago Fashion Coalition sent her a message out of nowhere. They wanted Beauty in Balance to host a South Asian fashion show.

Beauty in Balance isn’t a South Asian collective. It just happens to have a large South Asian membership, and Alisha didn’t want to restrict the membership to South Asians.

But she knew that in the entire history of Chicago Fashion Week, there had never been a South Asian fashion show. This would be the first.

She took the harder call and leaned into the niche instead of running from it.

The concept she built was called The Second Shift, for people whose first shift is their job and second shift is their art.

Six designers. Countless dancers, singers, and models sharing the runway. A sound producer scoring the walks.

Three acts which were structured more like a story instead of a simple fashion show.

Designers who had never shown before stood next to people who had never modeled before and it was ELECTRIC!

WHAT A SHOW!!! Every designer DELIVERED! Every model OWNED that runway like they'd done it a hundred times before.

And this year, The Second Shift is hosting an even bigger show in New York! (Something you wouldn’t want to miss!!)

Understanding Her Advantage

Building has never been this accessible, and everyone with a laptop calls themselves a founder now. So in a crowd that crowded, you need every advantage you can find, wherever it comes from. That’s exactly what I wanted to know about Alisha.

So I asked her the question this series exists to ask. What was her unfair advantage? She said, without any hesitation, “My parents.”

Her father has sold four companies. Her mother recently launched a company.

“During our dinner conversations, we'd pull ideas out of the blue, and discuss what would we do to solve this problem? From a very young age I was surrounded by this type of conversation. So when it came to having an idea, I knew exactly how to act on it.” - Alisha

I come from an entrepreneurial family too, so I know what it actually hands you, and it’s not money or contacts. It is a mindset.

It teaches you that failure isn’t a bad thing, because you’ve watched adults fail and discuss what they learned at the same dinner table. It teaches you to see problems instead of complaints. And it teaches you that the risky bet is worth taking more often, because you’ve watched enough of them to know the cost of never acting is worse.

It’s easy to hear “my parents” and file this whole thing under privilege. But privilege that never gets used is just a story you tell at parties, and plenty of people with the exact same starting point never build anything with it.

Entrepreneurial parents. A decade in supply chain. The internship you got when you were 18. The year off you took to travel.

Every. Angle. Counts.

We just need to learn how to use whatever we have got.

So what do you do if you don’t have this particular one? You go and build it. You find the right table where failures get celebrated, solutions get discussed, and risks get normalized. That table doesn’t have to be the one you were born at. It just has to exist somewhere you can reach it.

Now What

Alisha started this by accident, and now a lot of us are doing some version of it. Everyone is building a personal brand. Everyone is trying to carve out time off, trying to actually enjoy their life instead of just surviving it.

In a world where people are quietly clawing their way back to whatever they used to be passionate about, Alisha built one of the few places that’ll actually help you do it, and get paid while you’re at it. If you are a creative or an athlete figuring out how to do the one thing you are actually passionate about, that is the room to be in.

If you're a creative reading this, trust me, Beauty In Balance is your place!

Check out Beauty in Balance's website and follow their Substack.

And get The Power of AND. It's a curriculum written for YOU, someone with a real craft and a real job who has been told to pick one.

Alisha is giving Table for One readers a discount with the code EARLYBIB.

Get The Power of AND

This was the story of how Alisha built Beauty In Balance. Below this, in the paid section, is a playbook I pulled out of the interview. A playbook that you should follow if you want to build a mission-oriented community!

Thank you for reading all the way here.

If you are a solo founder who is craving a space where you can share your thoughts, learn from others, and build amazing things, Table for One is that place for you!

And if this piece hit something in you, tell me your story.

Subscribe now

Someone in my own city was building the exact same product, the exact same idea, for the exact same customer.

I had a competitor and I was sure this was the thing that would end Shezaar!!

Their product seemed it was almost built.

So how would I compete with the exact same idea? I had no differentiation left. Would I have to change my product?

The Competitors You Never See

I am happy I didn’t act on it. Because the year that followed proved just how WRONG I had it!!

Bob Moesta and Chris Spiek, who’ve spent years studying why people switch products, map every purchase as a fight between four forces. Two of them push your customer toward you. The other two hold her exactly where she is.

If you have less than 100 customers (in B2C) and less than 10 (in B2B), these forces are the only competitors that you should care about.

And I will bet you anything that one of them is beating you right now.

How Bad Is The Current Situation?

I started Shezaar because I was obsessed with reducing the waste fashion created. I had seen first hand what it did to communities in Chile and Peru, and I wanted to do my part to fix it.

Fashion brands don’t discard just a few racks of unsold clothing. They bury entire warehouses every single month.

So the problem was clearly real and clearly very enormous.

And for years, nobody cared where any of it ended up. But the upcoming, stricter regulations around end producer responsibility were about to change that. And I thought this presented a perfect opportunity.

My hypothesis was simple. If a brand was going to be held accountable for its product ending up in a landfill, the current supply chain was too convoluted to trust.

So I started to build on this hypothesis.

Every founder of a fashion brand I spoke to, agreed that this was a huge problem. Coincidentally in 2025 the fashion market was moving towards supporting circular business models.

So, in my head, this was like my entire market saying yes to Shezaar before I had even asked.

The reality was far from it.

A survey revealed that only 7% of fashion executives planned to put money behind circular business models and less than a third called resale a priority for 2026.

Which is why it took me a while to realize that the problem I found was real and expensive and getting increasingly regulated. But it wasn’t a priority for this quarter, or even this year.

When you stumble upon a problem and think you want to build a solution for it, you need to prove that this problem is urgent enough for your customer that they’ll pay you right now to solve it.

But I have seen customers do often say things we want to hear, just to be polite.

So these two questions have been my way to sift through my customer’s words and get to their actions.

I had brands agree the problem was real, agree the regulation was coming, and still do nothing at all. It took me a long time to work out what I was actually being measured against. Not the other platforms. The version of a solution they were already doing badly, for cheap.

How Good Is The New Thing?

Let’s say the problem is urgent. The next thing you need to figure out is whether your solution is actually better than what this person is already doing without you?

My offer was that the brand gives me its unsold inventory and never sees it again. I sell what I can through the app, hand the rest to donation partners who actually move product, and send whatever’s left to a recycler. At every step the brand can log in and see where its own clothes ended up.

This offer was a better product for maybe half the people I pitched it to. But it wasn’t a better product for the brands I actually wanted.

If a brand already had a warehouse and a logistics team, I was replacing something that already worked. And the regulation that would’ve made this their problem was three years away.

The version of Shezaar that would have won those big brands needed data I hadn’t collected yet. So what I was really asking them to buy was a bet, that I’d be enough better by the time they actually needed me. That was a hard sell.

If your thing is only a little better than what someone already does, the hassle of switching isn’t worth it. And from your side of the table that gap always looks bigger than it is. Founders overvalue the thing they just built.

So run this test on your own idea:

If you can answer that cleanly, you’re on the right track.

Now lets say your product is dramatically better and your customer’s problem is urgent. Somebody still has to take an action they might not have taken before.

What Habits The Customer Has To Break?

This is the one I never accounted for.

Every brand that agreed with me still had to break a habit that nobody on their team had budgeted a single hour for.

Adopting Shezaar meant an ops person logging SKUs, photos, and condition notes into a system nobody on the team had used before, on top of a job that was already full. A liquidator just showed up and hauled the product away.

So I took the work off their hands entirely. All a brand had to do was put the inventory on a truck. I photographed every piece, wrote the condition notes, loaded all of it into the system, and they could still log in and see exactly what had arrived and what was happening with their inventory.

The products you say yes to without thinking twice are the ones that fit into the day you already have.

And if using your product means breaking a habit, it stops mattering how much better the product is. Adoption gets hard.

But let’s say that change in behavior is unavoidable. Then there are two ways to get better adoption.

1. Go after people who don’t have the old habit yet.

2. Find the handful of true believers, the “early adopters”, who will switch on conviction alone.

But sometimes a customer can agree the problem is urgent, agree you’re dramatically better, agree you’ve made the switch almost free, and still do nothing.

What Happens If The Customer Gets It Wrong?

Matt Dixon and Ted McKenna studied more than 2.5 million recorded sales calls for a book called The JOLT Effect, and found that 40 to 60% of deals die from no decision at all.

The thing beating founders most often is nobody. Not another company. Not a better offer.

Just the customer’s fear of being wrong.

“Nobody ever got fired for buying IBM” is the oldest line in enterprise sales. Because it means that the safe option is the one that, when it goes wrong, can’t be traced back to one person.

And that fear is strongest at the top. The person who has the authority to say yes to you is also the person with the most to lose if that yes doesn’t work out.

You can manufacture urgency. You can build something dramatically better. You can absorb every hour of the work so nobody on their side has to change what they do all day. But there is no feature you can ship that fixes somebody’s fear of looking stupid in front of their boss.

The only thing that fixes it is trust. And you’re not building trust in a thirty minute call.

Which is why I stopped treating the cold email as the first touch. Before I sent one, I’d spend three or four days literally stalking that brand’s Instagram, actually reading and commenting. If I could find the founder and their profile was open, I followed them and engaged there too, always from my personal account. If they wrote on Substack I would read it. If they were on LinkedIn I was there.

By the time my email landed, I wasn’t a stranger asking for their unsold inventory. I was the girl who’d been hanging around for a few days leaving thoughtful comments I could reference.

It’s tedious, it’s slow, and there were weeks I hated it. But I don’t think a single brand would have said yes to me without it.

Before You Panic

Not every product has to solve something urgent. Plenty of the apps on my phone were built on something nobody was losing sleep over, and how we build for that is a whole other piece.

So the next time a competitor turns up in your feed, you don’t have to panic the way I did.

If you’re still looking for product market fit, there are four other things standing between you and your next customer. And none of them are ever going to show up on Instagram.

Tell me which one of the four is beating you right now. That’s the one worth your hour.

Leave a comment

If you're a solo founder building something, tell me. And let me know how I can help!

There are three moments like this I keep coming back to, three things I didn’t expect a fashion-tech startup to teach me. This is where it starts.

Moment 1

I am, since forever, an extremely introverted, anti-social person. I love my solitude. I almost always have to prepare myself before I meet anyone. And I am extremely self-conscious about how I look on camera.

So... putting myself out there in front of a camera for an idea that can fail was HUGE.

And that day, despite spending hours shooting and editing that video, I didn’t post it.

But the next day, I was scrolling Instagram and I landed on another founder’s page, barely 200 followers, talking about the exact fear I’d just spent a whole day fixated on.

So I thought, if she could say the vulnerable thing out loud, I could too. And if I wanted my product out in the world, talking about it was MY job. Nobody else was going to do it for me.

So I started posting anyway. Badly and mostly to an audience of less than 100 followers.

Because the rule of entrepreneurship, especially in the early days, is to just show up.

And eventually things got better. And to my absolute horror, I actually started to like creating content.

I’m still self-conscious about how I look on camera. But what changed is I stopped caring whether I looked good and started caring whether the thing, the video, the post, the article, worked.

The whole point of content was never me. It was getting a product, even a bad one, in front of users early enough to hear what was wrong with it.

Somewhere in there, content stopped being vanity and turned into a distribution strategy.

Moment 2

Coding scared me just as much, long before Shezaar existed.

I studied electronics and telecommunication engineering in college, where a CS class was mandatory for two semesters out of eight, and I dreaded both of them. The professors who taught it were some of the strictest in the department, prone to tearing into you the moment you got something wrong. I remember the anxiety before every class, every exam, the kind of anxiety that sits in your stomach for days beforehand. Anxiety that made me hate CS as a subject.

So the moment I finished the mandatory classes, I told myself I was done. I was never touching a terminal again.

But being a solo founder meant nobody was coming to build the MVP for me. I needed a working prototype to put in front of the people signing up for my waitlist. Hiring an engineer wasn’t an option because I wanted my savings to last as long as possible. So I decided to do it myself.

I tried Bubble first, the no-code route, and it couldn’t do what I needed the product to do. So I moved to Cursor, vibe-coded most of the real thing with the help of ChatGPT and Claude, and taught myself to understand code, one Codedex exercise at a time.

Without an exam attached to it, without a professor waiting to grade the practical, coding turned out to be something I liked. I still go back to Codedex for the exercises now, just because I like doing them.

I now practically live in Claude Code. I have built so many things including an operating system that tags my tasks, tracks my content analytics across every platform, helps me remember and build my network, and is basically the smartest chief of staff.

Subscribe now

Moment 3

Writing surprised me the most, because I already knew I loved it.

I wrote short stories as a kid and kept a journal for years.

But none of it ever left my room.

Not my parents, not my closest friends. Nobody knew I did it. Writing was the one thing I never wanted to turn into a performance.

Somewhere in my twenties I mostly forgot I used to do that. The real barrier wasn’t the newsletter itself, it was that I’d always guarded my deepest thoughts and never felt safe handing them to anyone.

So starting a substack for Shezaar gave me a low-risk way around that. I was writing in the brand’s voice, but I kept sneaking my own take in as the founder anyway, and people started discussing my opinions with me.

That’s the only reason Table For One exists. If nobody had responded to my take hiding inside Shezaar’s brand voice, starting a newsletter under my own name would never have occurred to me.

None of these three things were the plan. I built Shezaar to fix a textile-waste problem, not to become a person who is fine on camera, self-taught in code, and willing to publish her own writing. I got all three anyway, as a side effect of the one decision that actually mattered: build the thing, put it in front of real people, and let the discomfort teach you whatever it is going to teach you.

So here’s my only ask. Whatever you’re telling yourself you’re not enough for, trust that you’ll figure it out anyway. You don’t need to be good at coding right now to build an MVP. You don’t need to be good at marketing right now to get your first users. You don’t have to be good at finance to raise money.

You don’t need anything else. Because when push comes to shove, when you’re the only one who’s supposed to do it, you’ll end up doing it.

That’s why I’m building Table For One. It’s a community for solo founders brave enough to take the first step.

You still have to be the one who does it. You just don’t have to make a thousand mistakes to get there, not when other solo founders doing the exact same hard thing are already in the room.

If that’s you, apply to be a member and check out our events calendar.

APPLY

Okay, commercial over.

I spent most of this newsletter telling you what Shezaar cost me. This is the other half of that ledger. I did not expect a failed startup to leave me braver, stronger, and smarter.

What would you find out about yourself if you stopped waiting for permission to start?

If any of this sounds like you, reply and tell me what you’re sitting on.

A few months into building Shezaar, I was creating top-of-funnel content everywhere. Instagram, TikTok, Linkedin, Substack. You name it.

It wore me down faster than any week of sales or customer interviews or fundraising.

Because all of that effort converted to no views. Meanwhile, I just completely ignored Reddit, a goldmine that I hadn’t even thought of.

Until one day, I landed on a Reddit thread and everything changed. I saw a post where someone asked the same question one of my blogs answered. So, I commented with pure value, in a way I would answer a friend over text. And that comment got me 5 responses and 2 DMs!

So I started showing up on Reddit a few times a week after that. And just like that, with just three or four comments a week, I started driving real growth.

But it is not as easy as it sounds and the penalty of making a mistake is too heavy.

The 70/30 Rule

The instinct almost everyone reaches for is to promote what you have built. To post something maybe a link or a landing page. But that never works.

Subreddits are strict about self-promotion, and even the few that allow it get you two or three clicks, which are useless.

Seventy percent of what you post should be purely helpful. No link. No product. Basically nothing that promotes you in any way. But a real answer to what the person asked. Or a real post that starts a conversation.

This is what makes you a contributor instead of someone farming Reddit for clicks.

The other thirty percent can point somewhere. But it should never say “I built …” or “My product ….” Redditors are very very allergic to that! What works instead is saying something like “I found this article, here is what it says, linking it below if you want to read the rest.” Or a post that has undeniable value.

Here is a post that was me being pure vulnerable:

And here is one where I mentioned my own build, but I wasn’t selling anything:

Reddit is a long game!

But doing this well, every single day, across ten or so subreddits, is not something anyone can sustain for long. You either burn out or start cutting corners.

And cutting corners is exactly what got my first account banned.

The System

This Claude skill is a perfect system to show up every day.

It has three parts and everything runs through the browser in Claude Cowork.

The Scout

The Scout interviews you to learn what you want out of Reddit right now. It understands your product, its stage, your audience, what you can hand a user today, and how you write. Because organic outreach works best when you are extremely specific. Then it finds 10 to 12 active subreddits where that conversation is already happening. All of this gets stored to a profile md file. The first time this file is created, you need to check it and sharpen it. This file is the brain of the whole thing so you have to make sure that it is accurate.

Command: “Set up my Reddit system.”

The Sifter

This is the task that runs daily. It opens each of your subreddits, scores them, and hands you five threads worth your time with a comment already drafted in your voice. Just fifteen minutes of this every day and you have made a real dent in your organic growth. Save this as a scheduled Cowork task for early morning so all of the sifting is done before you even wake up.

Command: “Run my daily Reddit scan.”

The Coach

Once you have posted a dozen or so comments, the Coach analyzes which ones landed, writes down what works, and feeds that back to the Sifter so the picks get sharper over time. You do not have to keep a list yourself. Each time you post a comment, paste its link into the chat or say “log the one I posted“ and the skill logs it.

Command: “Review how my Reddit outreach is going.”

So all you need is a Claude subscription with “Code execution and file creation” turned on in settings so it can save its notes to files.

Download the skill file at the bottom of this post and drop it into your Claude account.

How To Not Create “AI-Slop” Comments

The only thing that makes any skill good is context. So, point the skill to your resources!

If you have your own essays, a product one-pager, a doc that answers a question you get all the time, point the system to them during setup.

Resources sharpen who the skill thinks you are.

Twenty articles that you wrote about your product or your industry tell it what you can credibly answer. Once it knows what you have deep answers for, the Sifter can prioritize threads where you are the right person to reply. And it can weave the exact references in the comments.

If you have nothing to point to yet, skip it. The system works fine without it. But the day you do, this is a game changer.

Steal Mine

If you use it, tell me what worked and what didn’t. If you are an early-stage founder, tell me what you are building and I would love to help any way I can!

Reddit Outreach Skill

Durva

In my opinion, it should be a matter of hours!

Over the last 2 years, I have worked on 8 ideas. 5 were pivots and versions of my old startup, and 3 came after I closed the business, all three in just the last 2 months.

Across all 8, I have been trying to perfect one thing: how fast I can go from an idea to actually talking to potential users.

The first one took 3 months to go from an idea in my head to an actual conversation with a user, because I wanted to walk in with something finished. I never once stopped to ask whether they wanted my solution, or whether they even had the problem I assumed they had.

The one I am building right now already has 17 people testing it from day 1. Every one of them is giving me feedback, on the name, the design language, the features, and a few have already started referring their friends and family.

And that, in my opinion, is the right way to build.

So how do I pull that off? It is not magic. It just takes a little strategy and a little courage.

Today, I want to share my strategy.

The Prompts

Everything in this process runs in a Claude or ChatGPT chat on any model.

The only part that takes some time and a little courage is getting real people to answer a survey. Real people who are ideally strangers.

Because responses trickle in over days the priority from day one is getting the survey out as fast as possible.

But before you start with the first prompt, write your hypothesis down on paper. I want you to write what you think the problem is, what you think people are doing about it today, and what you think the potential solutions could be.

Do it before you do anything else. Because everything that follows is created to prove or disprove your opinions.

Once you have that, copy these into your AI chat in order.

Prompt 1: Refining Your Thoughts

You are my validation partner for the next five days. We're going to stay in this one chat the whole time, so keep everything we produce here in mind as we go.

I have an early startup idea and I need to pressure-test it before I build anything.

Here's my raw idea:
[DESCRIBE YOUR IDEA IN 3–5 SENTENCES: the problem you think exists, who has it, and what you're thinking of building]

And here's what I already wrote down by hand, before any data:
[YOUR OWN FIRST DRAFT: what you think the problem is, what you think people do about it today, what you think the solution could be. Paste it rough. If you skipped this, go write it now.]

Your job: interview me to turn this into a clear one-page validation brief.

Rules:
- Ask me ONE question at a time. Wait for my answer before the next one. Don't dump a list.
- Keep going until you can fill every section below. Push on anything vague: if I say "small businesses," ask which ones.
- Don't be a cheerleader. If something sounds like a guess, call it a guess.
- Where my handwritten draft and my answers disagree, point it out.

Interview me until you can confidently fill in:
- The core problem (one sentence, in the user's words, not mine)
- Who exactly has it (specific: role, situation, not "everyone")
- How painful it is today and what they do instead (workaround / competitor / "nothing")
- My core hypothesis (the belief that, if wrong, kills the idea)
- My proposed solution (one sentence)

When you have enough, stop asking and output a document titled VALIDATION BRIEF with:
- Problem statement
- Target user (specific)
- Current alternatives
- My hypotheses (rewrite mine clearly)
- 3–5 additional hypotheses I haven't named but that this idea secretly depends on, the hidden assumptions that could sink it
- Riskiest assumption (the single thing most likely to be false, we test this first)
- Where this user already hangs out online (specific subreddits, communities, Slacks, forums, hashtags), I'll use this to find people
- Kill / Pivot / Continue criteria: what survey + research result would make you tell me to kill this, pivot it, or keep going? Give me concrete thresholds now, before I see any data.

Call it the VALIDATION BRIEF and refer back to it by that name for the rest of this chat. Do not quietly revise it later; if something we learn contradicts it, say so out loud.

Start by asking me your first question.

Prompt 2: Fast Landscape Scan

Using the VALIDATION BRIEF above, do a fast landscape scan with web search. 15 minutes of work, not a deep report. The deep one comes later.

I only need three things, in plain language, no jargon:
1. Is this problem already perfectly solved? List the top 3–5 things people use today (products, tools, hacks, spreadsheets) and one line on where each falls short.
2. Are there signs people actually want it fixed, complaints, workarounds, high-engagement threads? Give me 2–3 real examples with links.
3. Based on what you found, what 2–3 things should my survey probe that I might not think to ask?

Keep it under one screen. Bullets. End with Green / Yellow / Red light to keep going, and one sentence why.

If anything here contradicts the brief, say so plainly instead of smoothing it over.

Prompt 3: Build The Survey

Now build me a short validation survey I can drop straight into Tally or Google Forms. Use the VALIDATION BRIEF and the landscape scan above, especially the riskiest assumption and anything the scan told us to probe.

Non-negotiable rules:
- 5 questions. Aim for exactly five; 7 is the absolute ceiling and you need a reason to go past five. Every extra question costs responses.
- Default shape: 4 multiple-choice or scale questions, and at most ONE open-ended question that lets the person talk in their own words.
- Test my riskiest assumptions first, not my solution.
- Ask what people do and pay today, not what they would do. ("How do you handle X today?" not "Would you use a tool that…?")
- Neutral wording. Don't lead the witness, don't suggest the answer inside the question, don't sell my idea anywhere in the survey.
- Ask for name and email at the end, after every real question.

Give me, ready to paste:
1. Survey title (plain, not salesy)
2. Short description (2 sentences, what it's about + how long it takes, e.g. "Takes 90 seconds")
3. The 5 questions, each with type (multiple choice / scale / open text) and answer options
4. The final optional email question, worded well
5. One line under each question naming which hypothesis it tests, and what a good vs bad answer looks like, so I can read the first few responses live and know whether a question is pulling its weight

I would say ask for a name and an email last, after every real question. In my surveys this single change cut drop-off by 15 to 20 percent. Because identity requests up front make a form feel like a lead capture instead of a two-minute favor.

Another thing to remember is that you want to ask people what they do and pay for today, not what they would do if your solution existed. Because behavior is a far better predictor than what someone says they would do.

My own sweet spot is five questions with three multiple-choice and two open-ended, descriptive questions. And I always build my surveys in Tally with the Pro version. It is so worth the money. It shows partial submissions, so you still get signal from someone who drops off halfway. And I also get to observe how the first few people answer, so I can cut, rewrite, or drop a question mid-survey.

Prompt 3b: Optional Mid-survey Feedback

Here are the first responses that came in:
[PASTE THE FIRST 3–5 RESPONSES, partial ones included]

Against the hypotheses each question was meant to test: which questions are actually pulling their weight, and which are giving me mush? For anything weak, tell me whether to cut it or rewrite it, and give me the rewrite. Keep the count at five.

If people are dropping at a particular question, say which one and why you think so.

Subscribe now

Prompt 4: The Deep Research

While I collect survey responses, do the deep market research. Use full research mode and web search, dig properly. But the report must be written for someone who knows nothing about this industry.

Work from the VALIDATION BRIEF above, and test every hypothesis in it, mine and the ones you added. Don't re-litigate the landscape scan, go deeper than it.

Research rules:
- Do the heavy research, then translate it. Zero jargon. If you must use a term, define it in five words.
- Assume I know nothing about this market. Explain like you're telling a smart friend at a coffee shop.
- Every section starts with ⚡ TL;DR, do this: 1–3 concrete action items, not a summary.
- For each hypothesis: what the evidence suggests + confidence (High / Medium / Low) + one line why.

Structure the report exactly like this:
1. Is the problem real? (evidence people actually struggle with this)
2. Who has it, and how many (rough size in plain numbers, "roughly X million people / Y thousand businesses," not TAM/SAM jargon)
3. What they use today (the real competition, including "a spreadsheet" and "they just live with it")
4. Why now (what changed, why it hasn't been solved)
5. Reasons this could flop (be honest, the red flags)
6. Hypothesis scorecard (table: hypothesis → evidence → confidence)

End with a VALIDATION CHECKLIST + SCORE:
- 8–10 yes/no checks (e.g. "Is the problem frequent?", "Do people already pay to solve it?", "Is there a wedge competitors miss?")
- A score out of 10
- A one-line verdict: Strong signal / Mixed / Weak, and what would have to be true to move up a tier.

This score is a prediction, not the verdict. We'll compare it to what real people say at the end of the week.

Prompt 5: The Final Analysis

Survey responses are in. Give me the final validation call, using the VALIDATION BRIEF, the landscape scan, and the deep research report from earlier in this chat.

Raw survey responses (CSV):
[PASTE CSV, include partial submissions if your form captures them, and mark them as partial]

Do this:
1. For each question, tell me what the responses actually say, in plain language. Flag anything surprising. Note how many people left an email at the end and treat that percentage as a demand signal.
2. Go back to the Kill / Pivot / Continue criteria you set in the brief, before either of us had seen any data. Did the data hit them? Quote the thresholds back to me and be strict. Don't let me talk myself into it, and don't move the bar because the result is close.
3. Score each hypothesis: Supported / Mixed / Not supported (survey + research combined).
4. Cross-check: where do the survey and the research agree, and where do they contradict? Contradictions are where the real insight is. Also compare the research score you predicted earlier against what real people actually said, and tell me what the gap means.
5. Final VALIDATION SCORE out of 10 and one verdict:
   - BUILD: validated enough to make an MVP
   - PROBE: promising but one key thing is unproven; name the single next test
   - PARK: the evidence isn't there; tell me why, kindly but clearly

If BUILD or PROBE: the one riskiest thing still standing, and the fastest way to test it in the next five days.

This is also where you should think of a kill criteria because the best way to test multiple ideas is to think of it as an experiment. You hold the problem tightly and the solution loosely, and you stay open to whatever the feedback says, because an experiment can be proven or disproven, and neither outcome reflects on you. It just tells you whether this particular problem or this particular solution is the right one.

Why It’s Built This Way

I have used this exact structure eight times now, and each time, the fear of showing someone my unfinished idea got a little smaller.

I am still afraid of the judgment. But following a system means that by day five, I am not guessing anymore, and that is worth more than showing up with something polished.

I perfected this because it took me far too long to go from having an idea to actually talking to the people it was for.

If you run it on your own idea this week, reply and tell me which word you landed on. I want to know what got built, what got probed, and what finally got parked.

Durva

The Clicks That Weren’t Real

Unless you have been living under a rock, you already know about the Phia scandal by now.

For anyone who hasn’t fully followed it, here’s the plain version. Phia is a shopping assistant co-founded by Phoebe Gates and Sophia Kianni, launched in 2025, that lives on your laptop or your phone. When you’re shopping in Safari, Phia finds cheaper alternatives, ideally secondhand, for whatever you’re looking at.

Phia was supposedly a raging success among young shoppers, because now you could get coveted luxury fashion items for less.

But Bloomberg’s investigation found something uglier underneath. Phia was claiming sales it never actually drove. On iOS, when a user arrived through someone else’s affiliate link and hit checkout, the extension quietly opened a background tab, swapped in its own affiliate link, and took the credit for the sale.

Phia is not a one-off. It’s a pattern. And the pattern keeps getting worse.

Small Plug

Two years ago, I sat on an idea for eight months, too scared to start alone. I eventually built that idea into a real company, landed brand partnerships, raised money, made sales, and did it all as a solo founder with a team of seven.

Now I’m running a series to prove a solo non-technical founder can take a new idea, validate it, and ship a real app in 30 days, on three hours a day, max.

If you’re sitting on an idea too, come build with me. Follow me on Instagram.

Check Out My Instagram!

Fake It Till You Make It

Charlie Javice, a Wharton grad, built Frank, a student financial-aid startup, and rode it to Forbes 30 Under 30 in 2019. When JPMorgan came knocking, ready to buy, she told them Frank had more than 4 million customers when the real number was under 300,000.

They were reportedly counting anyone who had merely clicked the site as a user. And Javice paid a data-science professor roughly $18,000 to generate synthetic customer records to back the claim. That inflated number was a big part of what justified the price.

When JPMorgan’s team asked to see the real user data during due diligence, Javice blocked them, citing Frank’s privacy policy and terms of service. JPMorgan bought Frank for $175 million in 2021 anyway, and the deception fell apart the moment the bank tried to market to those “customers” and about 70 percent of the emails bounced.

Delve was the latest hot startup in Silicon Valley, the one everyone wanted a piece of, until a few months ago. Now it allegedly sits in a murkier space too. The YC-backed compliance automation startup, founded by Karun Kaushik and Selin Kocalar, raised $32 million at a $300 million valuation on the promise of SOC 2 and HIPAA certification in days instead of months. An anonymous whistleblower operation calling itself “DeepDelver,” published a roughly 10,000-word Substack investigation alleging fabricated compliance evidence, trust pages populated before any actual work had been done, and “certification” routed through what the report calls Indian shell entities dressed up as US CPA firms.

Sell first and build later has always been the rule in Silicon Valley! But not everyone who follows that rule ends up in court.

Some Lies Make You A Legend

We all know Reddit’s origin story. In the first few weeks, roughly 99 percent of submissions on the site were Alexis Ohanian and Steve Huffman posting under fake usernames, an attempt to solve the classic chicken-and-egg problem and set the tone before real users showed up.

Reddit faking its early users is beloved startup lore. Every product that relies on network-effects has done some version of it.

Nick Swinmurn founded Zappos by photographing shoes in local stores he had no relationship with and no inventory in, and when an order came in he would drive over, buy the pair at full retail, and ship it himself.

So, a human quietly doing the work behind an “AI” product is completely normal. It’s every Wizard-of-Oz MVP that ever shipped, including mine.

And no one wakes up one day and decides to commit fraud. It starts smaller, with harmless deceptions to get the ball rolling.

My Own Ladder Of Lies

Almost nobody wants to be first. Not the first customer. Not the first employee. Not the first investor.

So you stretch the truth a bit.

During my very first brand conversations, I told people I was closing deals with three brands when the reality was that I was just in the initial conversations. At my first networking event, I said I had a team of four people, but it was just me doing everything. I used to pretend to be an intern when I was interviewing people on the street, because I wanted to see their honest reactions. I said yes when someone asked if I had a cofounder, because I was embarrassed to admit I was a solo founder.

Then there’s the one I’m least proud of.

I was pitching to an angel, someone with real standing in the fashion-tech space, and it was going well. She liked the idea, and she liked me enough to talk seriously about writing a check. I name-dropped a few other angels I claimed to be talking to. She said she was friends with a few of those names, and she’d talk to them about a possible co-investment.

I froze. I admitted I’d reached out but hadn’t actually started those conversations. She politely said she would get back to me, but as expected, she never did.

So because of a small, seemingly inconsequential, lie, I lost someone who would have been in my corner, someone who was probably ready to write a check.

The Line

With this latest news, I’ve been sitting with something heavy.

Almost every early-stage founder stretches the truth in some way, most of the time, and I don’t think that’s bad.

Javice was convicted. Delve and Phia are still contested allegations. But none of them are a separate species from the rest of us. They’re what the stretching looks like after it goes unchecked long enough to compound.

So if that angel investor hadn’t called me out, would I have been capable of stopping? Could I have tried something bolder the next time?

And that’s not a comfortable feeling.

Because I am not sure whether I’m self-aware enough to know when I’m close to the line.

Are you?

What’s your “fake it till you make it” story? And will you be brave enough to draw the line?

But that does not happen anymore.

Every morning before I open my laptop, three of my minions aka Claude agents already have a stack of finished work waiting for me. One drafts a brief from the Substack articles, podcast episodes, and news that actually interest me. A second tracks everyone I follow and flags what changed about them overnight (a bit stalker, I know!). A third reads my content analytics, tells me what worked and what didn’t, and tells me who is engaging with my content and what I should say to them.

And none of them would break if I add anything on top!

So what changed between the version that broke and the one that hasn’t needed a fix in over a month?

Structure.

The Context

When you bring in AI automation, you are not writing code. You are writing a job description, and the agent is only as good as the information you provide.

Context is the onboarding packet.

An AI that doesn’t know who you are, what your business is, or what you have already tried will eventually get something wrong.

I think of context in two levels. First is the global level. This is context which will be used by every skill. So anything about the business goes in here. Who you are, who your audience is, the strategies you have already tried, what your voice actually sounds like. You get the picture.

Second is the local level. Context that I do not want other skills to touch. For example, I am building the same three-agent setup for Instagram that I have for Substack right now, and I deliberately do not want that agent reading how I write on Substack. The scripts I want on Instagram should not sound anything like a Substack article, so the rhythm rules stay local to the Substack agents only.

So my global context files are:

1. Who I am, in excruciating detail. How do I think? What do I like? What do I dislike? Everything.

2. What I am building right now. Substack, the community, Shezaar, and whatever I will do next. This file has that information.

3. What are my goals? What are my dreams? My why behind everything I do.

4. Who do I want to talk to? Who is my target audience?

For Substack specifically, my context folder is three files.

1. My voice. How I like to write. How I like to talk.

2. Any hooks and rhythms I like.

3. Who Table For One is for.

All of these files load automatically at the start of every editing session. There is a lot of trial and error involved in why I have arranged these the way I have, but this structure works the best for me.

That is the whole point of context: the system does not have to relearn who I am every time it runs. But an agent that knows everything about me and my business can still do something I never signed off on. So next I need a set of rules.

Subscribe now

The Guardrails

If context is the onboarding packet, guardrails are the job description.

I prefer to keep all the rules for one agent in a single folder inside the agent folder. And the job of the skill.md file is to make sure that my agent reads the rules.

For Substack specifically, my guardrails folder has two files.

Read more

I believe that being solo, especially in the early stages, is an advantage! And this series is the case for it, one founder at a time. For each article, I sit down with a solo founder from backgrounds as far apart as I can find, and we dig for the edge each of them built on. What did they do to get to where they are.

Somewhere in these stories, is a founder who started exactly where you are. And I am hoping their story hands you the courage to start yours.

Let’s goooo!

For a year and a half, a burnt-out software engineer tracked every dollar she spent across multiple currencies in a single spreadsheet. She was freelancing for three different companies, living out of a suitcase as a digital nomad, and had written off entrepreneurship entirely after a venture-backed startup left a bad taste in her mouth.

“Lunch Money started off as a side project that I decided to do because I was basically freelancing for three different companies as a software engineer and I missed coding for fun!”

Lunch Money is the budgeting app Jen Yip has run for seven years, entirely as a solo founder. It has been bootstrapped the whole way, and it grows without her breaking her back.

A Company Of One

For the first five years, Lunch Money was Jen and one part-time person in the Philippines only handling bank-syncing tickets. Every other support email, every feature request, every “why isn’t this transaction categorizing right,” went to Jen directly, on purpose. About two years ago she decided she did not want to do it alone anymore and brought on a core team of five, plus a small group of contractors.

These days she takes meetings only between ten and noon, Monday through Wednesday. The rest of the week is hers.

So what is her secret?

Subscribe now

Having Fun, On Purpose

She was having fun! And I do not mean that as a throwaway.

Jen built Lunch Money for herself, blissfully unaware it would turn into anything. As a software engineer she had spent years in jobs where nobody let her design and nobody let her near marketing. On her own project she got to put on every hat at once, and she loved it!

I feel a version of this right now. Table For One is the most fun I have had building anything. I get to talk to solo founders all day, learn how they actually think, and build a community for the people doing the hardest thing alone.

When the idea or the job itself interests you, the best part is not some reward waiting at the end. It is getting to do the thing you love day in and day out!

The Money Part, Honestly

Jen was able to sustain building something that made almost nothing the first two years because she had some cushion and she was relentless about making it last. She had four years of savings from Twitter, from before it went public. She then moved to Taiwan, where meals ran three dollars and she could walk everywhere. She built tools in-house instead of subscribing to them. She tracked every dollar and she was scrappy to the core.

The savings did give her the runway, but that discipline is what stretched it far enough to fund years of unglamorous building without ever taking a cent of outside money.

“Lunch Money was never about getting rich or making money. It was always about getting back to the roots of what I like to do, which is building, coding.”

Not raising was a strategy, not an accident. She had done it before, sat across from the investors, and seen the part of Silicon Valley she wanted no part of.

“I never felt the pressure to raise. 0%.”

She did not want to owe anyone, and she did not want anyone else steering where Lunch Money went. Without the pressure to grow explosively, without a flood of users she could not handle, she could build something meant to last.

She never burned money on ads to buy her way to users. That slow early growth is exactly what let her build the product her ideal user wanted.

The moment you raise, you add stakeholders and shareholders, and you hand away some of the freedom you thought you were keeping. But not everyone can make that choice.

Family depending on you, thin savings, no way to relocate somewhere cheap, no room left to cut. Sometimes you genuinely need the money, and raising is the only door open.

So if you do have to raise, the whole game becomes who you raise from. Find angels or investors who care about the problem as much as you do, who want the same pace you want. Be picky to the point of rude. Because you should raise from the people who will protect your direction, not seize it.

Saying no to investors was the easy part. Whether anyone would ever find her app was still an open question.

Subscribe now

Fifty To A Thousand Overnight

So how did she get people in the door?

“It was definitely luck and a lot of grit and just not giving up on getting your product out there.”

Most founders who tell you their early-traction story have quietly forgotten, or are too modest to mention, the grind sitting underneath it. Jen had a couple hundred people following her on Twitter. She had friends and family. But she kept posting about the app anywhere she could, over and over, while she sharpened it with the handful of people already using it.

And she had the one thing most founders spend years hunting for. She knew exactly who Lunch Money was for, because it was for her!

She had spent a year and a half tracking her own spending in a spreadsheet, so she was user number one, and finding fifty more people who lived like her was not a mystery. She knew where they were and how to get them.

Then one day she posted it on Hacker News. It sat on the front page for twenty-four hours, and her signups jumped from about fifty to a thousand overnight, along with a flood of emails from strangers asking whether she would build this feature or that one.

That kind of luck is manufactured. You try a thousand small things so one of them can catch, and you keep showing up long enough to be standing there when it does.

But luck does not explain the seven years since.

The Advantage She Barely Names

Ask Jen what she made that nobody could copy and she does not name a feature. She points to the sum of everything she has done, a post-seed startup, a company through its IPO, Y Combinator’s Fellowship, 500 Startups, years of freelancing for teams from seed-stage to the Fortune 500. She had to try all the versions she did not enjoy before she landed, with real conviction, on bootstrapping her own startup.

Her actual edge comes down to two smaller things she barely flags: insane clarity on her ideal users and focus.

Jen does not get pulled off course. She breaks a feature into must-haves and nice-to-haves, works the list like someone is squeezing a shampoo bottle to get the last drop, and she does not think ten steps ahead.

“I see life like a video game where you’re in this map, and the map is not discovered yet. And when you take one step forward, the next few tiles in front of you reveal themselves.”

You do not plan monetization for a side project that does not exist yet. You take the next step and see what it shows you. She stayed focused because focus was all she had.

This is the beat where I have my own scar tissues. Because my mistake was the exact inverse. I thought ten steps ahead, and it pulled me in ten directions, when I should have doubled down on the handful of users already there, already asking me for more.

If, like me, focus does not come naturally to you, here is the exercise. Talk to your users from day one, no matter how rough the product feels. People do not use things because they look nice, they use them because the thing solves their problem, so listen for what they want more of and less of and let that draw the map. And if you have nobody to think it through with, transcribe every user call, feed it to Claude, and ask it where you are fooling yourself, what you are assuming, and what you cannot see.

That is a good fix for the solo echo chamber, the one where your signal is clean but your read on it is not.

Subscribe now

What She’d Tell You

Her advice for the founder coming up behind her is a very simple philosophy: just take the next step.

Do not dream about what you will do at a thousand users. Do not make your product scale before there is anyone to scale it for. Do the things that do not scale. Show up places. Talk to people.

“Enjoy the process. It really does go by quickly. Don’t get too attached to the way things are today. Being adaptable is the most important thing in business.”

Two years ago AI was not a factor, and now she has rebuilt whole strategies around it. She has no idea what reshuffles everything next. Neither do you.

What stays with me is where she started. A burnt-out engineer who gave up on startups, and then built one on terms she would never trade.

The map only ever showed her the next tile, and she just kept taking the step.

She has started sharing that journey on Instagram and you must follow her!

Thank you for reading all the way here. This is the first interview. Starting with the 3rd interview, paid subscribers get the founder’s full playbook: the exact tools, numbers, and systems behind the story.

If it’s time to stop building alone, Table For One is a small community where solo founders connect and trade notes with people doing the exact same hard thing. Message me and I will send you the way in!

And if this piece hit something in you, tell me your story.

There were twelve of us, and we went around the table saying what we were building. Health tech. Bio tech. Someone making agents for lawyers. Someone in fintech. Then me, a nontechnical solo founder in fashion tech.

This was early 2025, back when fashion tech did not mean tech in San Francisco. So when I said it, someone across from me asked, “oh, like an app for your outfits?” I explained the real thing, a smart marketplace for the unsold inventory that brands sit on. I could see I had already lost the room. Everyone was politely waiting for me to finish so the introductions could move on.

A few weeks later I walked into a fashion tech meetup and the whole temperature changed. People asked real questions. They got excited about what everyone else was building. Same at the women founder events, same anywhere full of people who had also spent time in the group the mainstream overlooked. The interest was quiet and it was real, and it showed up wherever I was surrounded by people who knew exactly what that first night had felt like.

For a long time I let the wrong opinions win. I started believing the version of me that the dinner table had ignored. It cost me more than I knew at the time.

Subscribe now

The Permission Tax

The apology came due in three installments.

The first was saying yes to the wrong cofounder. I spent months hunting for someone to build with, mostly because I could not stand the thought of saying the words “solo founder” out loud one more time. By the time the fifteenth conversation turned into a yes, I took it, even though I already knew this person did not want the problem the way I wanted it. I stayed far longer than I should have, because starting over felt worse than living with the misalignment. It cost me months I did not get back.

The second was hiring too soon. Solo among cofounded startups, I wanted to look credible, so I hired before I had a system that needed the help. I filled the roles a “real” company was supposed to have, not the ones the actual work was asking for next. I was building a team to be seen with instead of a team the product needed.

The third was waiting too long to ship. I kept the product to myself because I did not want to put a half-finished thing in front of people who already thought the idea was small. I wanted it a little more polished, a little more defensible, before anyone saw it. That instinct cost me months of feedback I could have had, users I could have learned from, and a run of decisions I made alone because I was too scared of what the louder voices would say.

What’s Different Now

Every one of those mistakes came from the same place. I cared too much about how I came across to people who had already made up their minds. The wrong cofounder, the hires I did not need, the product I sat on. Each one was a way of asking permission from people who were not even paying attention.

Here is the part I wish I had understood sooner. The idea that got filed under “app for outfits” at that dinner was the same idea that later landed in the top 24 of more than 10,000 applicants worldwide for eBay’s Circular Fashion Fund. The lesson is not that “see, eBay agreed.” The lesson is that I shouldn’t have let the opinions of the least curious person have any effect on me.

And so much has changed in just over a year. If you are building without a technical background today, you are not doing it alone. The vibe coding community is bigger than it was a year ago and still growing, and there are more nontechnical founders shipping real products than at any point I can remember. The tools got better. The people got friendlier.

Fashion tech got its moment too. The category that earned me a confused question at that dinner now has Phia and Daydream and a dozen others, and the same people who once filed it under shopping are chasing it.

The people who waved me off were never the ones who got to decide whether the thing was worth building. I just did not know that yet.

Subscribe now

Build Anyway

So here is the only line I actually want you to keep. You do not need anyone’s permission to build.

If you do not know the industry yet, that is fine. Reach out to the people who do. In my experience someone will almost always give you fifteen minutes, and fifteen honest minutes are worth more than a year of guessing.

If you are not technical, there are hundreds of tools now that will carry you at least to the next step. You can sit down with Claude Code on a Saturday and have a rough MVP in front of a real customer by Sunday. Something real beats something perfect every single time.

If you are solo, I know how heavy that word lands when everyone around you has a cofounder. But you will find your people. You will find a team, and if you want them, you will find cofounders too. None of that has to be solved before you start.

The one thing I do not want, at any point in this, is for you to feel alone. You are not. Remember the people who actually leaned in and asked the real questions. That kind of room exists for you too. You just have to find it.

That is the whole reason Table For One exists. It is a community for solo founders where the connections are real and helping each other out is the baseline, not the favor. If that sounds like what you have been looking for, come pull up a chair.

And if walking into even a friendly crowd still feels like too much, start smaller. Message me. I will give you fifteen minutes, at the very least to hear you rant.

If you are building something that feels too early or too niche or just outside the mainstream, reply and tell me what it is. I read every one. And if you know a solo founder, share this with them.

Share

So for three weeks I ran an automated outreach sequence I had built myself. It wrote and sent cold messages on my behalf while I was doing something else. I personalized every variable I could. The name and the company obviously. But the two that I was proud of were a line pulled from their latest post and a line about something we had in common, the details that are supposed to make a cold message feel handpicked. I sent at least a hundred of them and I got ZERO replies.

Then one afternoon I closed the tool and wrote a single message by hand. It was a little long. It was just me explaining who I was and what Shezaar was actually for, personalized less to the brand than to what I wanted them to understand about me. I sent it to ten brands and left a real comment on each of their posts. By the next morning, four of them had written back.

That gap is the whole point of this piece. When you are on your own, automation feels like the sane response to a workload that has no bottom. But what it actually buys you is a wall between yourself and the only people who can tell you the truth about your product.

Why Automation Feels Like Progress

You just shipped an MVP, and the next step, actually talking to customers, is slow and terrifying. Being solo makes it heavier, because every job on the list is your job, and automating all of it can feel like the only way to stay above water. So you reach for AI to fill the silence. I did the same thing.

The appeal is that it looks like motion. You point a tool at a few thousand people, the sent count climbs, and from the outside it reads like reach. What you have actually bought is distance from every single one of them.

The trouble is that at this stage the most valuable thing you own is friction. Every bug report, every confused question, every “I would use this if it did X” is the raw material you need to find the version of the product that actually sells. Automate that layer away too early and you get a quiet inbox and a product that drifts further from anyone who would pay for it.

Subscribe now

Where Founders Get It Wrong

Most of the premature automation I see clusters into five moves, and I have made at least three of them myself.

Automating support before you have users. Founders deploy an AI chatbot so they never have to sit in a live conversation with a confused customer. At the MVP stage that conversation is the asset, not the chore. The customer would rather reach a human anyway, and that one unscaled exchange is where relationships are built. You are trading your clearest signal for a reply speed nobody asked for.

Building the pipeline instead of shipping the product. Founders who can code are the worst here. You spend a week building an automated onboarding flow that tags every new signup, drops them into a database, and fires off a welcome sequence, when you have eleven signups you could read by hand in an afternoon. The build feels like progress because it might be hard to do. But you are smoothing a path before you know whether anyone wants to walk down it. And every step you just automated is one more thing you will have to maintain and unpick later, when the product changes!

Blasting automated outreach. I showed you my version of this already. The part I missed at the time is that the personalization was never the problem. A message can carry your name, your company, and a line about your last post and still land as exactly what it is, one cold note out of a thousand. People can smell an AI-written message from a mile away, and the early adopters you most want are the fastest to catch it. What makes someone write back is knowing you picked them on purpose, and a tool working down a list cannot give them that, no matter how “personalized” it feels.

Letting AI write the roadmap. It is easy to paste your early feedback into an LLM and ask what to build next, and what comes back looks orderly and convincing. But a model can only rearrange what is already sitting in the feedback. It will hand you the safe average of what everyone asked for, which ends up being the exact version of your product that competes with everyone else’s. Because remember, most of the times, your customers do not know what they want. The one call no model can make for you is which uncomfortable, specific bet your customers need.

Automating a craft before you have done it once. It is tempting to buy the AI video editor or the AI copywriter before you have made a single video or written a single post by hand. The problem is that you cannot judge what it gives back. If you have never cut a video yourself, you cannot tell whether the automated one is good or just fast, so you ship generic work without ever knowing it is generic. Do it badly by hand at least once. That is what earns you the right to hand it off.

The Rule Of Thumb

The fix is not to swear off automation. It is to automate on a schedule the business earns, not one your anxiety sets. For the customer-facing work, that schedule looks like this.

• First 10 customers: Everything by hand. Talk to every user. Write every onboarding email yourself.

• Next 50 customers: Automate friction only. Reach for a basic tool when a manual task costs more than five hours a week.

• 100+ customers: Scale with AI. Automated support, real data pipelines, programmatic growth. Maybe hire someone.

Notice that nothing in the first column is clever. It is supposed to feel slow and unscalable, because that slowness is what keeps you close enough to hear what the product is missing.

For everything else on this list, the roadmap, the outreach, the video edit, the same two questions decide it.

1. Have you done this by hand enough to recognize a bad result when the tool hands you one?

2. Is it the biggest thing eating your week right now?

If the answer to either is no, you have not earned the automation yet.

Subscribe now

The One Thing To Do This Week

Pick the one task you have automated that sits closest to a customer, your chatbot or your outreach tool, and turn it off for a week. Do that job by hand instead, slowly and a little badly. Watch what comes back.

When I turned mine off, five brands replied in a day after a hundred automated messages had gotten me nothing. The automation was not saving me time. It was charging me the one thing a new product cannot afford to lose, which is contact with the people it was built for.

If this hit a nerve, reply and tell me the one thing you automated too early.

• I Hired Nine People And Fired Four Of Them

• Permission To Quit

• Trying To Be Everywhere Is Why You’re Nowhere

So here is the clarity I owe them. Over the year and a half I spent building Shezaar, I hired nine people and let four of them go.

Why The Advice Fails

The standard advice splits into two camps that both sound right. Hire slow, protect your culture, wait for the right person. Or hire the most talented person you can afford and move fast. Founders pick the camp that matches their current stage and then feel principled about it.

Neither camp tells you what you are actually screening for. When I let someone go at Shezaar, it was almost never because they could not do the job.

My first three hires were a content creator, a full-stack engineer, and an intern to help me run day-to-day operations. That was what I thought I needed help with. All three were capable. I let all three go inside a couple of months, and I lost real time and real money doing it.

The problem was not them. The problem was that I hired for the job I assumed I had instead of the one I actually had.

I needed someone editing my content, not producing more of it. I did not need a full-stack engineer, because I had taught myself to vibe code in a few days and I wanted to focus more on defining the product. And I did not need an operations hire either. I needed to prioritize my goals so that most of the “operational tasks” simply disappeared. I had gone looking for hands before I knew what the work actually was.

Three capable people, gone, because I treated hiring as the answer to a question I had not finished asking.

Gate, Then Dial

The five people I hired after that were the best I have worked with. The first thing I changed was the order of operations.

Before I wrote a single job description the second time, I automated everything that could be automated and systematized everything that could not. I only went looking for a person once I knew exactly which part of the work could not be handed to a tool or a process. And just like that, hiring became the last step instead of the first.

Then I changed what I screened for. I started treating culture as a gate and skill as a dial. A gate is pass or fail. Either someone is honest when something breaks, takes ownership without being asked, and works the way the team actually works, or they do not, and no amount of talent teaches them culture.

A dial is a question of degree. How senior, how fast, and how polished. You only reach for the dial once someone has cleared the gate.

I made the process slower and less flattering to match. Most senior people do not want to work at a two-person startup, and plenty of them cannot, because not everyone can hold that much ambiguity at once. So I screened for it directly. I made the interview longer. I added a video round. I ran at least two conversations, and for the technical roles I had the candidates do a small piece of real work before any offer went out.

Once I built the system first and knew what I did not want, I finally hired the team I should have been looking for all along.

Skill Can Be Taught

The reason gate-then-dial works is asymmetry. Skill is teachable. Culture is not.

You can teach someone your stack, your process, your customer, your way of doing things. People grow into roles all the time, and watching it happen is one of the real joys of building something.

What you cannot do is retrofit values into an adult who does not share them. You cannot coach someone into caring about what you care about, or into treating a fragile early team the way it needs to be treated.

This is why treating Skill and Culture as if they have an equal weight is the most expensive mistake you can make. You meet someone with obvious skill and a couple of quiet warning signs, and you let the skill pull the average up past your bar.

A brilliant hire who corrodes how your team works is not a net positive with an asterisk. They are a cost you pay a premium for.

None of this, though, is what sank my first three hires. Those were not gate failures. They cleared on character. I simply had not built the right things for them to do yet.

The order problem and the gate problem are two different problems, and I managed to make both.

The Rule I Broke

That fourth one that I had to let go is the part I am least proud of. It was a mistake I made knowingly.

Mid way in the lifecycle, the product hit a bottleneck only an ML engineer could clear. I had the occasional help but this time I need someone full-time. I interviewed at least twenty of them and I found one inside my budget, which at our stage was close to a miracle. He was the most skilled person I talked to for that role. He was also, clearly, not a fit for the team, and I knew it in the first interview.

I hired him anyway. The product could not wait, and I told myself the work was worth the risk. I had a whole framework for this exact mistake. I had just screened four people through it. But I was desperate.

Three weeks in, that one hire had nearly single-handedly dismantled the culture of ownership the rest of us had spent months building. Nothing dramatic. Just the steady friction of someone excellent at the job and wrong for the room. That friction was teaching everyone around him to stop caring too.

Knowing the “framework” of gate and dial did not save me.

I broke it the moment someone was skilled enough, on a week scary enough, to make me want to.

Some Rules Are Not Meant To Be Broken

Before you hire anyone, automate the thing that hire is meant to run and systematize everything around it. Hiring is the last step, not the first. When you finally do go looking for a person, you want to be filling a real gap, not buying yourself the feeling of progress.

And the moment you decide to hire, write your gate down before you ever write a job description. Three or four non-negotiables about how a person operates, not what they can do.

For me they were are they honesty when something breaks? Do they have a sense of ownership nobody had to ask for? Can they work with the specific way my team works with each other?

And no matter what, you do not let skill, however dazzling, talk you into ignoring your non-negotiables. Cause believe me, the most talented person you ever interview will be the one who tests this, usually on the week you can least afford to hold down the fort.

Hold it anyway.

It cost me three months and a lot of money to learn this. Hopefully you won’t be needing that.

If you have made a hire you regretted, reply and tell me what you missed.

Then I burned out and stopped everything for a month.

The distribution problem for solo founders is not that we do not know social media presence matters. We know it does. The problem is that there is no reliable way to figure out which channel is worth the specific hours, given our voice and audience and what we want to accomplish.

So we pick based on what other founders are doing, or what we last read about, or where we feel most comfortable posting. To find out whether it was the right call only after six months.

So, naturally I built something to help with this. Channel Scout is a six-skill pipeline that does what a “distribution consultant” or “GTM consultant” (if they exist) does, running locally on your Claude Pro or Max subscription with no API keys and no extra cost.

Here are the only two commands:

/channel-scout is the full strategy session. This is what you run the first time. It interviews you, scans your competitors, selects a channel, designs kill criteria, tests post drafts. So that by the end, you have two channels to bet on and a metric that tells you when something is not working out.

/channel-scout coach is the daily run. One coaching note, one dashboard refresh, one check of your kill criteria. Runs automatically if you want, or can be triggered manually.

Before You Start

This is built for Claude Code, so you need a Pro or Max plan. If you have never used Claude Code before, the install takes about five minutes and there are tutorial links in the README.

Subscribe now

How It Works

The first time you run /channel-scout, five skills fire in sequence. The full session runs under 90 minutes, with natural stopping points if you need to break. If you stop mid-way, running /channel-scout again picks up exactly where you left off.

These are the five skills:

ONBOARD interviews you, asking what you are building, who it is for, your three closest competitors, how many hours per week you can give to distribution, and what channels you have already tried. While you answer, it fetches your information and homepage in the background to create specific search parameters, ICP descriptors, and competitor feed. By the end of the interview, Channel Scout knows your constraints.

SCAN uses those parameters to fetch competitor information and find three to five channels that would work for you. For each channel it identifies, it extracts the winning content template: the hook pattern that gets traction on that platform, the typical post length, the posting cadence that works. It rates each channel on audience saturation, content gap, and ICP fit.

PREDICT is the part I found hardest to build manually. It scores voice fit for each channel, meaning how much rewriting your natural writing style would need to work on that platform. Then it runs something I called a wind tunnel: three synthetic personas built from real top-performing post language on each channel. Your angle goes through all three.

Channels that would require more weekly hours than you said you have get penalized. At the end, PREDICT picks two channels and writes the full reasoning to a prediction file you can read, question, and push back on.

PROBE drafts two native test posts per channel in your voice, sets your posting cadence from the intel data, and writes kill criteria. Not “give it three months and see.” Specific numbers. If LinkedIn impressions stay below 180 after seven posts, stop. You agree to that number before the first post goes out.

COACH runs every morning, reading a rolling context stack: not your full history, just your scorecard, yesterday’s summary, and the most recent weekly synthesis. It checks your kill criteria, writes one coaching note, and regenerates your dashboard, opening it automatically.

The Number That Matters

The problem was not that I picked the wrong channels. I picked five channels at once, had no criteria for any of them, and burned out before a single one could tell me anything useful. Had I run some experiment like Channel Scout first, it would have surfaced two channels worth betting on and given me a number to watch after the first post went out. It would have told me that given my ICP, my strongest channels were Substack and Reddit.

That is the piece I would have wanted before I opened a TikTok account in 2025.

Now this is not a content system and I am building an individual system for each channel. But those will work only after you have identified the right channels for you.

How To Install It

Two commands in Claude Code:

/plugin marketplace add DM1195/tableforone-channel-scout
/plugin install channel-scout@tableforone-channel-scout

Then type:

/channel-scout

Channel Scout asks for your company name, creates a folder at ~/channel-scout/[your-company]/, and starts the ONBOARD interview. Answer in plain English. Ten minutes in you will have a profile and a watchlist. By end of session you will have two channels to test, two draft posts per channel in your voice, and a kill criteria number for each.

All files live locally. Nothing is sent anywhere. Nothing expires.

The Daily Coach

At the end of your first session, you choose how the daily run works.

Automatic registers a launchd task on Mac or a crontab on Linux that fires at your chosen time. If your laptop was asleep, it runs when you open it.

On open adds a SessionStart hook to your Claude Code settings so the coaching run starts every time you open Claude Code.

Manual means you run /channel-scout coach yourself.

The coaching note is short. Post performance against kill criteria. What shifted in the competitor feeds overnight, if anything changed. One specific recommendation for today.

The dashboard is a static HTML file Channel Scout regenerates after every coach run: scorecard table, today’s note, competitor activity, kill criteria status in one page.

Channel Scout does not read your full post history every morning. It reads the rolling stack, and competitor feeds only get fetched if something actually changed since the last run. That is token discipline built into the design. A daily process should not become an expensive one.

What I’d Do Differently

I tried to make the PREDICT output final. Two channels, full reasoning, done. But the wind tunnel results surprised me often enough that I wanted to be able to push back on the picks. The tool now writes the full reasoning to prediction.md, and if you run /channel-scout again and tell it you want to revisit a pick, it re-runs PROBE with adjusted parameters instead of just confirming the first output.

I wish I had designed for that iteration loop from the start. The first version assumed the model would always surface the same two obvious channels. It does not, and the divergence cases are often the more interesting ones.

If the channel picks surprise you, or something breaks on your setup, reply and tell me what it gave you.

Durva

• Vibe Coding Lab #2: The Tool To Help You Visualize Your Product

• Vibe Coding Lab #1: The Morning Brief To Make You 10x Smarter

  ---

You know the feeling. You are trying to put in consistent effort on Instagram and LinkedIn and Substack. There is a LinkedIn post half written in one tab, a video you filmed two days ago and still have not edited, a newsletter draft you keep meaning to finish, and a quiet promise that this is the week you finally crack Twitter.

You try to post every day but miss a few. You try to engage with the right accounts. You are doing everything you can on top of building the product and talking to users and everything else you have to do.

You are showing up on multiple platforms and growing on none of them.

I spent six months in this hell hole with my last startup. But there is a way to get out of it in an afternoon.

"Try Everything" Is Wrong

“Try every channel, see what works, double down on the winner.” You have heard it a hundred times. After all, how will you pick a winner without testing it out? If I got a dollar every time someone told me this, I would have raised enough to fund one more month of Shezaar.

This advice assumes you have the hours to run a real experiment on each one.

You don’t.

With the time you actually have, you cannot run a real experiment the way experiments are supposed to be run. You can only run a few half-hearted ones at once, and you will end up pouring weeks into the wrong platform before you ever find out.

Take Table for One. I have posted on this Substack consistently since 1 May 2026. It took me 47 days to reach 101 subscribers.

That was at least five notes a day and two articles a week. I took a one week break in the middle and Substack punished me for it by tanking my views. In terms of effort, this is 20 to 25 hours a week, counting ideation, research, editing, scheduling, and engaging with other people on the platform.

There is no way I could have put in that same effort on LinkedIn at the same time.

But did I pick Substack because I love to write? No. I picked it for three specific reasons. It is where the audience I want lives. It builds my creativity, so I can sustain it. And in my niche it is not as saturated as LinkedIn. Hold on to those three reasons, because they are not luck.

I Guessed Wrong, And It Cost Me Months

I was not careful about picking the right platform for Shezaar, my last startup, and it was brutal. I was trying to grow on Instagram, TikTok, Substack, Reddit, and the occasional LinkedIn post. I could barely make a dent, and I was exhausted and burnt out.

I also assumed my users would come from Instagram and TikTok, so that is where most of my hours went. Scripting, shooting, editing video.

The users came from Substack and Reddit.

Obvious in hindsight. The people I was building for were researchers at heart. They lived in long newsletters and deep Reddit threads, not fifteen second videos. I burned weeks making content for people who were never going to buy. I was confident in my gut, and my gut was wrong.

That is when I learned nobody can afford to find this out the slow way. So do not experiment. Diagnose.

Finding The Right Channel In An Afternoon

Before you commit a single week to a channel, run this. Three checks, scored 0 to 3 each. Add them up. Do it for every channel you are weighing. You spend an afternoon instead of 6 months, and the highest score is where you go. These are the same three reasons I picked Substack.

Check 1: Are your people actually here, right now?

Take the exact words your customers use for their problem. If you do not have those words yet, stop and go get them.

Now search those words on the platform, filtered to the last 30 days.

• LinkedIn: search the phrase, filter to recent posts.

• Reddit: search the two or three subreddits where that problem lives.

• Substack: search Notes and publications for the topic.

• Instagram or TikTok: search the hashtag plus the problem.

Expected output: a wall of recent posts from real people with this exact problem, or a ghost town. Score 3 if it is busy and recent. Score 0 if it is dead.

Check 2: Is anyone like you already winning here?

Look for two signals at once. First, is anyone adjacent to you already getting real traction, meaning comments and replies, not just likes? That proves the channel works for your kind of thing. Second, is your specific angle still open, or is every version of your take already being shouted by a hundred bigger accounts?

Expected output: proof that people like you can win, plus a gap you can actually fill. Score 3 if both are true. Score 0 if no one wins here, or if your niche is wall to wall noise.

Check 3: Can you sustain what this place rewards?

Every channel pays out for one kind of effort. Be honest about whether it is the kind you can do every week for months.

• LinkedIn rewards written stories and operator lessons.

• Reddit rewards genuine help and zero selling.

• TikTok and Instagram reward video, your face, and a hook in two seconds.

• Substack rewards writing and a real point of view.

Expected output: an honest yes or no on producing that format weekly without dreading it. Score 3 if it fits you. Score 0 if you will quit in a month.

Add the three. The channel with the highest total is your one. Start there. Ignore the rest until it is working.

Build A Strategy Before Selecting A Channel

Your scores tell you which channels are alive and winnable. They do not tell you which one to aim at, because the channel that is perfect for finding customers will be useless for finding investors.

So before you choose, answer two more things. Those two answers, sitting on top of your three scores, are the five inputs that decide your channel.

Who are you trying to reach?

As a solo founder you are not chasing one audience. You have five goals: customers, investors, your next hire, partners, and authority, the slow thing that makes the other four easier. A channel serves some of them and not others, depending on who lives there. This is also where most founders aim at the wrong target, by choosing channels by business model. B2B goes on LinkedIn, B2C goes on Instagram. Wrong axis. LinkedIn is not the B2B channel. It is where professionals go to pay attention. If you are B2C it is probably not your customers, but it is your investors, your next hire, and your partners. If you are B2B it might be all five. Decide which goal is most urgent right now, and score channels for that audience.

What outcome do you actually want?

Name the one action you want from the people you reach. An email signup. A reply to your DM. A warm intro. A booked demo. The outcome you pick decides what winning even looks like on a channel, and it forces a split most founders skip. You need one channel where a stranger finds you, and one where they go deeper once they like you. Discovery, and depth. For Shezaar mine started offline, sixty in person conversations that scaled to nothing but taught me everything. Offline cannot run while you sleep, so it seeds your voice and your first believers. Your one online channel scales the voice you found there.

Run the three checks. Answer those two questions. The five together point at one channel, and now you have a strategy instead of a guess.

Play The Long Game

Know going in that you will most likely not go viral in your first six months, and you should not aim for it. The job after picking your channel is to build slow compounding growth and to learn as much from what flops as from what lands.

As I grow on Substack, I track the platform closely, and I study what is working for other people too. I got tired of doing all of that by hand, so I built a tool that does it for me. It watches the platforms you are weighing, tracks where your specific content and your specific people actually get traction, and by day seven tells you which one to commit to. This open sourced tool drops this Friday, as the next Vibe Coding Lab.

Until then, close four of those tabs and run the channel check.

And remember, consistently putting 20 to 25 hours into one or two channels with a strategy beats half-assed posts on many, every single time.

At first I could not believe it. I read it twice. I thought for sure this was a mistake. Or maybe this was a spam email. But when the self-doubt settled, I was elated.

Two weeks of pitch prep and an amazing pitch later, I was not selected for the top eight. But, in a weird way, I was relieved.

Resilience Is Overrated

The cultural norm is that winners never quit and quitters never win, so we celebrate resilience and shame quitting. But most of the unhappiness, wasted years, stalled careers, and lost money come from people staying in losing positions long past the point where it stopped making sense.

I come from a third-generation family business. So, naturally I have a HUGE chip on my shoulder. I feel the constant need to prove myself and to seek external validation. Which is why quitting was never on the table.

So when the logic started showing me what I did not want to hear, I chose to ignore it. My fear of personal failure was far greater than the logic to just stop and salvage what I had. I told myself the answer was to work harder. So I worked harder. I worked through the holidays. I worked every weekend. But, had I tried to be objective, I would have made better decisions.

The Things I Was Refusing To See

There were three main issues, and they had been there from the start.

I did not love the industry. I did not love fashion. I loved the problem of textile waste. The two are not the same thing, and I had spent a year telling myself they were. Which meant I wasn’t the right person to solve the problem.

Every other fashion-tech founder I met could pitch their company using the latest styles, revered brands, and runway designers. Mine had a tone of “save these clothes.” I could not tell you the difference between Doên and Réalisation Par. But to kill the problem of waste, I had to sell fashion. To sell fashion, I had to understand it. And that was my biggest weakness.

The problem was real, but it was not urgent. Brands were managing their deadstock with patchwork solutions that worked well enough. There was no hair-on-fire moment yet. When the alternative is “deal with it later,” even a good solution loses to inertia.

And the last one: my customers, the shoppers, were spoilt for choice. The kind of buyer I was building for had thirty resale apps on her phone already. So, getting her attention required either viral organic momentum or a paid marketing budget. Without either, the unit economics did not make sense.

Now these might seem like surface-level problems that could have been solved by just being smart and scrappy. However, there were mistakes that I made along the way that made solving these nearly impossible. And I will post about them too.

The Strength To Kill

Sometime in the middle of that year, I had coffee with another founder. She was building her own thing, completely different from Shezaar, and at one point she said, casually, that if she did not hit a hundred paying customers in three months, she was quitting.

I remember thinking that was a horrible way to think about building a startup. How could you be committed to something if you had already imagined the version where you walked away?

But, I get it now. She had what Annie Duke calls kill criteria. Criteria that probably saved her a lot of time and money.

Annie Duke in her book Quit says that we quit too late, not too early. Grit and quit are not opposites. They are complementary skills, and most of us are great at one and terrible at the other.

The question is never “should I push through” versus “should I walk away.” The question is “is this still worth pushing through, given what I know now?” If your honest answer is yes, grit. If your honest answer is no, quit.

The reason this is hard is that your biases lie to you about the answer. The loudest one is sunk cost, telling you that you have come too far to stop. Underneath that is identity, telling you that founders do not quit. And the most seductive of all is optimism, telling you that next quarter the metrics turn.

So, having kill criteria does not mean you are not committed. It means you have given yourself the option to do something else if the evidence stops supporting the bet. And the criteria do not have to be about money. A hundred paying customers did not happen, but a thousand downloads did? That still works.

I walked out of that coffee shop thinking she was being defeatist. I had no kill criteria for Shezaar. I had a dream and a chip on my shoulder. So when the evidence started saying no, I had no agreement with myself about what no even looked like. So I just kept going.

What The Months Cost Me

Staying too long does not just cost you money. It costs you in ways that take longer to count. The people you stopped calling. The holidays you spent at your laptop instead of at the table. The body that kept score while you ignored it. The work you would have done if you had said no a quarter earlier and used those three months for something honest.

Most of what I lost was not the money. It was the months between knowing and saying.

What I Am Building Now

I quit Shezaar four months ago. I have spent the time since writing about my experience, building a network, and pitching half-baked ideas. I do not yet know what I am going to build next. But I know it will not start the way Shezaar did, with a build-first mentality.

And sometime soon I will write about the mistakes I made building Shezaar, mapped to the structural choices I am making this time so I do not make them again.

I have felt extremely embarrassed sharing this part of my story. But I am sharing it anyway.

For now, if you are reading this and you have evidence that is telling you to do something else or pivot, believe that evidence. And the smartest thing you can do for your future self is to decide what your kill criteria look like before you need them.

So you’re three hours deep asking Claude to “find the issue” and it’s finding things, but none of them are the actual thing.

I’ve been there.

When you vibe-code, the AI builds fast and you ship faster. Somewhere in between, the code outpaces your understanding of it. The logic exists, but it exists in the AI’s “head”, not yours. So when something breaks, you can’t point to what or where. You grep through files. You ask Claude for help without being specific. You’re scared to delete anything because you don’t know what depends on it.

That’s not a skill issue. That’s a visibility issue.

Sprintt is the agent library I’m building for solo founders. It has 127 functions and 42 dependencies across 28 features. I built every one with Claude. Until last week, I couldn’t tell you what most of them did. I was exactly where you are.

So I built a tool that shows you what’s there.

Skip Explanation And Get The Prompts

Overview Of The Skill: What It Does

This simple and free claude skill helps you visualize your vibe-coded product and identify the gaps you could have missed. Point it at any project folder. A browser tab opens with three views of your codebase: three different ways of looking at the same code, depending on what you’re trying to figure out.

App Flow:

Three columns: pages on the left, database tables in the middle, external services and API routes on the right. Pages are grouped by URL section: all your /admin/* pages together, all your /onboarding/* together etc. Each page is a card you can expand to see the components inside it. Each component shows what data it queries, where it navigates, what server actions it calls. Arrows connect components to the specific tables and services they touch.

Constellation:

Same data, radial layout. Four concentric rings: pages on the outside, then API routes, then database tables, external services at the center. Routes and tables don’t sit randomly. They gravitate toward the pages that use them. If your agents table is read by both dashboard and admin pages, it floats between those sections. The layout shows you something no file tree does: how siloed or shared each resource actually is.

Function Map:

Every function in the codebase as a block, grouped by file. Click one to see what calls it and what it calls. Dead code flagged. Linter issues surfaced. Claude writes a plain-English explanation of what each function does, and if it has bugs, generates a ready-to-paste fix prompt for Cursor. This is the deep-dive view for when something’s broken and you need to actually trace it.

Two toggles work across the views:

• Heatmap. Colors nodes by connection count. Tables go blue for reads, red for writes. Pages get more saturated the more routes call them. Lets you see at a glance which tables are your hottest and which pages are doing the most work.

• Orphans. Highlights anything with zero connections. A page no route leads to. A table nothing reads. A service nothing imports. Orphan doesn’t always mean broken. Sometimes the connection is dynamic, sometimes the analyzer missed it. But now you have something specific to investigate instead of a vague sense that something’s off.

Your code never leaves your machine.

How To Get It Running

Two ways. Pick one.

The Fast Way (1 Minute)

If you have Claude Code installed and don’t mind downloading from my free GitHub repo, paste these two commands:

/plugin marketplace add DM1195/tableforone-codebase-visualizer
/plugin install codebase-visualizer@tableforone-codebase-visualizer

Then in any project, ask Claude Code: “map my codebase” and point it to a folder.

Build It Yourself

If you’d rather build it yourself, or customize it for your stack, it’s five prompts run in sequence in Claude Code, about 30 to 45 minutes. The prompts produce the function-level analyzer, the app flow parser, the visualization, the constellation layout, and the skill wrapper that orchestrates it all.

The full prompts, the design constraints, and the gotchas are in this doc. One thing to note: don’t paste all five at once. Run each, see what you get, fix what’s off, then move on.

The plugin is open source. Repo here. The doc has the full setup, all five prompts, and a few features I cut from this post for length.

Get The Prompts

What This Is Really About

The work isn’t writing code anymore. The work is seeing what you built.

Once you’ve shipped something you can’t see inside, your options narrow fast: abandon it, or rebuild it from scratch. Most founders pick one of those after losing weeks. The hope is that now you don’t have to.

If something doesn’t work, send me a message. Wrong stack, missing feature, broken on your setup, whatever it is. I’d rather know than have you hit a wall and give up on it.

And if you’re a solo founder trying to figure out how to build and ship without a team behind you, Table For One is where I write. The tools, the decisions, the mistakes, written specifically for people building solo. Free to subscribe.

- Durva

Subscribe now

The price tag on the fridge.

I have admired those model kitchens a dozen times. I always assumed the fridge was staging, like the fake fruit in the bowl. It had never occurred to me that IKEA would actually be selling them.

So I did a little digging and here are the facts.

• IKEA doesn't manufacture refrigerators. The fridge in the box is made by Whirlpool, Frigidaire, or Midea, depending on the model.

• It isn't the cheapest fridge. It falls somewhere in the middle of the price range.

• The reviews are mixed. Service complaints are common. Replacement parts can be a pain because the units are custom-specced.

And yet people buy it. A lot of them.

Which left me with one question…

Why Does Anyone Buy This Fridge?

IKEA is not an appliance company. They don’t manufacture compressors or cooling coils. They’re a furniture company with €44.6 billion in global retail sales.

The reason they sell fridges, or any appliance for that matter, is simply because they sell cabinets.

Sounds weird? Let me explain.

Every customer who buys IKEA’s modular kitchen ends up needing appliances. And most third-party appliances don’t fit. The fridges are too deep. The microwaves are the wrong color. The dishwashers stick out past the countertop. They basically ruin the Scandinavian look the customer just spent three hours planning.

That’s the friction. And IKEA stepped into it.

They partnered with Whirlpool, Frigidaire, and Midea. Specced units to the exact dimensions of the modular kitchen. Extended a five-year warranty, four years longer than what those manufacturers offer direct. And dropped it into step 4 of the kitchen planner, right between picking your cabinet doors and checking out.

The customer who came in for cabinets ends up clicking “add fridge” without thinking. They don’t comparison shop. They don’t measure twice. They don’t worry about the warranty.

IKEA pre-solved all of it.

The Playbook, Mapped

The move has three parts. Clean enough to replicate.

Have an anchor.

A core product that’s the reason the customer is in the room. For IKEA, it’s the kitchen.

Identify the friction.

What's the next thing the customer has to figure out right before or after they buy the anchor? Not next year. The next 48 hours. For the IKEA customer, it's "what fridge, microwave, or dishwasher fits this thing I just designed."

Find a partner.

Someone who already builds the thing that solves the friction. You don't have to make it in-house. You curate it, brand it, and integrate it into the same flow as the anchor.

They didn’t get into a new industry. They got deeper into the same customer’s problem.

The fridge is not the product. The complete, frictionless kitchen is the product. The fridge is just what makes it possible.

The Good, The Premature, And The Missing

Not every company that understands this executes it well. I've been thinking about three archetypes, with examples that are happening right now.

The missing ones solve half the problem and walk away.

Calendly is the case I keep coming back to. They booked meetings for a decade and never touched what happened inside or after them. The customer's actual next 48 hours after a meeting got booked were full of friction: who is this person, what did we discuss last time, what notes do I need to take, who follows up. Calendly had years of distribution and watched Granola, Fathom, Otter, and Fireflies build entire companies on the gaps they ignored. They're trying to catch up now with a Notetaker product launched in 2026, but they handed competitors a five-year head start.

The premature ones sell the fridge before anyone wants the cabinet.

Humane is the obvious one. They raised $230M, launched the AI Pin at $699 plus a $24/month subscription, and shipped with a full ecosystem in the box: laser projector, voice OS, gesture controls, plans for an operating system that would eventually live across other devices. The problem was that the anchor product, the pin itself, didn't work. Reviews were brutal. Returns exceeded sales by 2024. HP bought what was left for $116M, less than half of what Humane had raised. They had built the upsells, the platform, the ecosystem, before anyone had agreed that the core thing was worth wearing.

The good ones sell the next mile.

Granola just shipped the cleanest recent example. Their anchor, AI meeting notes, was working. People loved it. So they asked the IKEA question: what's the customer's next 48-hour friction? The answer was sitting in plain sight. Every user frantically Googles the person they're about to meet in the five minutes before the call. Just to get some context. So now, if a meeting is on your calendar, the Granola agent goes off overnight, pulls relevant context about the person you're meeting, and lays it out at the top of the note when you open it. You don't have to search. You don't have to switch apps. The friction you were about to hit is just gone.

Subscribe now

The IKEA Test

So when do you actually do this? There are three conditions. Mostly obvious ones. But if you haven't hit one of them, you shouldn't be thinking about the upsell yet.

One: does the anchor have retention? You can't sell the fridge if no one wants the cabinet. Low churn, repeat usage, customers who tell their friends. Those are the prerequisites. If the anchor is leaking, the pre-solve makes it worse, not better. Fix the leak first.

Two: is the upsell the customer’s next 48-hour problem? Not their next year. Not their next adjacent need. The specific thing they're about to do or worry about immediately after they bought from you. A no-code form builder upselling embedded payments works because the user is literally about to need a way to collect money from the form they just built. The same form builder upselling email marketing fails because that's a different workflow on a different day. If you have to explain why the two products belong together, they don't.

Three: does it feel like one product? If the customer has to leave your interface, make a new account, and copy-paste their info into a third-party dashboard, you haven't removed friction. You've moved it. IKEA's fridge appears in the kitchen planner. It doesn't redirect you to Whirlpool's website. Granola's pre-meeting brief opens at the top of the note before your meeting. It doesn't open a separate research tab. The value you're offering is curation and convenience, not just access.

If all three pass, you have a fridge to sell.

The cleanest version of this looks like nothing. The customer doesn’t feel upsold. They feel understood. They came in for the cabinet and left with a complete kitchen, and they’re grateful you thought of everything.

Figure out what yours looks like. It’s probably already sitting in the gap between what your product does and what your customer has to do next, or even right before.

Thanks for reading Table For One! Subscribe for free to receive new posts and support my work.

Subscribe now

Sources

1. Inter IKEA Group. “IKEA Retail Sales FY25.” IKEA Global Newsroom, 2025. (Revenue figures, kitchen/dining FY26 focus.)

2. IKEA. “Appliance Deals & Offers.” IKEA US. (SUPERKALL model, five-year warranty terms.)