> Yes, you guessed it, let's go with Electron and CoffeeScript.
> The main tech stack is still CoffeeScript, but we changed the UI framework from React to Riot.js.
> I've installed Babel, Mocha, ESLint, and added libraries via npm.
> I've rewritten my entire code base from CoffeeScript to ES6.
> The introduction of MobX, a state management library, and the introduction of Flow, a type checking system.
> So I rewrote everything in TypeScript, including my own libraries.
> Anyway, I'll be replacing my own components like Button and Toolbar with Material-UI ones.
> It's time to rewrite everything to styled-components.
> It's time to rewrite everything to useXXX.
No wonder why these software projects (personal as well as professional ones) are 6 years late. It may be a good learning experience, but a terribly inefficient way of developing software.
Exactly. Using a boring stack like jQuery would have been already good enough to let them concentrate on solving business problems rather than stack ones
> Using a boring stack like jQuery would have been already good enough to let them concentrate on solving business problems rather than stack ones
One quick look at the UI (https://signal.vercel.app/_next/static/media/screenshot.dc00...) and with the experience of developing bigger stateful UI applications with jQuery (and Backbone.js, and AngularJS, and React, and...), I would wager that if they were using jQuery at this point, they'd be fighting way more than they ended up doing.
I agree with grand-parent though that it seems like an excessive amount of rewrites, don't get me wrong.
12 years ago I released v1.0 of the full stack open source platform for anyone to use to quickly put together pretty much anything on the Web in a standard way, and focus on actually growing it, but I have faced opposition from day 1, on weird bases
First, I was told that the name of my library “conflicts with the excellent Q.js library for promises” and that no one was going to take a look. Well, promises are built into browsers now. But I renamed it to Qbix Platform back then.
Then people told me that it doesn’t use the latest React / Angular / Web Components / Typescript whatever, and looks old. On the PHP side they told me that it looks like ancient code because it’s compatible with PHP 5.2 and told me I must break compatibility.
Then I was told that PHP is a stupid language to build a platform in and I should use Go or Rust if anyone would take it seriously.
Every step of the way, I was citing massively adopted projects like Wordpress, Joomla, Drupal, the number of servers running PHP and my vision for everyone to “just run it” https://qbix.com/ecosystem
But the signal to noise ratio was very high. Some people here on HN started telling me that they didnt want to read that page because they found mentioned a token. But the token is optional and there only for settling micropayments and hosting companies to make money from customers globally. It is solving the payments problem on the web and getting rid of the stupid paywalls. It is solving the problem of monetizing digital content like open source software, journalism etc. Which have corrupted journalism.
In short, it’s been a lonely experience. Many times people are married to the latest fads or taboos and unwilling to even read what you wrote (unless you remove all mention of a token and add the latest framework du jour).
Here it is, if you want it, it’s free and open source btw:
Web devs specifically seem to be especially prone to inheriting biases from more senior devs that they've worked with, to the point that they spout things like "php is terrible and no one should use it" or "jquery is bloated and useless" without actually having used the technology they're rallying against. Or sometimes they'll maybe have messed around with a poorly written legacy application, or they'll go through a tutorial.
I actually partially blame xkcd for people spontaneously getting these kind of trendy opinions. If I had a nickel for every time a junior dev quoted that 99 problems regex comic to my I'd have like... a few bucks.
Things are outdated when they no longer have use do to their age, they aren't outdated just because there's something shinier.
Exactly. The one thing I learned about web dev in 10+ years is, all (or most of) the opinions are wrong.
Where we were in the early 2000s wasn't bad, it was actually pretty slick compared to all the "shiny" we have today.
There will always be problems, but the idea that to solve the problems we should use Yet Another Cool Library/Language is just incorrect. Sometimes its good to refactor/rewrite, but often the rewrite is just as bad (or worse) as the old thing. You should have a very compelling reason to do so (at least for large scale rewrites, removing tech debt is OK).
Some people see a new project as a new opportunity to get to use new tools and processes. They get wrapped up in that more so than in the delivery of the product. Others see a new project as an opportunity to hone existing skills in their current set of tools and processes. The latter group tend to deliver a much higher-quality project on time and budget.
Exactly why I have zero regrets going native on macOS. Yes, Xcode isn't the best to put it mildly and SwiftUI is still maturing.. but I am so glad I don't have to deal with the modern web stack. Daily smiles instead of facepalms, most of the time!
No one "has to" rewrite just because they're building on the web. Coffeescript was a bad bet but other than that all of the technologies listed there would have been fine for many years to come without a rewrite.
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.
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.
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.
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.
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 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.
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.
- 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.
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.
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.
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).
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.
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.
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 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.
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!
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.
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.
Really good writeup and insights, thanks for this.
A friend of mine convinced me to enable kind of "donations" if you will for a free macOS app I've made a some time ago. I was not really trying to sell it or anything as it's a simple tool which you setup once and then that's it. But I figured that some might want to support my work and so I setup a Gumroad page with a suggested price of $2.99 and kinda forgot about it. The first $1 email that came through that felt very validating
I use boring stacks in all my software development including jQuery, also 5 years programming and not a dime of revenue. American software development not easy. Even though I offer free account, how messed up is that.
I love reading posts and comments like these, as it gives me better insights and questions what I have been doing wrong as I can relate to this shiny new attachment syndrome very much myself.
Seems like a solid app. I haven't evaluated online music software but this is a good first experience, for me. I appreciate that I can try it without signing in.
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.
when I got my first apartment that had its own clothes washer and dryer, the first time I found a $1 bill in the dryer with my clothes, I put it in a frame and hung it on the wall!
> The main tech stack is still CoffeeScript, but we changed the UI framework from React to Riot.js.
> I've installed Babel, Mocha, ESLint, and added libraries via npm.
> I've rewritten my entire code base from CoffeeScript to ES6.
> The introduction of MobX, a state management library, and the introduction of Flow, a type checking system.
> So I rewrote everything in TypeScript, including my own libraries.
> Anyway, I'll be replacing my own components like Button and Toolbar with Material-UI ones.
> It's time to rewrite everything to styled-components.
> It's time to rewrite everything to useXXX.
No wonder why these software projects (personal as well as professional ones) are 6 years late. It may be a good learning experience, but a terribly inefficient way of developing software.
One quick look at the UI (https://signal.vercel.app/_next/static/media/screenshot.dc00...) and with the experience of developing bigger stateful UI applications with jQuery (and Backbone.js, and AngularJS, and React, and...), I would wager that if they were using jQuery at this point, they'd be fighting way more than they ended up doing.
I agree with grand-parent though that it seems like an excessive amount of rewrites, don't get me wrong.
12 years ago I released v1.0 of the full stack open source platform for anyone to use to quickly put together pretty much anything on the Web in a standard way, and focus on actually growing it, but I have faced opposition from day 1, on weird bases
First, I was told that the name of my library “conflicts with the excellent Q.js library for promises” and that no one was going to take a look. Well, promises are built into browsers now. But I renamed it to Qbix Platform back then.
See for yourself LOL: https://news.ycombinator.com/item?id=6053211 and https://news.ycombinator.com/item?id=6053296 (2013)
Then people told me that it doesn’t use the latest React / Angular / Web Components / Typescript whatever, and looks old. On the PHP side they told me that it looks like ancient code because it’s compatible with PHP 5.2 and told me I must break compatibility.
https://news.ycombinator.com/item?id=35897369 (2023)
Then I was told that PHP is a stupid language to build a platform in and I should use Go or Rust if anyone would take it seriously.
Every step of the way, I was citing massively adopted projects like Wordpress, Joomla, Drupal, the number of servers running PHP and my vision for everyone to “just run it” https://qbix.com/ecosystem
But the signal to noise ratio was very high. Some people here on HN started telling me that they didnt want to read that page because they found mentioned a token. But the token is optional and there only for settling micropayments and hosting companies to make money from customers globally. It is solving the payments problem on the web and getting rid of the stupid paywalls. It is solving the problem of monetizing digital content like open source software, journalism etc. Which have corrupted journalism.
In short, it’s been a lonely experience. Many times people are married to the latest fads or taboos and unwilling to even read what you wrote (unless you remove all mention of a token and add the latest framework du jour).
Here it is, if you want it, it’s free and open source btw:
https://github.com/Qbix/Platform
I actually partially blame xkcd for people spontaneously getting these kind of trendy opinions. If I had a nickel for every time a junior dev quoted that 99 problems regex comic to my I'd have like... a few bucks.
Things are outdated when they no longer have use do to their age, they aren't outdated just because there's something shinier.
Where we were in the early 2000s wasn't bad, it was actually pretty slick compared to all the "shiny" we have today.
There will always be problems, but the idea that to solve the problems we should use Yet Another Cool Library/Language is just incorrect. Sometimes its good to refactor/rewrite, but often the rewrite is just as bad (or worse) as the old thing. You should have a very compelling reason to do so (at least for large scale rewrites, removing tech debt is OK).
I am guilty of trying to keep up with the buzz like learning Rust even if I don't need it (get by with JS/Python/C++)
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.
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.
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.
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
Neither the application nor the ORM lived on. I now start from an existing ORM framework for any new project.
Good learning!
Dropping a quarter of a mil on an app that might not pan out seems out of the question.
- 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 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?
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.
> Nice to meet you. I'm an engineer who runs a small mobile app development company.
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.
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!
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!
https://news.ycombinator.com/item?id=37808115
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/
Estimated Cost to Develop (organic) $1,023,233
Estimated Schedule Effort (organic) 13.87 months
Estimated People Required (organic) 6.55
A friend of mine convinced me to enable kind of "donations" if you will for a free macOS app I've made a some time ago. I was not really trying to sell it or anything as it's a simple tool which you setup once and then that's it. But I figured that some might want to support my work and so I setup a Gumroad page with a suggested price of $2.99 and kinda forgot about it. The first $1 email that came through that felt very validating
- https://news.ycombinator.com/item?id=24599679
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.