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.
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.
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...
>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.
Pivoting involves picking a different problem to solve. Or who to solve it for. Or rarely, a radically different way to solve it (usually involving starting anew).
Features and other product work is tweaking on the solution side, assuming there is nothing wrong with the chosen problem.
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.
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.
It is definitely hard to break the "but... I'm a professional" mindset. It is good to remember that your code isn't you. If you get PMF, just re-write everything from scratch.
As an argument on the other side - so long as you're making enough to live comfortably enough, then there's no real need to abide the business logic though, even if you think it absolutely does maximize income in the longrun. If you spend years working on something and it turns out somehow nobody else likes it, well at least you have something that you're presumably satisfied with, and you often learn an immense amount in process.
Careers that aren't quite so commercialized regularly carry out this process. The obvious example being writers where you may spend months/years writing a book only to find out that nobody wants to publish it. Or perhaps you ultimately just don't like it. I know Andy Weir (of "The Martian" fame) wrote about 75,000 words on his next novel before deciding he just didn't like it, and scrapped the entire thing.
Yes, agree. Definitely, follow your heart. My comment is aimed more at the situation where your curiosity does lead you to a desire to create a successful product.
Because the content has high value compared to all the ChatGPT written slop.
It is well researched use-cases, based on actual research papers, and includes implementations and solutions. Also highlights problems. For the first 3 months the posts are free.
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
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.
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.
Networking, in the broadest sense of the word. Gone to tech meetups, gotten to know a lot of people in my particular niche (sound and image processing).
Surely a side project. It is actually really good too.
There is quite a problem with creativity being stifled by the infinite possibilities of a modern DAW.
Everything feels super fast and responsive on it too. I am going to spend a good amount of time in this.
Helio is a desktop app that is down this line but more complicated and not as easy to use. This just all makes sense if you know how a piano roll is going to work.
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.
- 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.
How do they get funding? They're already rich. Every single one of them, even if they haven't yet earned a personal fortune, ask them what their parents do. Find out they either own a Carl's Junior franchise or a semiconductor company. NBD, just build things, amirite?
To be fair, even if you only work in software you already have a leg up (not as much as someone born with a silver spoon in their mouth) both because the salary is pretty good, and because you're used to designing, programming, debugging, and documenting.
I’d noticed it as 2.58 in Firefox’s dev tools, so when you say 2.54, I’m curious. #ab9ea2 on #ffffff. https://webaim.org/resources/contrastchecker/ says 2.57, https://contrast-ratio.org/#%23ab9ea2-on-white says 2.57 and on hover expands that to 2.5785676343306743. I presume Firefox is rounding, while the other two are truncating. Truncating actually feels more useful for how people are too likely to use such things—taking values as low as they can while still complying.
The new, superior method is https://www.myndex.com/APCA/. It yields an Lc of 50.4, which is (as you’d expect) wildly unsuitable for body text.
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.
The point is to make something stripped down compared to Reaper. The problem with modern DAW software is you end up getting lost in the infinite possibilities.
It is counter intuitive but constraints are a known aid to creativity.
If you want to write notes, this is the way to do it. Otherwise you get lost picking effect,synths, samples , on and on and on.
The idea would be to write the notes then you take the midi into something like Reaper.
If the author reads this what it really just needs is a microtuning import for scala scl files. There is absolutely nothing that can do this easily for non 12 tet music and just have the notes in front of you without much else.
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.
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.
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!
100 comments
[ 4.8 ms ] story [ 183 ms ] thread- https://news.ycombinator.com/item?id=24599679
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/
Neither the application nor the ORM lived on. I now start from an existing ORM framework for any new project.
Good learning!
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.
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.
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.
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.
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.
Careers that aren't quite so commercialized regularly carry out this process. The obvious example being writers where you may spend months/years writing a book only to find out that nobody wants to publish it. Or perhaps you ultimately just don't like it. I know Andy Weir (of "The Martian" fame) wrote about 75,000 words on his next novel before deciding he just didn't like it, and scrapped the entire thing.
Estimated Cost to Develop (organic) $1,023,233
Estimated Schedule Effort (organic) 13.87 months
Estimated People Required (organic) 6.55
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.
I appreciate the grind though
https://news.ycombinator.com/item?id=37808115
Dropping a quarter of a mil on an app that might not pan out seems out of the question.
It's always a huge money sinkohole until it isn't.
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.
There is quite a problem with creativity being stifled by the infinite possibilities of a modern DAW.
Everything feels super fast and responsive on it too. I am going to spend a good amount of time in this.
Helio is a desktop app that is down this line but more complicated and not as easy to use. This just all makes sense if you know how a piano roll is going to 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.
How in the goddamn fuck do you work up an inheritance?
> Nice to meet you. I'm an engineer who runs a small mobile app development company.
- 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.
There are plenty of apps you can build that don't require any upfront costs.
I'm working on an app that runs entirely on a consumer PC.
To be fair, even if you only work in software you already have a leg up (not as much as someone born with a silver spoon in their mouth) both because the salary is pretty good, and because you're used to designing, programming, debugging, and documenting.
Please don’t do this
The new, superior method is https://www.myndex.com/APCA/. It yields an Lc of 50.4, which is (as you’d expect) wildly unsuitable for body text.
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.
The point is to make something stripped down compared to Reaper. The problem with modern DAW software is you end up getting lost in the infinite possibilities.
It is counter intuitive but constraints are a known aid to creativity.
If you want to write notes, this is the way to do it. Otherwise you get lost picking effect,synths, samples , on and on and on.
The idea would be to write the notes then you take the midi into something like Reaper.
If the author reads this what it really just needs is a microtuning import for scala scl files. There is absolutely nothing that can do this easily for non 12 tet music and just have the notes in front of you without much else.
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!
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.
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!