Being a solo founder means doing the jobs of six people with the time of one. The right AI tools don’t make you “10x” — they just let the parts you’d otherwise drop actually get done. Here’s the practical stack, organized by the job to be done, from someone running a real one-person startup.
Validating the idea
Before you build anything, pressure-test the idea. Don’t ask a chatbot “is this good?” — it’ll just flatter you. Use a tool built to be skeptical.
AI startup idea teardown — free, no signup: paste an idea, get a blunt GO/NO-GO verdict, the real risks, the specific buyer, and 5 actions for the week.
Perplexity / Claude with web search — for hunting real, dated complaints on Reddit and Hacker News (force it to cite sources).
Building the product
Cursor / Claude Code — AI-assisted coding; the daily driver for shipping fast.
v0 / Bolt / Lovable — generate a working UI or prototype from a prompt when you want speed.
A good boilerplate (auth + billing + AI baked in) so you skip the boring 20% every app rebuilds.
Marketing and content
Claude / GPT — drafts of landing copy, posts, and email sequences (then rewrite in your voice — generic AI copy converts badly).
An AI tool that reads your Search Console data and tells you which page to write next beats “do SEO” advice.
Sales and outreach
AI for prospect research and drafting cold outreach — but send it yourself, personalized. Automated DMs get you banned and ignored.
Operations and finance
AI for first-draft SOPs, financial models, and runway math — fast scaffolding you then sanity-check.
The honest take: tools vs. a team that does the work
Most “AI founder tools” are a chatbot that gives you advice you still have to act on. The leap that actually saves a solo founder time is AI that does the work in your real tools — ships the landing page, drafts the outreach, runs the pipeline — not just describes it.
That’s the bet behind AI Cofounders: six specialized AI cofounders (Product, Tech, Marketing, Sales, Operations, Finance) that produce real deliverables and take real actions, with your approval. If you want to stop collecting advice and start handing work off, start with the free teardown and see one of the cofounders in action.
The rule for picking tools
Don’t chase the tool of the week. Pick one per job, learn it deeply, and ask of each: does this help me execute, or just plan? The ones that execute are worth paying for. The ones that only advise are mostly free elsewhere.
Every “first users” guide assumes you already have an audience. Most founders don’t. You shipped something, you have zero followers, no email list, and posting about it gets crickets. So how do you actually get your first 10 users?
The honest answer is the one nobody likes: by hand, one at a time. That’s not a failure mode — it’s how Airbnb (door-to-door), Stripe (installing it on people’s laptops), and Superhuman (a concierge call per user) all started. You don’t need distribution to get 10 users. You need 10 conversations.
You need ~10 users, not 10,000 followers
This reframe matters. Building an audience is slow and most builders are bad at it. Getting 10 users is a sales problem, not an audience problem — and you only need a handful. Stop waiting to be famous and go talk to people.
1. Mine your warm network first
The fastest users are people who already know you. Not “post on your profile and hope” — direct messages:
“Hey [name] — I built a thing that [does X for people like you]. Would you try it and tell me what breaks? I’ll set it up with you on a quick call.”
Ten of these to the right people usually gets you 2–3 trials. They convert because there’s existing trust.
2. Go where your users already complain
Your users gather somewhere — a subreddit, a Discord, an Indie Hackers thread, a niche forum. Be useful there first: answer questions, help people, for a week, with no pitch. Then mention your tool where it genuinely fits a thread. People who came from a helpful answer convert far better than people who came from an ad.
A warning learned the hard way: read each community’s rules before you post. Most ban self-promo, and getting your account flagged on day one sets you back.
3. Cold outreach — it’s a numbers game, not a charisma game
Find 20 people or companies who visibly have the problem (posting about it, building something adjacent, hiring for it). DM or email each one something specific:
“Saw you’re [doing X]. I built [thing] that could [specific benefit for them]. Want me to set it up for you, free, this week? Genuinely just want feedback.”
Send 30, book ~3 calls, close ~1. Lead with value, make it specific to them, and don’t pitch — offer to do something useful.
4. Give something away that’s about THEM
The single best top-of-funnel is a free tool or teardown that’s about the user, not about you. A result they can screenshot and share spreads on its own utility — no audience required. (That’s the whole idea behind our free startup idea teardown: paste an idea, get a verdict, and people share their results.)
5. Concierge the ones who show up
When someone does try it, don’t let them bounce. Get on a 15-minute call, walk them through it, watch where they get stuck, and fix it in real time. Your first 10 users should feel hand-held. That’s not a crutch — it’s how you learn what’s broken and turn a trial into a retained user.
The mindset shift
Getting your first users isn’t a growth-hacking problem. It’s the unglamorous work of dragging 10 humans in one at a time — DMs, communities, a useful free thing, and conversations. It won’t scale, and it’s not supposed to. You do the unscalable thing until the product is good enough that word of mouth and SEO start doing it for you.
If your idea isn’t validated yet, start one step earlier: run it through the free AI startup idea teardown first, so you’re recruiting users for something people actually want. Then go have 10 conversations.
Most people think finding a startup idea means waiting for a flash of genius. It doesn’t. Good ideas come from a repeatable process of noticing real problems — and the hard part isn’t finding an idea, it’s telling a good one from a shiny one. Here’s how to do both.
Where real ideas actually come from
Your own annoyances. The thing you hacked together with a spreadsheet because no tool did it well. If you have the problem, you’re a built-in first user.
Your unfair knowledge. A job, hobby, or community you know deeply. You see problems outsiders can’t, and you know the language the buyers use.
Where people already pay. Look at what’s already selling and find the underserved slice, the bad-but-popular incumbent, or the niche too small for the big players.
Public complaints. Reddit, Hacker News, app store reviews, support forums. People describe their pain in their own words, daily. Read where your would-be users complain.
Notice what’s not on the list: “what’s a hot market.” Chasing AI or crypto because they’re hot, with no specific problem, is how you end up building a solution looking for a problem.
The test: is this a problem or just an idea?
The difference between a founder and a daydreamer is this filter. A real idea has:
A specific person with the problem — not “everyone who…”. “Solo therapists who hate writing notes” beats “busy professionals.”
Existing pain, not hypothetical pain. People are already losing time or money on it, today.
A reachable audience. You can actually find and talk to these people online.
Money already moving. Competitors or paid workarounds exist. “No competitors” is usually a red flag — it often means no budget.
If your idea fails these, it’s not a bad idea — it’s an unvalidated one. Which is fine, as long as you validate before you build.
The trap: falling in love with the solution
Founders fall in love with their solution (“an app that does X!”) instead of the problem. The solution feels exciting; the problem feels boring. But the problem is where the money is. Stay obsessed with the pain, stay flexible on the fix.
Don’t trust your own excitement — get a verdict
Your own enthusiasm is the worst possible judge of an idea. You’re not neutral. So before you commit months, get an honest, skeptical read: does the pain exist, who has it, what do they use now, will they pay?
You can do this manually (hunt real complaints, name the tribe, map competitors, force a GO/NO-GO verdict), or run it in one shot with the free AI startup idea teardown — paste your idea, get a blunt verdict, the real risks, and the cheapest way to test the riskiest assumption. You can also browse public teardowns to calibrate what a good idea actually looks like next to a weak one.
The honest summary
You don’t find a startup idea by waiting. You find it by paying attention to real problems — yours, your field’s, and the ones people complain about publicly — and then ruthlessly filtering for a specific buyer with present pain and a budget. Find the problem, validate it cheap, and only then fall in love.
Most founders validate their startup idea by asking ChatGPT “is this a good idea?” and hearing “what a great niche!” That’s not validation — that’s a compliment machine.
Real validation answers four questions with evidence:
Does the pain exist? (Are real people complaining about this, in public, recently?)
Who exactly has it? (A reachable tribe, not “everyone who…”)
What do they do about it today? (Competitors and workarounds — both are good news)
Will they pay? (Is money already moving in this space?)
Here’s how to get evidence-based answers using AI, for free, in about 30 minutes.
Step 1: Hunt the complaint, not the compliment (10 min)
Go where your audience already complains: Reddit, Hacker News, niche forums. The AI move is to use a model with web search and force it to cite:
“Search Reddit and Hacker News for people describing this problem: [your problem]. Give me direct quotes with links, dated within the last 12 months. If you can’t find at least 5, say so.”
The last sentence is the important one. You’re trying to make “there’s no demand” a possible answer. If the AI can’t find recent, specific complaints, that’s your result — cheaper to learn now than after three months of building.
Step 2: Name the tribe (5 min)
“Busy professionals” is not a tribe. “Solo therapists who hate writing post-session notes” is. Push the AI:
“Based on those complaints, describe the single most specific group with this pain. Where do they hang out online? What words do they use for the problem?”
The words matter — they become your landing page headline and your search keywords.
Step 3: Map competitors and workarounds (10 min)
“List products that solve this today, with pricing. Then list the manual workarounds people describe (spreadsheets, VAs, duct tape). What do users complain about in each?”
Two traps here:
“No competitors” is usually a red flag, not an opportunity. It often means no budget exists.
The workaround is your real competitor. If people solve it with a free spreadsheet, your $49/month tool fights the spreadsheet, not the other SaaS.
Step 4: Force a verdict (5 min)
This is the step everyone skips, because chatbots are agreeable by default. Force it:
“You are a skeptical product advisor who has seen 1,000 failed startups. Given the evidence above, give me: a GO / NO-GO / PIVOT verdict, the 3 biggest risks, and the cheapest possible test for the riskiest assumption. Do not soften the verdict.”
You’re not asking permission to build. You’re asking what would have to be true — and what the cheapest way to check it is.
The traps that invalidate your “validation”
Leading the witness. Ask “what problems do you have with X?” — never “would you use a tool that does Y?”
Validating the solution instead of the pain. People lie about what they’d use; they don’t lie about what already hurts.
Counting upvotes as demand. Likes on “I’d love this!” are not pre-orders. Money, emails, and waitlist signups are.
One-and-done. Validation isn’t a gate you pass once; the verdict updates with every new piece of evidence.
Or run the whole thing in one shot (free)
I turned this exact process into a free tool: the AI startup idea teardown. You paste your idea, and the Product cofounder from aicofounders.co runs the full diagnostic — honest verdict, pain level, the specific tribe, named competitors, real risks, and 5 concrete actions for this week.
No signup, takes a few minutes, and the verdict is deliberately blunt — it will tell you NO-GO when the evidence says NO-GO. You can also browse public teardowns other founders have run to calibrate what honest validation looks like.
Worst case, you lose 5 minutes. Best case, you avoid losing 3 months.
Between them: 130 messages, 86 board items, zero things produced in reality. No landing pages deployed. No outreach emails sent. No GitHub pushes. No social posts made.
The product technically worked. The tools were wired. They could have executed — they just didn’t.
I sat with this for three days. The instinct was: nobody wants this product, kill it. But the engagement was high. The output volume was high. The piece that was zero was crossing the line from thinking to shipping.
That’s not a “users don’t want this” diagnostic. That’s a UX problem: the product makes thinking easy and shipping invisible.
Reading the data carefully
Here’s what made it interesting. Both users worked through their first session for 90+ minutes. They populated multiple boards (Idea Teardown, Validation, Sprint, Pipeline). They generated cold email drafts, landing page copy, sprint plans, financial models.
All of those outputs are executable — the tool to ship each one exists in the product. There’s a “deploy landing page” tool, a “send via Gmail” tool, a “push to GitHub” tool. They just sit in a Tasks panel users discover about 30% of the time.
When the Sales AI drafted a cold email and said “want to send this?”, the user had to mentally rebuild the context: which tab is the tasks panel in, what does approval look like, do I need to connect Gmail first. Three layers of friction between draft and ship.
That friction is the difference between “AI that helps me think” and “AI that helps me ship.” Different products. Different value props.
What I shipped to close the gap
30 days of work, no new capabilities, only UX:
Action buttons on every deliverable card. When the Sales cofounder produces an email draft, the card now has a primary “Send via Gmail” button right under it. Not in a Tasks panel. Inline. Same for “Push to GitHub”, “Post to LinkedIn”, “Deploy live”.
A system rule I called EXECUTE-OR-OFFER. Every cofounder’s system prompt now has a forced rule: when you produce an executable artifact, you MUST end your response with a specific ship-offer. Not “let me know what you think” — “want me to send this to david@acme.co right now?”
A “Shipped” panel. New side panel listing every real-world artifact the cofounders have actually produced. Sent emails, deployed pages, pushed code, posted social. Empty until you ship something. Becomes a visible scoreboard.
A reframed onboarding question. “What does it do?” became “What do you want SHIPPED this week?” The first cofounder turn aims at the founder’s stated weekly outcome, not 12-month strategy.
Connection-aware buttons. If Gmail isn’t connected, the button reads “Connect Gmail → Send” with one-click OAuth.
Preview modal for high-risk actions. Click “Send via Gmail” → modal opens with editable subject, recipient, body. Cancel / “Looks good — send.”
Background nudge cron behind a feature flag. Daily cron that surfaces what’s overdue. Gated by an env var — defaults off.
Total: 17 files modified, ~600 lines added, single branch.
The harder lesson
Shipping “no new features” is uncomfortable. It feels like inactivity. The marketing department of your own brain says “but I need something new to post about.”
But the diagnostic was clear. The capabilities existed. The hierarchy was wrong. If your data shows users engaging but not converting to action, your next sprint probably isn’t more features. It’s surface area redesign.
The hardest features to ship are the ones that change user behavior, not the ones that add surface area.
What I’m watching now
Did the change move the needle? The honest answer is: I’ll know in 14 days. The metric is binary — does the Shipped panel populate for any user? If yes, the UX bet was right and I extend the pattern. If it stays empty, the diagnostic was wrong and the gap is in the thesis, not the UX. Different pivot.
I’ll post the results when the window closes.
Where this came from
I’m a developer at a Fortune 500 by day and a solo founder by night. aicofounders.co is what I’m building — AI cofounders for solo founders who want to ship a SaaS while holding down a full-time job and a family.
The product is in closed beta. If you want to try it, join the waitlist. If you want to test it without signing up, you can run a free idea teardown — one of the cofounders, running for free, on whatever startup idea you’re thinking about.
If you’ve solved the engage-but-don’t-ship gap in your own product, I’d love to hear what worked. Reply on X or shoot an email — I read everything.
Eight hours at the day job. Six hours awake with my son and partner. Two hours on the side project, 10 PM to midnight, most days. Eight hours sleep on a good week.
That’s the schedule. Most weeks I get 12-15 hours on the product. Some weeks the day job demands a fire and I get five. Some weekends the kid is sick and I get zero.
At 50 hours a month, that’s 600 hours a year. Most full-time founders burn 600 hours in a single month. The math says I should be 12x behind them.
Six months in: I’m not. Slower, yes. But shipping consistently, learning the same lessons (just slower), and — crucially — not running out of money or burning out.
I want to share what actually works at this pace because most “founder content” is written by people who quit their jobs. The side-hustle path is undermarketed.
Why I haven’t quit yet
Three reasons.
Stability removes desperation. I’m not building from financial fear. I can pick the right feature instead of the marketable one. I can spend a week fixing infrastructure that won’t show up in screenshots because there’s no urgency to fake progress. When you’re not running out of money, you can make slow decisions.
The day job teaches what NOT to do. I sit in 4-hour quarterly planning meetings. I watch products take 3 months to ship a button color. The contrast trains my speed instincts. Every time I open my laptop at 10 PM, I can ship in 25 minutes what a corporate team would schedule for next sprint.
The audience is built-in. My LinkedIn audience cares about “engineer at Fortune 500 builds side project” content. That’s the content I have. Doesn’t work without the day job context.
The conventional wisdom says quit, give it everything, the constraint of survival will force product-market fit. My experience: the constraint of survival forces something, but it’s often not PMF. It’s bad fundraising, bad customers, or burnout. Stability lets you wait for the right shot.
The actual schedule
Monday-Friday:
7:00 AM — kid up, breakfast
8:30 AM — at the day job
6:00 PM — back home, family time
9:00 PM — kid in bed
10:00 PM — laptop open
12:00 AM — laptop closed (mostly)
Saturday-Sunday:
One of these days is family-only, no laptop
The other has maybe 3-4 hours of focused work
Weekend hours are unreliable — plan around weekdays
That’s it. The 10 PM block is sacred. No phone. No Slack. No “quick check” on email. Two hours of clean coding.
The 2-hour evening block — what actually fits in it
I used to think 2 hours wasn’t enough to do anything real. Six months in, here’s what fits:
One bug fixed + one feature shipped
One new tool wired through the integration layer
One blog post written
One round of cold emails (5-10) personalized and sent
One full code review of my own work from the last month
One conversation with a beta tester (DM thread)
One Notion template written from scratch
What does NOT fit:
Two of the above
A 4-hour deep refactor
A real podcast appearance
A live coding session
The discipline isn’t “work harder.” The discipline is “do exactly one thing per evening.” Pick before you open the laptop. Don’t context-switch.
What I stopped doing
A list of things I stopped doing once I accepted the 12-hour-week constraint:
Reading hacker news during work hours. I used to scroll for 20 minutes a day “for inspiration.” Now I batch it to weekends.
Tracking every metric daily. Daily metric reviews are a procrastination loop. I look at numbers once a week.
Writing roadmap docs. Nobody reads them. The work itself is the spec.
Adding features users haven’t asked for. Easier said than done.
Meetings with myself. I used to “plan the week” for 45 minutes on Sunday night. Now I write the weekly ship target on a Post-it, that’s it.
Premature scale thinking. Optimizing for 10,000 users when I have 2 is just procrastination dressed up.
Comparing myself to full-time founders. Their constraints aren’t mine.
What I started doing
One ship target per week, written before Monday. Anchors everything.
One personal email per day to a beta tester or specific ICP person. 30 emails a month, slowly compounding.
One blog post per week (this is one). SEO compounds over 18 months.
One free resource per month (Notion templates, frameworks). Lead magnets that demonstrate the product.
A weekly “what I shipped” review every Friday night, 15 minutes. Brutal honest.
Walking before the 10 PM block to context-switch out of day-job brain.
A list of “would do if I had a full-time founder budget” that I check quarterly. Most things on it turn out to not matter.
The 6-month numbers
Side-hustle math, for context:
Followers grown: 90 → 370 on X
Waitlist signups: 92 (all organic)
Beta invites sent: 18
Beta accounts redeemed: 3
Active users: 2
Real customers (paid): 0 (still closed beta)
Hours spent: ~350
Hours per beta account: 116
Hours per X follower: 1.25
The hours-per-result math is awful. The compounding math is fine. The fundamentals (shipping consistently, talking to users, learning the lessons) are working. The amplification (distribution) is where the slow part is.
What I’d tell my 6-months-ago self
You’re not behind. The pace is normal. Founders you admire took 1-3 years before anything worked.
Distribution is the bottleneck, not building. Spend 50% of your time on distribution starting now. (I still don’t do this enough.)
Pick a narrower niche. “Solo founders” is too wide. Pick a specific subgroup — side-hustle founders with day jobs, or domain experts going SaaS — and write FOR them, not for everyone.
Build a free vehicle product early. A small free tool that pulls people into the funnel without committing to a SaaS trial. (I just shipped one — should have done it month 1.)
Stop “saving” Product Hunt for “later”. Launch it on a small product to learn the mechanics. The first launch is always rough.
The reply game is your most underused channel. Bigger account threads are where attention lives. Be there daily.
Why I’m still doing this
The honest answer: it’s the most meaningful work I do in any given week. The day job pays well and I’m grateful for it. But the day job hasn’t asked me to think hard in months. The side project asks me to think hard every single night.
That’s worth a lot. Even if the numbers stay slow, the I’m a person who builds things identity stays alive. I can’t put a dollar amount on that.
The day job and the side project teach each other. The corporate context grounds me in scale and stakeholder reality. The side project keeps me dangerous.
Where to find the work
I’m building aicofounders.co — 6 AI cofounders for solo founders who want a team without hiring one. Closed beta.
If you want to test it without signing up, run a free idea teardown. It’s the Product cofounder, running for free, on whatever startup idea you’re thinking about.
If you’re on the same path — day job + side project + kid or no kid — say hi. I read every email and reply within 24 hours: kyle@aicofounders.co.
This is post #2 of an ongoing build-in-public series. Subscribe to follow the journey from closed beta to first paid customer.
I run a SaaS where every user interaction triggers LLM calls. The product is aicofounders.co — 6 AI cofounders that produce strategic output for solo founders. Token spend is the largest variable cost in the business.
Two months ago I built a per-user cost dashboard for the admin panel. Looked clean. Showed me $4.50/week in LLM cost. Felt expensive for 2 active users.
Made me nervous. Started slowing beta invites because the math felt fragile. Considered raising the Starter tier price from $29 to $39 to cover real cost. Deprioritized some token-heavy features.
Last week I looked at the dashboard again and noticed something. OpenRouter — my LLM provider router — returns response.usage.cost on every API call. The actual cost in USD, calculated by them, returned in the response.
I’d been ignoring it. My dashboard was using a static pricing table I’d built months ago, calculating cost from token counts. I wired up the real cost reading.
For two months, my product had been silently using anthropic/claude-haiku-4-5 (cheap, $1/$5 per million tokens). My pricing table HAD that specific entry — but a typo in the model name. The real model returned by OpenRouter is sometimes served as anthropic/claude-4.5-haiku (version before tier, different convention).
My exact-match check failed. Costs fell through to the catch-all anthropic/* which pointed to Sonnet pricing ($3/$15 per million). Three times the real cost.
The bug was invisible because:
The dashboard “worked” — it showed numbers
The numbers were plausible — $4.50/week feels like a reasonable LLM cost
There was no error log because the catch-all matched correctly (just with wrong rates)
This is the most dangerous category of bug. Loud bugs you catch immediately. Silent bugs that produce plausible-but-wrong numbers can run for months.
Strategic decisions I made on bad data
In the two months when my dashboard was lying:
I slowed beta invites. Was worried about cost-per-user. Should have invited more aggressively.
I considered raising Starter pricing $10/month. Would have hurt conversion for no real reason.
I deprioritized features that consumed tokens. Specifically, the deeper research tools (multi-step reasoning, longer context). Those should have stayed.
I planned a tool-model swap to reduce cost on what I thought was the second-biggest token consumer. Turned out it wasn’t.
Four bad decisions, partially mitigated by being a careful person, but the bias was real. Bad dashboard data shapes product strategy in ways that look rational from the inside.
When the provider returns real cost, use it. Static table is fallback only.
Part 2: backfill historical data.
Rather than just fixing forward, I wrote a script that walked every UsageLog row in the database, looked up the correct rate for the model recorded, and updated estimatedCost to match reality. About 5,000 rows. Total time: under a minute.
The dashboards now show truth all the way back to the product launch.
A checklist for anyone running LLM-powered SaaS
If you have a per-user cost dashboard and you’ve never re-verified the methodology, do it tonight. Bullet checklist:
Read your provider’s response.usage.cost field if available. OpenRouter, Anthropic, OpenAI all return it. Use it as the source of truth.
Match on both requested AND served model names. The model you REQUEST and the model your provider SERVES can differ in naming conventions. Catch both shapes in your pricing table.
Add an explicit pricing entry for every model variant you use. Don’t trust catch-alls. When you add a model, add the entry. When you remove a model, remove the entry.
Re-audit your cost methodology quarterly. Models update. Env vars change. Provider pricing changes. Your code didn’t notice.
Track requested model vs served model in your log. Saved me a debug round when I needed to figure out which model was actually doing the work in production.
Backfill historical rows when you fix the methodology. Otherwise your dashboards show two different truths — old wrong, new right — and your eyes will lie to you about trends.
Cross-check by hand monthly. Pick a single user, look at their token spend in the dashboard, manually multiply by current rates, compare. Catches drift before it becomes habit.
What this cost me
Two months of slightly suboptimal decisions. No actual lost money — the real cost was always lower than I thought. But the opportunity cost of slowing beta invites and dragging on pricing decisions: probably one or two beta users who would have been ready to be paid converters by now.
The lesson generalizes beyond LLM cost. Dashboards lie. Especially the ones you built yourself. Especially the ones you stopped checking the math on.
Bigger principle
A founder I respect once told me: half your job is being skeptical of your own data.
If you can’t reproduce the dashboard math by hand on a single row, you’re flying blind.
If you haven’t re-verified the methodology in 90 days, the methodology is probably wrong.
If your strategy depends on a number in a dashboard, audit the number before you commit the strategy.
Where this work happened
I’m building aicofounders.co — 6 AI cofounders for solo founders. The cost dashboard described here is part of the admin panel that lets me run unit economics in real time.
