This resonates with me. I've recently come out of retirement, and really gotten back into programming and product building. I've done this a few times before, but even with experience, I STILL find it hard sometimes to not just dive right in and start building. Mostly, it's because I enjoy it so much.
Now though, things are different. After a throw away project to get back into things, I realized I could very nearly just build first and find product market fit second if only because building is sooo much quicker now.
I decided that over the course of a year I was going to try building 3-6 separate projects, and assume at least one will be successful. My most recent project I realized very late that it's probably going to be very hard to ever make much money; so for now, I'm giving it away for free, just to see how people use it (https://seikai.tv).
I've not just started a new project and for sure this one is going to be a unicorn!
Spent last year working on a side project and assumed I would need this and that in order to launch. But after it was ready to launch, I found out there was no product market fit. I have known about the importance of quickly finding out pmf but still made the mistakes. knowing != doing. We just love building stuff and mistakenly convince ourselves that if I add one more feature, this thing would be ready for launch and take off. But in reality...
It’s a good lesson. We found PMF with a shared google sheet and a bit of data processing behind the scenes. The level of polish I’d come to expect as an engineer at an enterprise company was astronomically higher than what was actually needed for our customers to give us their dollars.
>In my experience reducing features is better to begin with.
This is right approach. Lean. If you don’t have PMF, reduce your features until you find it. Pivot. Maybe pivot again. Eventually you’ll find a market to serve. Just don’t fall into the sunken cost fallacy. Time box your market exploration.
As a freelance back-end developer with various co-founding experience this question speaks to me. I think it's all a matter of perspective.
Looking at it from a development perspective the two can mean the same thing: we pivot and so we need to add new features.
However, in my experience the key is to look at pivoting from a non-development perspective. As mentioned in parent comments you pivot to find a product market fit. That entails finding your audience and the problem you're solving for them. Those questions do not require a product, but a human understanding. Questions like 'is it actually a problem they need solving, or a slight convenience?' and 'how are they solving their problem without my product?'.
By pivoting quickly in that space you don't get bogged down by technical issues or challenges that don't even matter, and the real solution might be a week's worth of time.
Thanks for posting this insight, because a typical engineer, if they are worth their money, does not like the idea to launch something "unfinished" or "half-baked" or even "not yet perfect", but the business logic behind the MVP (minimal viable product) is clearly correct.
Have to disagree (although this may be a "no true Scotsman" disagreement).
I think a typical engineer is more likely to want to evolve towards mature software in small steps. In my experience the "complete it, then release it with a big splash" approach is more likely to come from marketing. "We moved the CTA up the page a bit" isn't the stuff of press releases.
TFA talks a bit about shiny object/library syndrome. I think there's another good reason to avoid new things: LLMs are better with old stuff.
I can sit down and essentially english-type an app together in javascript or an old version of bevy, but if I ask for new APIs it all falls apart until I have built up sufficient examples in my own code. I've tried giving documentation, etc. It's just easier to version pin something from 2022 and chug along using a less featureful but more productive assisted-coding paradigm.
I remember the moment when in my last startup, the first invoice was paid - $5. A magic moment. I still remember the name of the customer. The last invoice before exit was $50.000. I remember that customer too.
Interesting, did you pivot / change the target market? $5 sounds more like a consumer product but $50k likely isn't (unless you literally progressed from skateboards to cars like every Agile cartoon wants to make us believe)...
Among other things, I'm working on an elephant hunter type product. Took us five months, but the first invoices were $7k, $3k and now $45k but that doesn't prove much yet.
How do you guys get funding to build things for such a long time? Rent, food and health insurance in my area costs $50k per year. If feels I have no choice but to earn a salary.
Dropping a quarter of a mil on an app that might not pan out seems out of the question.
Nobody starts by dropping quarter of a mil, you start by dropping $1k and being very frugal, releasing something minimal, seeing how it behaves, and once you have some actual data to work with, you pivot again and again and again.
It's always a huge money sinkohole until it isn't.
- this is very likely a side project. Conclusion made by the fact that the author was writing, re-writing and re-writing again the project because of a new 'cool framework' that came out. They were taking their time to do that and doing it repeatedly for years. Proving that releasing the project was not their first concern, nor making money out of it judging from the fact this was not designed to make money but merely having a github sponsor button. Author's main concern seems to having been to just have with it and learning was likely a bigger factor.
- it didn't need funding to startup, as it seems like the only costs were the operating costs which were likely just a server on vercel
Also, to answer your question more thoroughly
- usually people that make projects like these have a main job, which funds in one way or another their side-projects.
- A million $ is a very unusually big capital. Side projects are very unlikely to need such big amount of funding just to start-up. People just throw a small capital if needed at all, and if the project self-funds itself, maybe they'll throw the money back.
It may be possible for you later in life. Most bootstrappers have worked up some wealth via traditional methods like savings, home equity, inheritance, and freelance/consulting work.
VC money and accelerators are primarily for people who dont have the wealth to bootstrap, but who are young and willing to take investors on early.
I feel like many would point at all of the technology migrations and view it as a cautionary tale: that if you don't stick with whatever stack you picked, then shipping will be a lengthy ordeal due to migrating between various sub-optimal choices all the time. For example, what if someone just picked jQuery for the front end and stuck with that and tried and rewrites or changes after the launch of the MVP?
On the other hand, this no doubt will let you learn a lot of useful things along the way and possibly make you a better developer, or at least give you an idea of which technologies are nice or easy to use, or suited for certain problems.
It's nice to have that sort of separation between the categories of what you aim to do - to study or to try and ship something, because without you see a lot of cases (especially in indie game development, for some reason) where people feel disappointed due to not shipping anything in the end. There's nothing wrong with unfinished projects that let you learn, or shipping sub-optimal code to get it out of the door and start generating value.
I used to think my goal was to do this and that and change the world etc... I am starting to think that I just like building things and maybe thats OK.
Ah Riot.js, it was like Vue before Vue, yet it never took off for some reason, and it had component templates with locally scoped JS and CSS. I remember mentioning it to a few fellow devs when they were hyping up Vue and nobody ever even heard about it.
I remember this uncanny feeling when I started reading about a new thing in JS frameworks called "file based routing", coming from PHP it was, wait, didn't we just come from this to proper routing, and now this is a feature again.
whenever i tell other developers that i think file-based routing is stupid all i get are blank stares. i guess we'll just have to let the young bucks figure it out again on their own
Technically they didn't put a price tag on the app, the $1 was github sponsor money, so the project was never really designed to make money.
The app itself (Midi editor with piano roll UI) looks great but is instantly made much less relevant if you just install Reaper (and actual DAW, free to try, available at the time all this was developed).
Cool thing, but the moral of the story is: release that toy thing you spent a few weeks on, it's as ready as it ever will be and maybe it'll grow with it's user base.
i've been making websites since 2000. i've seen the internet change and made couple of projects during my life, none took off. as time went, i realized this golden era of online businesses is long gone and everything has been monopolized and bought out by the big tech companies and that money for ads is what matters the most these days. right now i am finalizing my last project that i will ever make, for this reason. it will be 2.5 years of work in march, when i will be releasing it. the only reason i am going for it and i stuck with working on it full-time this whole time is because it is a type of business where customers will come on their own and will want to use it because it provides them with a new sales channel so competition is actually good for them. it flips the usual business model on its head. otherwise i would have quit a long time ago. my hopes up to get it going this year and make 1M in sales next year and hope to be able to focus on growing it for many years to come.
Light text on light background for max pain. Still I will read it though. Frankly, I commend anyone who is willing to work long-term on massive projects by themselves like this. I find it inspiring since all my projects are like this tbh.
Seems like frameworks were a major problem for the project. I get it. Sometimes if you're too early you end up having to build not only your project but a small ecosystem of things to support it.
This resonates with me. I've recently come out of retirement, and really gotten back into programming and product building. I've done this a few times before, but even with experience, I STILL find it hard sometimes to not just dive right in and start building. Mostly, it's because I enjoy it so much.
Now though, things are different. After a throw away project to get back into things, I realized I could very nearly just build first and find product market fit second if only because building is sooo much quicker now.
I decided that over the course of a year I was going to try building 3-6 separate projects, and assume at least one will be successful. My most recent project I realized very late that it's probably going to be very hard to ever make much money; so for now, I'm giving it away for free, just to see how people use it (https://seikai.tv).
I've not just started a new project and for sure this one is going to be a unicorn!
Spent last year working on a side project and assumed I would need this and that in order to launch. But after it was ready to launch, I found out there was no product market fit. I have known about the importance of quickly finding out pmf but still made the mistakes. knowing != doing. We just love building stuff and mistakenly convince ourselves that if I add one more feature, this thing would be ready for launch and take off. But in reality...
It’s a good lesson. We found PMF with a shared google sheet and a bit of data processing behind the scenes. The level of polish I’d come to expect as an engineer at an enterprise company was astronomically higher than what was actually needed for our customers to give us their dollars.
> mistakenly convince ourselves that if I add one more feature,
Even non-technical founders make this error. Everyone wants to believe that "just one more feature" is the difference between make and break.
In my experience reducing features is better to begin with.
>In my experience reducing features is better to begin with.
This is right approach. Lean. If you don’t have PMF, reduce your features until you find it. Pivot. Maybe pivot again. Eventually you’ll find a market to serve. Just don’t fall into the sunken cost fallacy. Time box your market exploration.
How do you mark the difference between pivoting and adding new features?
As a freelance back-end developer with various co-founding experience this question speaks to me. I think it's all a matter of perspective.
Looking at it from a development perspective the two can mean the same thing: we pivot and so we need to add new features.
However, in my experience the key is to look at pivoting from a non-development perspective. As mentioned in parent comments you pivot to find a product market fit. That entails finding your audience and the problem you're solving for them. Those questions do not require a product, but a human understanding. Questions like 'is it actually a problem they need solving, or a slight convenience?' and 'how are they solving their problem without my product?'.
By pivoting quickly in that space you don't get bogged down by technical issues or challenges that don't even matter, and the real solution might be a week's worth of time.
+1
Thanks for posting this insight, because a typical engineer, if they are worth their money, does not like the idea to launch something "unfinished" or "half-baked" or even "not yet perfect", but the business logic behind the MVP (minimal viable product) is clearly correct.
Have to disagree (although this may be a "no true Scotsman" disagreement).
I think a typical engineer is more likely to want to evolve towards mature software in small steps. In my experience the "complete it, then release it with a big splash" approach is more likely to come from marketing. "We moved the CTA up the page a bit" isn't the stuff of press releases.
Wise words man
TFA talks a bit about shiny object/library syndrome. I think there's another good reason to avoid new things: LLMs are better with old stuff.
I can sit down and essentially english-type an app together in javascript or an old version of bevy, but if I ask for new APIs it all falls apart until I have built up sufficient examples in my own code. I've tried giving documentation, etc. It's just easier to version pin something from 2022 and chug along using a less featureful but more productive assisted-coding paradigm.
I spent eight years and I'm around -$150,000 for my main webapp so you're ahead of the curve!
What’s the web app, if you don’t mind sharing the link
I remember the moment when in my last startup, the first invoice was paid - $5. A magic moment. I still remember the name of the customer. The last invoice before exit was $50.000. I remember that customer too.
Interesting, did you pivot / change the target market? $5 sounds more like a consumer product but $50k likely isn't (unless you literally progressed from skateboards to cars like every Agile cartoon wants to make us believe)...
Among other things, I'm working on an elephant hunter type product. Took us five months, but the first invoices were $7k, $3k and now $45k but that doesn't prove much yet.
No we started with too low of a price, and we added enterprise pricing later on. So it was a combination, but we didn't pivot.
How do you guys get funding to build things for such a long time? Rent, food and health insurance in my area costs $50k per year. If feels I have no choice but to earn a salary.
Dropping a quarter of a mil on an app that might not pan out seems out of the question.
Nobody starts by dropping quarter of a mil, you start by dropping $1k and being very frugal, releasing something minimal, seeing how it behaves, and once you have some actual data to work with, you pivot again and again and again.
It's always a huge money sinkohole until it isn't.
Reading the article carefully, one realizes
- this is very likely a side project. Conclusion made by the fact that the author was writing, re-writing and re-writing again the project because of a new 'cool framework' that came out. They were taking their time to do that and doing it repeatedly for years. Proving that releasing the project was not their first concern, nor making money out of it judging from the fact this was not designed to make money but merely having a github sponsor button. Author's main concern seems to having been to just have with it and learning was likely a bigger factor.
- it didn't need funding to startup, as it seems like the only costs were the operating costs which were likely just a server on vercel
Also, to answer your question more thoroughly
- usually people that make projects like these have a main job, which funds in one way or another their side-projects.
- A million $ is a very unusually big capital. Side projects are very unlikely to need such big amount of funding just to start-up. People just throw a small capital if needed at all, and if the project self-funds itself, maybe they'll throw the money back.
It's not really clear from the blog post, but it seems like it was a side project. That's why it took so long.
Personally, I've gotten a lot of mileage out of doing freelance work 2-3 days/week and working on my own projects in the remaining time.
It may be possible for you later in life. Most bootstrappers have worked up some wealth via traditional methods like savings, home equity, inheritance, and freelance/consulting work.
VC money and accelerators are primarily for people who dont have the wealth to bootstrap, but who are young and willing to take investors on early.
I think having a day job was a big part of why that took five years?
From the article:
> Nice to meet you. I'm an engineer who runs a small mobile app development company.
I assume you work in your freetime, besides your actual job.
I feel like many would point at all of the technology migrations and view it as a cautionary tale: that if you don't stick with whatever stack you picked, then shipping will be a lengthy ordeal due to migrating between various sub-optimal choices all the time. For example, what if someone just picked jQuery for the front end and stuck with that and tried and rewrites or changes after the launch of the MVP?
On the other hand, this no doubt will let you learn a lot of useful things along the way and possibly make you a better developer, or at least give you an idea of which technologies are nice or easy to use, or suited for certain problems.
It's nice to have that sort of separation between the categories of what you aim to do - to study or to try and ship something, because without you see a lot of cases (especially in indie game development, for some reason) where people feel disappointed due to not shipping anything in the end. There's nothing wrong with unfinished projects that let you learn, or shipping sub-optimal code to get it out of the door and start generating value.
Good job, though!
2.54:1 contrast for text which spectacularly fails any accessibility specs.
Please don’t do this
Same here but I learned so much I think it was worth it, im literally 4y+ in. I made a platform for my own personal website:
https://arionhardison.com
then Ai education: https://pub.education
then Ai healthcare: https://codify.healthcare
I used to think my goal was to do this and that and change the world etc... I am starting to think that I just like building things and maybe thats OK.
Just visited your personal website, looks like it has a bunch of overflow errors - worth looking into.
I appreciate the grind though
Ah Riot.js, it was like Vue before Vue, yet it never took off for some reason, and it had component templates with locally scoped JS and CSS. I remember mentioning it to a few fellow devs when they were hyping up Vue and nobody ever even heard about it.
Did you also tell them about “server side rendering” capabilities of PHP?
I remember this uncanny feeling when I started reading about a new thing in JS frameworks called "file based routing", coming from PHP it was, wait, didn't we just come from this to proper routing, and now this is a feature again.
whenever i tell other developers that i think file-based routing is stupid all i get are blank stares. i guess we'll just have to let the young bucks figure it out again on their own
I wouldn't be who I am today without wasting years in the bike shed. Kudos!
One time I set out to write an accounting ledger application and towards the end realized I built an ORM framework.
Neither the application nor the ORM lived on. I now start from an existing ORM framework for any new project.
Good learning!
Surprisingly the cost to develop is fairly accurate, using scc's COCOMO
Estimated Cost to Develop (organic) $1,023,233
Estimated Schedule Effort (organic) 13.87 months
Estimated People Required (organic) 6.55
Technically they didn't put a price tag on the app, the $1 was github sponsor money, so the project was never really designed to make money.
The app itself (Midi editor with piano roll UI) looks great but is instantly made much less relevant if you just install Reaper (and actual DAW, free to try, available at the time all this was developed).
Cool thing, but the moral of the story is: release that toy thing you spent a few weeks on, it's as ready as it ever will be and maybe it'll grow with it's user base.
That ain't the moral of the story... It's not even the literal story that they shared
I built a deep search for financial research in 2023 and learned that 2025 would have been the year to launch it.
Sounds interesting, what stops you from (re-)launching it?
Previously:
- https://news.ycombinator.com/item?id=24599679
Thanks for sharing, great result
i've been making websites since 2000. i've seen the internet change and made couple of projects during my life, none took off. as time went, i realized this golden era of online businesses is long gone and everything has been monopolized and bought out by the big tech companies and that money for ads is what matters the most these days. right now i am finalizing my last project that i will ever make, for this reason. it will be 2.5 years of work in march, when i will be releasing it. the only reason i am going for it and i stuck with working on it full-time this whole time is because it is a type of business where customers will come on their own and will want to use it because it provides them with a new sales channel so competition is actually good for them. it flips the usual business model on its head. otherwise i would have quit a long time ago. my hopes up to get it going this year and make 1M in sales next year and hope to be able to focus on growing it for many years to come.
Interesting. Link?
not yet. it is nothing world-changing, just sales platform for digital content creators. something like patreon, teachable, audible...mashed together.
I want to be as cool as this guy.
Light text on light background for max pain. Still I will read it though. Frankly, I commend anyone who is willing to work long-term on massive projects by themselves like this. I find it inspiring since all my projects are like this tbh.
Seems like frameworks were a major problem for the project. I get it. Sometimes if you're too early you end up having to build not only your project but a small ecosystem of things to support it.
Here's the software they ended up making which looks frigging cool: https://signal.vercel.app/
Luckily there is reader mode, the contrast is so low to make it almost illegible.
Is that Signal Vercel MIDI thing something people can use to make music for free?
Yes
yeah, GitHub Sponsors is non-existent, impossible to get any revenues from it
And yet it still hurts significantly less that Patreon
Thats cool.
Cool to read. Thanks.