I'm desperately trying to find an idea I can work on, taking advantage of the current ease of developing MVPs.
I'm REALLY tired of working for an idea that doesn't belong to me (aka companies), but everything I create or try to do seems like there are already dozens of other solutions doing the same thing (specially in the fields of wrapping AI).
Thoughts?
The major lesson I have after +20 years doing this: WHO CARES.
This concern is valid for a huge company or anybody that wanna get like 70% of the whole market.
For solo/small teams? Think of yourself as a street cart vendor that sells hamburgers, and is located on the front of mac donalds.
They still sell.
What you has but not others is that you are small, and is the actual person other person can , FOR REAL, talk about your product.
That is the whole thing of working as a freelancer, solo, small business. You can, FOR REAL, provide personal training/consulting/support, etc.
And that works even if you just take the product made by the big corporation and just know how to use it. There is business in being the guy who knows Excel well.
Product's built based on brainstorming: NEVER worked.
Product built around solution to actual problems I've experienced: Always worked, BUT may not have a large enough TAM.
The best way to actually find problems to solve is to replicate something else (as a learning process to actually find the real product you need to build), or talk to people who have problems: e.g. Try an replicate a product with relatively simple core functionality all the way-end-to-end.
During that process you'll probably discover paint point that aren't addressed by any product.
Example from building: Build some GenAI based app that allows users to upload a video and have it "horrified." There may only be a small market in that, but the framework you build to do it could be productized (or subsets of the problem). A simple to use full stack solution where folks can focus on the image / video generation model prompting fine tuning, and then one-click deploy that model wrapped in a whitelabeled ios app with monetization built-in, etc. <-- sell the shovels.
Example from talking: Lot's of buddies have challenges with bringing AI based coding tools into the organization because most don't support on-prem. Is there an on-prem solution that acts like a DMZ? That is, Cursor team could securely deploy their models to containers running on on-prem hardware (with layers of physical and software security to prevent exfiltration of the model weights), while companies can load their propriety data into another container. Win-win.
A couple of things to consider:
- Business is more about execution than being the first to market with an idea. Marketing, customer satisfaction, pricing, reliability, ect, all come into play. Before you create, spend time looking at the "dozens of other solutions doing the same thing." You may find a weakness, unfulfilled need, niche, ect. Often times, in early markets with lots of players, the first movers have a lot of baggage that holds them back from growing.
(IE, the first movers made a lot of false starts and end up with Frankenstien products. You can "bypass" them by better understanding the market and building something with less functionality, but just enough functionality to meet most of the market's needs. This is a huge advantage because you aren't wasting time fixing a feature that only 2-3 people use, or making sure you don't break that one feature that 2 people use.)
- Look at books like "The Incredible Secret Money Machine" by Don Lancaster or "Start Small, Stay Small" by Rob Walling.
- Read through (and watch) a lot of YC material about starting a business. Although it isn't focused on solopreneurs, a lot of the concepts are very similar.
Me: I realized that I enjoy joining a company early and turning the MVP into an industrial-strength product.
Also: ideas are far less important than execution [1]. That's why it's best to work on problems you actually care about. If you don't, you'll end up cutting corners or burning out well in advance of success.
I did this a dozen times for different companies. So, I started a startup that focused on the 10% of features I had become an expert at and made it available as a self-service SaaS with a much smaller price. But then you still need to sell the damn thing, which is a drag and I don't put much effort into. I let the product grow pretty organically as users (who are SME's within departments of most companies) change their jobs and are looking for better solutions within their new employer's.
Sorry intentionally vague, not really willing to give specifics.
I think the world is full of ideas to work on. You can look into almost anything, and see that existing ways of working and systems are mostly crap. Just start working on something. Probably you will encounter other problems -- i.e. ideas -- when working on the first one.
The biggest thing is not the coding, but all the other stuff. Sales, invoicing etc. I find that tiresome.
I found an area far outside of tech that had very real problems that nobody was really solving; in fact, the existing tools that should have solved this problem turned out to be a nightmare for the intended users. I've been working on it for a few months now and gotten very positive feedback, and have a steadily-growing userbase now. It's more of a side-project right now, maybe 10 hours/week, but maybe someday it'll evolve into an actual business (:
Not willing to share specifics about the specific area I'm doing this in, but the general idea stands. It helps a lot that the problem I'm working to solve is one I personally dealt with, so I understood a lot about what the problem was and was able to effectively solve it for myself. This translated into producing something that a lot of people like and use regularly.
Even more broadly: solve your own problems, then generalise out. If you're solving a real problem that you have, that isn't incredibly specific to something about you/your life/the way you do things/..., then odds are there's probably others out there with the same problem. Every even modestly successful project I've had started with solving my own problems, then polishing the solutions for others to use.
At first it seemed like a trivial tool that was just a thin wrapper around wget, so I didn't think anyone else would want to use it, but as I started adding features traction grew and random contributors came out of the woodwork and started helping.
Monetized through consulting, and the consulting money is paying enough to scale the buiness a bit. Next step is releasing a "Pro" version as a SaaS with some fo the features that I cant open source anyway (e.g. CAPTCHA-solving, bot-detection avoidance, etc.).
What’s important to clarify is that I’m not building exactly what I had in mind when I first dreamt all this up long ago, but my first idea would never have worked anyway. The best thing I ever did was just launch, because your users (or lack thereof) will quickly prove which ideas are good and which are not. So my advice is just pick the best idea you have right now. Or if you don’t have any idea just solve a problem you or your friends have. Then launch as soon as you can and pivot, pivot, pivot. It’s always going to be an iterative process.
Do that enough, and you'll end up with a laundry list of "wish we could have this product/feature/etc."
A lot of the "boring" industries are also entrenched in old solutions that move at snail pace.
For example, working on an idea that doesn’t belong to you — that is the wrong frame.
Avoid leaping to solution thinking and look at actual problems. Talk to other people outside your company to see if they have the same problem. Then, try different approaches to solving it.
If you get really lucky you will end up with customers that tell you exactly what they need you to build for them.
You still will not be working on an idea that belongs to you.
But the business will.
It's about 90% time, not the 50% I expected.
What I’ve learned is that marketability is often more critical than the idea itself. If you’re working on an incremental improvement to an existing solution, start by defining your niche and Ideal Customer Profile (ICP). Consider your approach to reach these customers: Are you part of a community with shared pain points? Does this group struggle with specific issues your product could solve?
The customer and how you’ll connect with them should always come first.
Unless you can split hairs on why specific products don't appeal to people in a given niche/industry, at the technical level that the users care about, you probably won't find much success.
In my personal experience I come from the medical side of things. The amount of garbage software written by people who know nothing about how we work is obnoxious. They all advertise themselves as the "next generation, streamlined, efficiency boosting" magic pill for us, but it's about as convincing as your 5 year old telling you they can do your taxes.
So my advice is find something to do in an area of expertise you already have.
Note that this implies spending time in a different problem domain than just programming all day (alternately read as: have a hobby or two).
I finally have a side project with traction & paying users and it’s because sheer frustration drove me to improve an inefficient workflow in my language learning process (hobby), which turned out to not be such a unique problem at the end of the day.
(Not to shill - I was a frustrated Anki user and built this to improve my own life: https://ankiweb.net/shared/info/1531888719 )
Here's what worked for me: look for an important and frequent problem that you and people you know have, where the solutions are inadequate and people are not happy.
To know if you're going in the right direction talk to people about their problem and see how unhappy they are with the current solutions. You don't need to build anything at first just to validate the problem.
Most of your time building a business will be spent talking to customers, doing sales, understanding the problem space, not so much coding.
All of my ideas are things I need that weren’t available or were missing critical features.
I personally think it’s high risk to attempt to build something for others that you don’t personally need. You’re going to make a lot of assumptions and probably be wrong. It may cost you a lot of time and money.
I can imagine so many people sitting around trying to think of AI related things to build, since that is the insane trend right now. This approach, IMO, is not the right one.
Even building something that already exists - but making it cheaper or more reliable (improving the status quo) is enough.
When I was in Germany, I wanted to turn my highschool German into something usable, but no apps or techniques worked for me. And I've tried 20+ of them.
Anki was the closest, but I really dreaded the card creation process - sentence, translation, audio...
So when I've finished university, I've found myself in a situation in which: I didn't need a lot of money, didn't have a job, LLMs were a new thing.
So I've started building.
Sounds like probably short-term coattail-riding.
You'd have to find some niche that companies like OpenAI won't just cover themselves, with general-purpose solutions (and what they can AI-derive just like you're thinking). They're already marketing to your customers.
And if they won't soon cover what you do, don't be so dependent upon them that they can eat up your margin or cut you off anyway.
The other option is to be an investment scam yourself: ride the hype investment, draw big salaries, puff up resume, hope you get acquired quickly.
I still haven't quit my day job, but my business produces a reasonable side income.
Releasing something...anything is the first step. First ideas are dumb anyways but it opens up the door to the next iteration of the app.
Also there is a reason that lot of competitors are in a market. There is money to be made. When lot of competitors just niche down. Reduce focus to one segment of the market.
E.g. I use/used Google App Engine (GAE)[1] a lot. When Google deprecated the GUI, I found it inconveniencing using the CLI. Secondly, there was no GUI for the Datastore Emulator. So, I set out to build something for both of them [2] and then decided to put it out there for others.
Along the line, it turned out that Google didn't support using one of their tools "dev_appserver.py" for building Python 3 Apps on Windows and so I also built a patch for it [3]
1) https://cloud.google.com/appengine/docs/standard
3) https://github.com/NoCommandLine/dev_appserver-python3-windo...
Be very careful when you feel desperate. It's a recipe for bad decisions.
Long-term: sooner, softer, smoother. Recognizing and addressing issues sooner means you can make smaller adjustments.
Short-term: consider treating your current situation as your role learning experience. If you as a developer don't own the product, who does? Why isn't that you? If you think you can build a business on your own, you should be able to be the product owner within your company (and then you'll have plenty of resources if the product is worth something). If you do that, you'll have the experience needed to head out on your own if that's what you really want.
If you scoff that you could never do it in your company because those roles are filled, it's corrupt, etc., then treat the situation as your emotional learning experience: i.e., even if the company is as bad as you think, assume it's the best opportunity you'll ever get. How can you be the one that spins straw into gold? Build your own agency. It's unlikely you can afford better collaborators on your own dime.
Finally, the value stream always branches and branches. You can always go smaller to avoid competition, or bigger to divide a larger pie (typically into smaller pieces). If you want to extract value. But is that what you want?
If you want to build your brand, create something critical for someone important, retaining the credit and the credibility. For success and satisfaction, it's likely more important whose team you're on than what you do. And for that, you never, ever want to seem or be desperate to leave.
Whether building products for people or working with collaborators, think about things from their perspective: that's consideration (both emotional and as exchanged in contracts). Empathy for others is the master virtue, and you might find it helps you avoid thinking of working for a company as working on something that doesn't belong to you.
Like, just walk around your day without headphones on a no-stress day, and ideas just pour in from the ether. Not to mention if you have a pain point somewhere in your work or elsewhere.
Unless you went to Stanford and are going to secretly use your family office as the seed round and lead investor to scam VCs into thinking there is demand for your funding round, then making up problems and solutions isn’t for your socioeconomic class
Read this to learn more — https://asindu.xyz/posts/the-nature-of-technology-book-revie...
I was tired of spinning wheels trying to validate ideas.
I have experience working in a commodity business. And I tend to believe most things fall in this category.
You can differentiate yourself based on various factors, but the fact that other solutions exists is a good sign. You don't need to create an entire market to sell your product.
Do your product really well, but don't get hung up on it. Learn and lean into good client service. That will create the most opportunity as you expand.
You are running a business not a product.
I suggest exploring the idea of positioning. Here's a good start: https://www.youtube.com/watch?v=mggcrp8ddZE
* Notion.so had a growing user base, and customers loved it
* More and more people (and businesses) were storing important info in their workspaces
* Notion users were publicly complaining about the lack of a decent backup option (i.e. they cared enough to complain)
* Notion announced that they would be launching an API soon
Basically, there was untapped demand and no competition whatsoever. I was undecided between 2 ideas, so I built 2 landing pages and started talking about both. I noticed that one of them received more attention than the other. As soon as I gained the early access to the API, I started building.
The rest is history.
Go check my latest one Powtain.com: https://powtain.com/pow/AZges1
Look at companies already operating and think to yourself, "Meh, I could do that." and then do it.
Finding problems requires that they be considered as such, that there be a desired state that is different from the current state. That there be a gap (error). At some point, a hunter-gathered said "You know what, I'm kind of tired of hunting game. I'd rather chill and have these animals and plants right here". His current state differed from his desired state, and there was a problem that was born. That was a different problem than the state of being hungry (Current state: hungry. Desired state: not hungry) which lead him to hunt and gather in the first place.
Finding problems has a lot to do with exposition. The more situations, the higher the chance a problem hits you. Problems may not be yours but other people's, and they may not be aware they are problems (current state ≈ desired state. Close enough that they're not picking up the error, or that they perceive they can't do anything about it, often due to asymmetry of information).
That is to say, focusing on problems is more conductive to ideas.
Then who does the problem belong to? Your problem or other people's. Sometimes when it's other people's problem and you like these people, the problem becomes yours. "Fixing someone's computer", for example. Sometimes you go to use their computer and it's horribly slow even if the specs are good, and they might even have not noticed it or they got used to it or it's not that big of a problem until you fix it and they notice just how fast it's become (back to when they purchased it, but they forgot how it felt - perceptual contrast).
That is to say: what's your target audience. What's the market? The segment. Do you like that crowd? For some people, it's not important, but it is for me. There are categories of people I could talk with and topics I could talk about for hours and days and not feel like it's work (previously MLOps platform), and there are others I wouldn't really hang out with by choice or default (helped a friend making a product in the dental space).
Then there's qualifying the problems: Is it a real problem? For whom is it a problem (buyer, user, etc)? Do they know it is a problem or will I have to make them see it (raising awareness and "educating" is expensive)? Has it always been a problem or just now? Why now and what changed? When was the last time they had that problem and what happened and how frequently they're having it (frequency, impact)? What have they done to solve it (time/money/people/etc)? What were the outcomes (are they still dissatisfied)? Is it urgent/mandatory? Is it expensive?
How can I search for and reach the people who have that problem in order to learn?
>I'm desperately trying to find an idea I can work on, taking advantage of the current ease of developing MVPs.
Either hang out with people and listen. There are a lot of times where people describe something frustrating for them that is obvious for you. Now, whether the solution already exists and it's simply a lack of awareness, or they're aware of solutions and none did it for them, or that there are organizational hurdles, it's up to you to figure that out, but you're often in a position you can see it.
What's great is that you got the technical part down; one fewer layer of risk is good; but in my opinion, most of the time it's not that that kills an endeavor. The code cemetery is full of MVPs and full-blown products that found too few or no buyers to make viable at the time and place.
>but everything I create or try to do seems like there are already dozens of other solutions doing the same thing (specially in the fields of wrapping AI).
Kind of like beverages, snacks, clothes, cars, phones, laptops, languages, frameworks, etc? It tells you the importance of market, distribution, and a bunch of things other than code.
Checkout
indiehackers.com
for lots of stories/ideas on this topic.