I will agree with the strategy of separating your product into sub-products, and working on and releasing them one at a time. A single, well-executed feature is often better than many mediocre ones.
Especially as a solo founder (shameless plug: I run https://resend.io), I think this is the best way to both test your assumptions early, and to consistently ship improvements without spreading yourself too thin.
I've taken this approach as I set out to compete with companies with 100s of millions in funding and 100s of employees who had built out very feature rich and elaborate product platforms.
In my specific case, it went something like
1. build a shitty live chat plugin
2. make said shitty live chat plugin good
3. extend previously shitty live chat plugin with shitty
automated messaging capabilities
4. make those shitty automated messaging capabilities good
5. and so on..
In between each step you should try and get people to use it, be shameless. You'll often be surprised that you can find users already at step 1, despite competitors already rocking well-established and mature solutions.
Doing this long enough (I have been going hard for 9 months), all of a sudden you'll find yourself with your own platform, built slowly by stacking one brick on top of another, and sticking to it.
i think the drawback to this approach is that maintenance and just "staying in place" starts to become a nightmare. development is circular in that you have to loop back around and make sure your good live chat plugin even better as time goes on.
it's not just lay a brick and you're done. my experience has been that you either solve a problem that is very single minded (bonus if it's in the consumer space) and tries to solve for one or two problems, or be prepared to face reality in hiring and scaling.
you might be able to compete on some level with the well funded companies, but you aren't going head to head with intercom or hubspot without more resources. not to mention that businesses don't want to deal with companies that don't seem like they have the capacity to support them.
Definitely. You will reach a point where perhaps you will be spending 70% of your time building out novel features, while the remaining time is spent reiterating on your existing features to make sure they stay relevant.
And the beauty of being a solo founder (even more so a digital nomad living sparingly) is that you don't have to go head to head with the giants, even if you were to just tickle them with a stick and steal 0.1% of their customers, you'd be doing very well for yourself.
And since you cannot match their wallet, try to beat them in efficiency. With smart technology decisions, you can maintain incredibly low operational costs, while ensuring massive scalability (shout out to Elixir).
Valid point, to avoid this trap I did a modest amount of initial market research and realized a lot of people were having problems with my competitor's offerings and were actively looking for alternative solutions.
I set out to test this as quickly as I could and just kept going at it when I verified they were willing to backup their frustrations with their creditcard.
The fallacy is when people use the size of a market as support of why they should enter it, sort of like this:
Founder: "We should enter X market! It has $1 Trillion worth of annual business."
VC: "It must be heavily saturated, with mature, efficient companies. Why should we fund you?"
And now is the fallacy - instead of replying with something like "we have better A, we do B differently and we're priced at C," they say "well we don't have to take over the entire market, we ONLY need .001% and we'll be billionaires!"
And the fallacy, more specifically, is similar to an appeal to probability, because using such broad metrics aim to give the VC a false sense of confidence - that even if the founders aren't 100% successful, they only need to be .00001% successful for them to make a killing.
But it still doesn't answer the original question: How does a founder go from 0% to .000001%.
But when you're evaluating the marketplace, it's perfectly reasonable to say "I need x% of the market to break even, y% to earn a profit" and extrapolate from there. The idea itself isn't bad, it's when it's used improperly.
hey your product looks good! any way you could share some info on how long first version took and if you made any money with it (or how long it took to start making money etc)? I find these side project cases very inspirational.
for example my friends brother created http://www.mailaletter.com/ and its always great to talk to him about it. (it was not making him much for the first year or so, but then it kind of exploded when people started using it in a way that he has not predicted. I forgot what it was exactly but something to do with companies needing to mail letters internationally and it being cheaper for them via his site)
If I remember correctly, I pushed the barebones chat plugin out (it was embarrassingly bad at this point) after 1-2 months of development. At that point I was also working part-time and finishing my CS degree, so the amount of time I had to work on it was limited.
Somehow I still managed to convince a few people to use it though
I wish, more like some weird amalgamation of other websites blended together with my caffeine trips and sleep deprivation. I once heard good artists borrow, great artists steal
For all the cries on HN of "ideas are worthless! execution is everything!" people sure do get upset when someone executes a less-than-100%-novel idea...
My trick has always been to solve one of my own problems, and be my own first customer. Then I know it works, and meets the goals of the audience. I figure that if I need the problem solved, so do other people, but even if nobody else ever shows up, I got my own value from it.
The problem is polish, documentation, marketing, promotion.
There's plenty of stuff that i've made that's useful in the form of an inelegant API that i don't mind using. But to build a polished product with documentation, a marketable presentation, analyze what you offer that the competition does not, getting people interested, blogging about it, is quite a lot more perspiration.
Writing a useful MVP is necessary, but often the easiest part. Most ideas dont fall under "if you build it and they will come".
Totally agree. Building a usable, shippable, commercial grade product and actually getting people to pay you money for it is quite an ordeal. An enormous amount of attention needs to be paid to get a product nobody cares about installed, even for free. Even after the sale, you have to provide support which will run at a loss until you reach a customer threshold.
The SaaS and subscription model evens out the revenue spikes, but you still have to make the sales.
A salesman, I am not. I suppose I should learn how to do it, but I don't have much passion for the sales side of business.
This is usually why you need 2 people. Someone to build the product and someone to sell the product. There'd be no Jobs without Woz and vice versa. Exceptions to this are unicorns. It's not surprising that the presence or absence of co-founders is a strong signal to investors.
I thought the only down-to-earth meaning of unicorn was a startup with a $1B+ valuation, regardless of the number of co-founders, no? [1] Your statement "There'd be no Jobs without Woz and vice versa. Exceptions to this are unicorns." seems to indicate a restriction to one founder for unicorns.
No, another common use 2-3 years ago was a single person who could accomplish disparate (founder) roles, such as design + code or sales + code. "Unicorn" is still used for various types of rare events.
Or maybe you could actually just ship a FOSS product so that if people are interested they can hire you or pay you (or your company) to get more good stuff ?
I'm struggling with finding a problem I have myself that isn't already solved a thousand times. As a software developer it's not so easy, as software developers tend to solve their own problems very quickly =)
My hobbies so far haven't translated neatly into side projects, but I guess I just need to get more creative.
The main problem of such a platform would be the signal to noise ratio. I imagine majority of submissions would go in the direction of "faster horses" and "X, but better".
Just make sure you weight the opportunity costs, meaning your time might be better spent on something else. If you are an highly skilled and productive software engineer you are one in a million, and fixing one of your problems, even a very hard one, might only end up being useful for a tiny group of people.
Shameless plug, I just launched an overhaul to a side project today (https://instacalc.com).
The biggest impetus was having a friend using the old version who pinged me with some feature requests. It reminded me that the service can help people I know directly and gave me a huge boost of motivation. If friends and family are using it, you'll want to help them out :).
I started BetterExplained about 10 years ago exactly (wow), just taking some of the notes online. Thankfully they were on evergreen math topics (divergence, flux, gradients... stuff I desperately wanted intuitions for) and it grew from there.
I had been thinking of doing a decade year retrospective on what's worked/not worked in terms of keeping motivation and momentum for the projects (so far, so good). Thanks for the reminder!
Looking forward to the retrospective post! Motivation tends to be highly fluctuating. Perseverance is the key to success. Would love to hear how you maintained a decade long streak.
Found and fixed the bug, should be working now. (For what it's worth, I was using fat arrow functions in javascript, which aren't supported in all browsers yet. Forgot to compile it down to ES2015.)
Limiting the scope can't be emphasized enough if you're married with kids.
I've failed to ship 6-7 side projects because of limits to my free time. The best side project I've successfully shipped, besides blogging, was limited to 2 "features" one of which I already had from a failed project.
So basically, try to group anything into smallest possible self-contained utilities, until you grow a pile of them big enough that your next project can be basically assembled from them...
Ironically, my current side project evolved exactly the opposite way: I tacked on more and more features, and later broke everything apart into plugins once the correct abstraction had emerged.
Devils advocate here, it sounds more like your problem was constantly moving to another side project before completing the last. If you had spent all that time on a single project, how far would it have gone?
I used to be the kind of guy who started a lot of things, but never finished them. I got angry at myself, and built a project with the sole goal of finishing it. The challenge of “just get it done” really put me in the right mindset. Since then I’ve started finishing what I started. Here’s some tips.
If you’re going to try a new to you tech, only use 1 new to you thing at a time. There is nothing wrong with using a technology that’s old. In fact, that’s the best way to finish something. Old technology is googleable, stable, and usually has libraries for everything you want to do. New tech might let you do in 3 lines what old tech will do in 20… but getting those 3 lines of code to work might take more time than just writing the extra code. The next point, elegance does not matter. NO ONE cares about your project. They aren’t going to review the code, so why spend time doing something elegantly? Just get it done.
As mentioned in the article, you really have to realize your limits. At work, when you have a large team, the definition of MVP can expand. When it’s just you, you REALLY need to think about what value you’re building. I’m constantly asking myself “is this thing I’m going to spend today on actually going to be the difference between my product being useful and not working at all”. “Is there a way I can get away with faking, or doing this thing manually”. If you only have a few users, you might not need to automate right away.
One more personal preference, I don’t talk about what I’m working on with friends and family until I’m near done or done. For a few reasons, first if you talk to other engineers, they’ll discourage you. When you propose an idea to another engineer, they’re shoot it down pointing out minor flaws. I used to think, oh that’s useful… they’re preventing me from going in the wrong direction. Upon reflection though, I’m not sure the advice I’ve gotten has always been “useful”, it has made me give up on ideas. Maybe I’m weak willed, but this is what I need to see my ideas get done. If you really believe what you’re building will work, the only person worth talking to are your future customers, if your future customer isn’t interested… that’s actually worth something.
This was a good blog post. I have shipped side projects before. What helps me the most is to always have some really, really tiny incremental goal every week that's achievable. This way, there's always some momentum of sorts, even if some weeks are far less productive than others. It's when momentum dies completely that projects don't come out of the abyss.
I have found the same. Stressing to make massive progress or sneak in a 6 hour session makes me burn out super quickly, and the inertia of starting a bigger feature makes it less likely that it will happen.
I have shipped a few web projects this way and found it's been just as useful for game development. In the rush to see progress I burnt out learning last time, but this time I am making serious progress with just a small task each day or every couple of days.
Also adding minor bugs that are turning into rabbit holes to a backlog for later helps keep me motivated.
Same here. I use a trello board and discipline myself to complete at least one task a day. No matter how small. This usually leads to me getting in the zone and completing a bunch of other tasks. If not, its ok. There's tomorrow.
I find aggressive scope-cutting to be one of the most compelling things about building side projects.
I'm shopping for computer parts at the minute so built a quick app to scan UK shop deals, threw it up at a subdomain of my personal site (plug: http://slackfriday.jhope.ie) and let it go. Over cyber monday and later it got loads of traffic and watching a stupidly simple app do it's job was thrilling and liberating.
Even doing agile and lean MVPs every day at work nothing quite matches the level of focus you can reach when you know your own capacity and have a time-limit. I kind of disagree with the OP in that even if you use tech that you're familiar with and have a fleeting idea it's still worth doing every once in a while to remind yourself why and how people use things.
A great thing about this is that there is no point where it's "done", as long as it has enough content to be useful. As I get more data, it unlocks tons of opportunities for mini-projects. Writing a blog has been a good side-project for the same reason.
I wanted to read this post but I couldn't get past the light grey font which was very hard to read. Illegibly thin and light fonts like this are borderline hostile to users, and frustrate me every time I encounter them.
I'm sorry I have nothing more constructive than that to contribute.
I really like the idea of approaching rapid development like writing an essay or a blog the first time. Just getting all the words out on the paper goes a long way; same thing goes for programming.
I understand your mindset, but sometimes a little bit of planning upfront can save so much time in refactoring. I'm not sure code is analogous to writing save for maybe a choose your own ending type novel. An Essay is essentially a sequential flow of ideas where as a program is more like a tree. Perhaps what you are referring to is rapidly developing the nodes(classes) of that tree without concerning yourself to much with the connective branches between classes. If that's the case then I can see the benefit.
From purely technical viewpoint that is correct and engineer in me agrees with you 100%. However: if you look at the bigger picture you will notice that the feature list is not known in advance. Which means the nice abstraction you made are probably unsuitable and will make repurposing software more difficult, not less. Because nobody knows what the end product will look like, so it pays to ship fast, iterate on product design and refactor / rewrite later.
But I know what you are saying, I have struggles with that inner engineer daily and he just won't shut up. :)
This is my personal experiment to see if I can build and market a full-fledged SaaS tool. It has also been a nice way to pick up a new programming language (Elixir).
I have a lot of unfinished projects. I start working on a new idea, build out some functionality and then the interest fizzles outs and the project is left unfinished.
This time, I decided to take a different approach - I decided to keep publishing the app incrementally. I started off with just a landing page first, last week I added the demo survey. There are a LOT of things left to be done before I can roll out public access to this project, but getting a few beta users has been a nice inspiration to keep me going.
I've really enjoyed this comment thread because I started feeling like everyone was shipping their side projects but me. Turns out I was only seeing the highlight reel. Weirdly, the fact that everyone seems to have problems with this, encourages me to keep trying to work on it.
I agree "Ship it" part.
My previous side projects is always by this styles: "good idea" (1 week) => develop it (2 week) => "not satisfaction" （several days） => abandon => next idea ....
The passion always dispears after one month, so in one month, need ship it.
BTW, the Show HN is really really good channel for every early shipping.
Scope creep is the enemy. I'm a big fan of the minimum viable product idea. What is the smallest thing you can build that lets you quickly make it around the build/measure/learn loop.
One big issue with working on side projects is that you get emotionally attached to it and sometimes it takes over your mind, more than it should. Learning to balance that would help you be at peace at slow speed of the side project, after all it's called side project for a reason.
I have been depending on developers to do the hardcore development (I can do web-coding myself well enough) and are therefore depending on convincing developers to help me.
After a number of attempts at starting various products/services with various levels of success but ultimately fizzling out.
Ex. Weekendhacker have around 8K designers and developers subscribed but it kind of died out, because the time i spent vs. any income I made was not making sense. I haven't killed it but it's basically in hibernation until I figure out what to do with it. It was a really frustrating to see something like that die out with such high hopes of starting an actually community.
However I finally managed to launch something that is generating growing side income for me year over year, which I can control the progress of and which allow me to expand slowly but surely.
Now GhostNote is only the start of something much bigger I am building but it allow me to control the scope and slowly expand what I am doing while still enjoying it as an added bonus I am making good money.
You should ask yourself the questions like.
Why am I building what I am building?
Is there a simpler way to do what I want to do. (Ex. could it just be email to start with? Weekendhacker was.)
Is this really what I want to spend my time on?
Does the world really need this?
But most importantly you should never give up, sooner or later you you wil find something as long as you make sure you don't spend too much time on each.
I have literally hundreds of ideas, a whole graveyard of almost implemented projects
Just keep trying new stuff, make new alliances with developers. Do several things at once if you have to. But if you want to make money with your side project don't be too attached.
Khan Academy history (https://en.wikipedia.org/wiki/Khan_Academy):
The organization started in 2004 when Sal Khan tutored one of his cousins on the Internet using a service called Yahoo Doodle Images. After a while, Khan's other cousins began to use his tutoring service. Because of the demand, Khan decided to make his videos watchable on the Internet, so he published his content on YouTube.[9] ...The critical acclaim and the positive responses of students prompted Khan to quit his job... and focus on the tutorials
If your goal is to eventually make money from the project then sure. There is value in shipping things only that they get used, open source comes to mind.
I agree with this sentiment. Nothing motivates me more knowing there is potential to make money on it. Then again there are those side projects you do just for fun but those are ones I also don't invest tons of time on.
The biggest problem I've had with side projects in my past jobs was that my employment agreement was all encompassing and I would require my employer's explicit permission to release the project. So I pretty much stayed away from them except as purely throwaway learning exercises.
i think reid hoffman's quote (linkedin founder) sums it up best, "if you're not embarrassed with the first version of your product then you've launched too late."
i have seen many posts about mvp and narrowing scope here--all right on the money.
some other things that have worked for me, i'm the world's biggest procrastinator and i have literally 20-30 side projects that i've started for some time, was extremely passionate about, and then moved onto the next big thing, but i've recently had a few projects that i went deep on and actually got out, even hoping to build a business out of.
i've also found that the technology stack is not that critical, as a perfectionist i want to create a kickass platform that's easily maintainable, beautifully coded, using all the right tools that can meet billions of requests per day from the start, easy to deploy, automated, etc, but that typically just leads me down a huge rat hole. if your energy is finite (for me it is), you should focus all of it on getting your stuff out the door as quickly as possible, getting it in front of potential users because often times what you think is a great idea is raw and will need tuning. make things functional, able to showcase your main idea (or a particular use case), don't have to have all use cases fully done. get it out there and iterate. i'm certain that there are people that can make all the right technology decisions from the get go to support billions of requests per day, fully automated (if you are one of these, please email me right away!) but you're solving the wrong problems, if you want to get a side project or business out there, go build it, get it out there and then iterate, and iterate fast.
for the sake of argument, probably side projects like tools or libraries, these are a bit different in nature, you probably want to choose the right technology stack, etc. but if you want to build a business out of your side project, then don't dwell on this too much, use what you're familiar with that can give you the quickest turnaround, there will be pains with whichever tech stack you choose, some more than others, but it will pale in comparison to the roadblocks in front of you to build something into a business.
for one of my recent projects, i use sqlite3 for my relational database, i don't even want to spend all the 30 minutes or whatever to set up postgresql, it's to that level of scope reduction. when users grow, then i'll spend the time to upgrade and add backups, etc.
I'm working on a DITA (to PDF) renderer [1] based on rinohtype [2]. About a year ago I was in a startup coaching project. I was advised to put out an MVP ASAP. Since then, I've worked full-time on the project and only now I'm releasing what I believe is an MVP. One year ago, my product was functional, but it didn't allow easily styling the output PDF. I believe this is the feature that differentiates it with the competition. I feel that, without this feature in place, my product wouldn't offer anything interesing.
I could have also released an "MVP" much earlier, but say it couldn't render tables. Who would've taken it seriously then? Even if I added this feature at a later point, how many of the people that tried the first version would bother checking it out again?
For some (new) markets, I'm sure you could crank out an MVP in a month. But for existing markets, there's the established competition that sets the bar, no?
no doubt, you raise an excellent point--mvp is somewhat vague, hard to quantify, and there's no universal answer so unfortunately the answer is it depends on the idea/product/lifecycle. chances are if you're still trying to get a feel for a market, this could be an entirely new market, one that doesn't quite exist, or an existing one with incumbents, like airbnb as an example, an mvp could be like a simple mobile app with login (not even oauth based for facebook/twitter/google), listings, a way to book, and bill. don't implement user feedback on listings where they've stayed, don't implement icons for users, forgotten password is an email to support, etc, i'm sure you could find a million things that are needed, but what are the essentials for getting people to use your app satisfying some specific needs (crashing at a complete stranger's place). each feature doesn't really need all the bells and whistles, enough to get people to start using the basics. your assumptions and hypotheses about how the market would leverage this tool could be entirely off, so you might need to change direction (pivot more or less) and you'd need to get to this conclusion asap, sooner rather than later, etc. if you spent a year coding something you think would be perfect for a market you are defining or discovering, this could be a large waste of time, so fail fast as they say.
in your case, you seem to be quite clear about what you need, what the competitors have and don't have. but let me play devil's advocate because i don't know how much effort "[rendering] tables" would take or how much you've put in the past year, but let's just say you could put something out there in 6 months time as opposed to 12 months time, it probably will have some table rendering, not 100%, but do you think that would be advantageous or not?
thanks for the footnotes, much appreciated and good luck with your app!
>> "if you're not embarrassed with the first version of your product then you've launched too late."
Carmack said it as well: Michael Abrash and I once had a discussion kind of justifying ourselves. We said, "Well, if we shipped on time, we probably weren't ambitious enough."
I like it, except for the part about "refactor later" in my mind the best way is refactor "first" so that adding your feature is "easy"...though I don't always follow my own advice with hobby projects LOL. Don't let technical debt subsume you, though, fight back eventually.
I do like the part about focusing on "the next feature for your customer" though, customer centric can take you far, that's good...most/many hobby projects focus on only the next "feature for me" and never get around the marketing/polishing side of things, whereas focusing on customer-ish stuff encourages the latter, the latter being 80% of success typically overall (or get a partner to do that part, the common successful way there...)
I just want to say it is OK to give up from time to time. I had a serious side project I worked on for 2 years. Sometimes you need to cut your losses. I was able to use
a product that cost me $100, though it doesn't work exactly as I want, it does the job. So just ask yourself, is this worth it?
If you need some additional motivation, I recommend Just F*cking Ship (https://unicornfree.com/just-fucking-ship/). It helped me get out of a rut and focus on what's most important.
I suggest that instead of this approach, you take an approach of starting by overengineering it and making it absolutely perfect in every way - then just ship the part of that you manage to actually do.
Sometimes the best way to write a short story is to write a three-volume epic.
I think I'd need to see some evidence that that is a more effective strategy than starting small.
My biggest enemy is always analysis paralysis. The bigger the project, the less likely I am to ever even start, much less finish anything. Likewise, when I do start, if the scope is too big, I'll flit from concept to concept never really finishing any of them. But, when I have a very small, concrete, and actionable item, I can knock it out in no time...it almost doesn't even feel like work sometimes.
I don't think the "overengineer it" approach could ever work for me.
>I think I'd need to see some evidence that that is a more effective strategy than starting small.
"To begin with, GNU will be a kernel plus all the utilities needed to
write and run C programs: editor, shell, C compiler, linker,
assembler, and a few other things. After this we will add a text
formatter, a YACC, an Empire game, a spreadsheet, and hundreds of
other things. We hope to supply, eventually, everything useful that
normally comes with a Unix system, and anything else useful, including
on-line and hardcopy documentation."
Looks like he did all that. (Mostly in the form of Emacs). Anyway it's hard to get more ambitious than a list like that. Other early announcements of effective projects were the same - very large vision.
Counter-argument: GNU was a copy of an existing reasonably well-engineered and well-documented solution, in almost every piece. Sure, GNU utilities often improved or extended the standard, but the design already existed. Further, GNU is a system of many discrete parts. Each piece could be built by an individual without tight interdependence on other pieces. That's an MVP. Small, useful, pieces, that add up to something bigger.
I believe GNU is evidence of the opposite point you're trying to make. Unless your point is actually "think big, but build in small, manageable pieces", but if that's your argument, that wasn't how I understood it.
Ambition is not antithetical to building in small pieces. In fact, I think most people have to start small.
While we're on the subject, I'll quote another kinda famous first announcement:
Hello everybody out there using minix –
I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I’d like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).
I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I’ll get something practical within a few months, and I’d like to know what features most people would want. Any suggestions are welcome, but I won’t promise I’ll implement them :-)
>Unless your point is actually "think big, but build in small, manageable pieces", but if that's your argument, that wasn't how I understood it.
Unfortunately, that was exactly my point!
I've made a modification to my original comment: I've italicized the word "approach" now, to emphasize that this is just the kind of attitude you should have.
Basically, my main point is that if you don't overengineer a perfect and very ambitious solution, you're unlikely to ship anything - but if you do, then you are more likely to ship it, even though obviously you will start shipping some small part only.
It would be interesting if there were some way to do a double-blind experiment, giving a thousand people a couple of different approaches and to see who ends up shipping :).
in short, I'm saying, by targeting something huge and overengineered, you are more likely to ship something (anything at all) - versus targeting a minimum; which leaves you less likely to ship anything worthwhile. I am not saying by targeting something huge and overengineered, you are going to ship something huge and overengineered. Rather, that you will end up shipping a small part of it. (And that this approach is better than the alternative.)
I'm not convinced that what you write is the case. There are lots of small projects that are never shipped. But as a percentage, is it higher or lower than the percentage of over-engineered pieces of perfection do not have any part of it ever shipped?
Maybe the "tenth callback" is just a bad example, but I would emphasize not doing anything that will sap your motivation on the path to shipping. For me, that's having to deal with brittle code when I'm constantly reevaluating the requirements.
I really enjoyed reading this. I have been stalling on a side project for some time and this article has given me some ideas with how to proceed. Specifically narrowing down the requirements.
Sorry but those animated gifs distracted me from reading. Normally I will scroll things like that off the page but when they come so close to each other all I see is the movement.
Personally, I found them to be topical and slightly more engaging than text. They appear at the top of each section, so I thought of them as helpful summaries of each section as well as comic relief. I felt like they encouraged me to finish the next section instead of leaving the page early.
Especially as a solo founder (shameless plug: I run https://resend.io), I think this is the best way to both test your assumptions early, and to consistently ship improvements without spreading yourself too thin.
I've taken this approach as I set out to compete with companies with 100s of millions in funding and 100s of employees who had built out very feature rich and elaborate product platforms.
In my specific case, it went something like
1. build a shitty live chat plugin
2. make said shitty live chat plugin good
3. extend previously shitty live chat plugin with shitty automated messaging capabilities
4. make those shitty automated messaging capabilities good
5. and so on..
In between each step you should try and get people to use it, be shameless. You'll often be surprised that you can find users already at step 1, despite competitors already rocking well-established and mature solutions.
Doing this long enough (I have been going hard for 9 months), all of a sudden you'll find yourself with your own platform, built slowly by stacking one brick on top of another, and sticking to it.