I have more app ideas than I know what to do with right now.
That sounds like a good problem, and in some ways it is. Codex and Claude Code have made the distance between "this workflow is annoying" and "there is a working app in production" feel shorter than it has ever felt in my career.
But that also creates a new problem.
When you can build almost anything, you need a much better filter for what is actually worth building.
That is the part I keep coming back to. Prompting matters. Shipping matters. Knowing which model is good this week matters. I use all of that every day.
But the thing that feels more valuable every month is the judgment before the build starts. Which real problem deserves software in the first place?
CalConnect started with a dumb real problem
CalConnect did not start as a brainstormed SaaS idea.
It started because my calendar setup was annoying.
I had work calendars, personal calendars, client calendars, and enough meetings moving around that double-booking became a real problem. I did not want to expose meeting titles, attendees, notes, or links between calendars. I just wanted the other calendars to know I was busy.
That is a good software problem.
It is specific. It is boring. It repeats. It has a clean before and after. It is painful enough that someone will actually care if it disappears.
So I built CalConnect.
This is a real product at calconnect.io. People can sign up, connect calendars, redeem AppSumo codes, manage billing, and hit the weird little edge cases real software always has.
It is a Next.js app on Vercel. Supabase handles auth and Postgres. Google Calendar push notifications tell the app when something changes. Stripe handles subscriptions. AppSumo redemption works through hashed lifetime deal codes. Rafter reviews the security-sensitive pieces before they ship.
There are cron jobs, OAuth scopes, token refreshes, webhook handlers, RLS policies, billing portal links, reconnect flows, and all the boring production stuff that separates a neat prototype from an app people can actually use.
That is where AI has changed the game for me.
I can move through all of that much faster now. I can ask Codex to read the repo, update the docs, write the migration, explain the webhook failure, tighten the copy, add the Stripe edge case, or make the landing page cleaner.
AI helped me build it. The workflow is what made it worth building.
The app idea is usually too big
The first version of almost every software idea is too wide.
You want the whole platform. The whole operating system. The whole dashboard. The whole CRM. The whole AI assistant that manages every workflow for every team in every industry.
That is usually where the idea gets weaker.
CalConnect worked because the first job was tiny:
Mirror Busy blocks across Google Calendars without leaking private calendar details.
That is it.
There are plenty of directions it can go from there. Teams. Assistants. Better rules. More calendar providers. Scheduling workflows. But the first product did not need all of that to be useful.
This is the part I think a lot of people skip when they get excited about AI app building.
They go straight to "what can I build?"
The better question is:
What problem keeps showing up even though people already have tools?
That is where the good ideas hide.
CreatorBoard is the next example
CreatorBoard came from a different kind of mess.
Running creator programs sounds fun until the work spreads across DMs, comments, mentions, emails, spreadsheets, affiliate tools, ad accounts, and random Slack threads.
The hard part is rarely "do we have creators?"
The hard part is knowing who matters, where the conversation happened, who needs a reply, which creator already sent assets, which creator is driving revenue, and which message should be handled before it goes cold.
That is a software problem too.
The important part is the wedge.
CreatorBoard could become a huge platform if you let it. Instagram, TikTok, YouTube, X, LinkedIn, affiliates, payments, contracts, content approvals, attribution, paid amplification, reporting, and a thousand other things.
My instinct is to start with the smallest useful pain: one inbox for creator program messages, with the creators you already care about sorted to the top.
Even that is not simple. Instagram has Facebook Graph API constraints. TikTok does not give you the same webhook surface. YouTube is its own OAuth and push world. X has paid API realities. LinkedIn has limited messaging access.
That is why knowing what to build matters.
The code is only part of it. The actual product judgment is choosing the first slice that can work technically, solve a real pain, and reach a buyer without turning into a six-month platform fantasy.
My current build filter
When I look at a new app idea now, I run it through a pretty simple filter.
First, did this come from a real workflow I have seen?
CalConnect came from my own calendar mess. CreatorBoard came from watching creator programs turn into scattered tabs and lost follow-ups. The Google Ads agent playbook came from 15 years of managing paid media and then trying to give agents enough judgment to be useful.
If the idea only exists because it sounded cool in a prompt, I do not trust it yet.
Second, are people already duct-taping a solution together?
Spreadsheets are a good signal. Shared docs are a good signal. Slack threads are a good signal. Airtable bases, Zapier workflows, Notion tables, calendar hacks, manual QA checklists, random exports, and "can you send me that again?" are all good signals.
Those are not signs that the market is solved. They are signs that people care enough to tolerate a bad workaround.
Third, can I describe the first wedge without using five commas?
If the first sentence needs a paragraph, the product is probably too big.
CalConnect mirrors Busy blocks across calendars.
CreatorBoard puts creator messages in one inbox and prioritizes the creators you track.
That is the level of clarity I want before I start building.
Fourth, do I understand the boring parts?
This is where a lot of AI-built apps fall apart. The demo looks good, then the real world shows up.
OAuth verification. Billing. Refunds. AppSumo codes. Token refresh. Webhooks. Rate limits. RLS. Delete account flows. Error states. Logs. Support. Privacy policy language. Someone connecting the wrong Google account. Someone cancelling and then asking why they still have access.
The boring parts are the product.
If you are using AI to build software, you cannot skip them. You just get to move through them faster if you know what to ask for and you have a repo that explains how the system works.
The operator advantage
This is why I think operators have a real advantage in the AI app era.
If you have spent years inside a workflow, you know where the pain is real and where people are just complaining. You know which parts are annoying but harmless, and which parts actually cost money, time, or trust. You know what a buyer will understand in 10 seconds because you have had the same conversation over and over.
That experience is leverage now.
A junior builder can ask AI to make an app. A senior operator can tell AI which ugly workflow is worth turning into an app, where the first wedge should be, what should be excluded, what the user will not tolerate, and which edge cases will break trust.
That is a very different thing.
You do not need 15 years in an industry before you build anything. You do need taste, curiosity, and enough contact with the actual work to know what is painful versus what is just interesting.
AI makes it easier to build the wrong thing quickly. That is the trap.
The win is using AI to build the right small thing faster than you could have before.
What I would do before building
Before I let myself get too deep into a new product, I want the boring one-page version. What problem keeps repeating? Who has the problem? What are they doing today instead? What is the smallest useful wedge? Where will the first users come from? What has to be true for someone to pay?
Then I want the part people usually avoid until too late: what private data, money movement, OAuth access, or user trust does this touch? What would make the product embarrassing or dangerous if it broke?
Those questions save a lot of time.
They also make AI more useful. Codex is much better when it is working from a clear product decision instead of trying to invent the product strategy while also writing the code.
That is the pattern I want more of in my own work. Use AI to compress the build, but use operator judgment to decide what deserves to exist.