> I kept finding myself using a small amount of the features while the rest just mostly got in the way. So a few years ago I set out to build a design tool just like I wanted. So I built Vecti with what I actually need...
Joel Spolsky said (I'm paraphrasing) that everybody only uses 20% of a given program's features, but the problem is that everyone is using a different 20%, so you can't ship an "unbloated" version and expect it to still work for most people.
So it looks like you've built something really cool, but I have to ask what makes you think that the features that are personally important to you are the same features that other potential users need? Since this clearly seems to be something you're trying to create a business out of rather than just a personal hobby project. I'm curious how you went about customer research and market validation for the specific subset of features that you chose to develop?
I think a successful product strategy can be "build something you love, see if others love it too". If that's enough customers, you can judiciously expand out from there. The "fail honestly" method.
This is the best way to build products imo. I'm like this, and I've been accused of being very "vibes-based." However, that's a way more tractable way of shipping stuff instead of "well Jim said he wants X, but Amy said she wants Y" so you end up just kind of half-assing features because you think they might get you users, instead of just being passionately all-in into a very defined product vision (which is a very Jobsian way of doing things).
It's also easier to run a feedback loop. If you implement Y, but Amy doesn't give you $5 a month, what are you going to do? Knock on her door? Users have no idea what they want half the time, anyway.
If you build a product and no one cares, it bruises the ego a bit more, sure, but if you self reflect, you can eek out your own bad assumptions, or bad implementation, or maybe a way to pivot that keeps your product ethos.
Good taste is an incredibly powerful differentiator in competitive markets like software. Seems like there’s 3-5 decent choices for darn near anything I need, and usually 1 smaller team has the product that stands head and shoulders above the rest.
Second, if you have the feature that people need or a service or network effect, they will suffer through a bad app - see every Electron app ever.
That “smaller team” may not be around in a year and if you are lucky, you’ll get an “Our Amazing Journey” blog post. Does this product export to a format that my design team can import into Figma if this product goes tits up?
If you want to do the proverbial “moving upmarket” then yeah you’re going to have this and a lot of other problems. Taste does not sell (let’s be nice and add “on its own”) in that segment.
If ten people make focused tools covering different 20% subsets of the giant ones, there's a good chance of having a choice that matches what any given customer wants. And for most customers, that's going to be a better match than a big tool that does tons of other stuff they didn't want.
That is the alternative timeline for software I always wanted to live in, both as a user and as a developer. Make it 100 different tools instead to make it even more likely that there is a close enough match.
Games are closer to that than any other type of software even if they tend to cluster around popular genres and styles a bit much.
If you give people a limited set of tools they quickly improve until then they need (well, want) different tools. In order to keep your customers you'll inevitably end up adding new things.
I don't know anyone that doesn't use a combination of at least one simple, one feature laden, text editor. Most of us via notes apps, etc., routinely move between a range of text complexity, suitable to a range of things we want to write.
Having the simplest to the most powerful apps be consistent between each other, wherever they have feature commonality, would be really nice.
Especially when, who the heck has time for trying out a dozen products? That's at least a full day of work, which probably costs more than the software itself.
No, you just read a few reviews to find the best full price option and best budget option and figure out if the budget does what you need or not. And often go for full price just because you don't even know what features you'll need in 6 months which you don't need now, so safer to just learn the option that is the most future-proof.
You're right. Even across stuff I _really_ use it's hard to bring myself to try.
Anecdotally I haven't tried Codex and use Claude Code. The day I try Codex will be when I hear from my friends/communities that it's much better.
Same for IDEs, STT tools, etc
I dunno. I get that we have different needs, but I enjoy testing out new productivity tools. I'm sort of a productivity-software-junkie. I don't use almost any of the things I try, but I enjoy exploring the market.
Then again, I do this in my free time. At work, I rarely deviate from what is provided and the handful of things that I explicitly added.
This post is about some highly interactive software with a lot of design decisions, and this thread is about finding whether or not your 20% feature niche is supported.
Let's be real, unless some soul somehow had the same 20% as yours and left a review somewhere, you won't know if the features you need, or their implemention, fit your need until you try.
Which is where the bulk of the other 80% of features come from. It’s a cycle.
You start as you describe, you expand, you end up with this enterprise monstrosity, everyone using a different 20%. New tool comes along, you start as you describe…
> Joel Spolsky said (I'm paraphrasing) that everybody only uses 20% of a given program's features, but the problem is that everyone is using a different 20%, so you can't ship an "unbloated" version and expect it to still work for most people.
To me this is an argument for more apps that do less extremely well instead of a handful of apps that do everything poorly. There's nothing wrong with a tool that's honed for very specific user. They'll never hyperscale, but that's also fine.
Or then again maybe they can. Google Docs is plenty popular despite being closer to WordPad or TextEdit in terms of functionality than it is to MS Word.
"I'm a developer who hates your decision to kill that tech. Can you please talk about your shitty adventure before you became CEO of this company cause I want to embarrass you?"
Then Steve Jobs gives one of his most memorable statements about building good products while ignoring the taunt.[0]
Every now and then I stumble on video game developers who have been chugging along for many years, even decades with a handful of dedicated fans. They make obscure niche games that play so well into that niche that they can sustain themselves. Honestly this is something I'd aspire to get to eventually, building a niche product that I love and that just enough people love that I could live sustainably on it, not trying to please anyone but a little collective of people who all agree on what the product should be.
This is a far bigger small world than some might expect. The number of devs and games he's referring to numbers well into the thousands. A quick search [1] shows more than 4 games are released per day on Steam which will go on to earn more than $50k in revenue, so about 1500 per year.
It's wild - I'm a big gamer but I strongly doubt I could even list 1500 games across all systems and time. And that many games make $50k+ each year.
It's crazy! I don't think anyone in my sphere is some hardcore fan of a niche game. But then I stumble on them in the marketplace or watching some GDC talk and it's like, wow this solo dev has been making this obscure series of games for 20 years and they live comfortably (but not extravagantly) with their family. Good on them!
I'm really just describing the long tail at this point. Gives me hope that maybe I can find that product before getting to retirement age.
A quick web search suggests that you are probably paraphrasing a newsletter [1] that Joel Spolsky published in 2001. He was talking about software like Excel (of which he was the Product Manager) and Word. Maybe a tool that is more focused on a narrower task (like UI design) can be less "bloated"?
Not just that, it was Excel a quarter of a century ago.
I am not even sure it was still true by the time her wrote it. It think that there is a set of core features (laying out stuff in a table, simple formulae) and some very commonly used features (e.g. graphs, data filtering) and a long tail of less commonly used advanced features (pivot tables, database like formulae like VLOOKUP).
Its more like 80% of users only use the same subset. Less commonly used stiff is important to the people who do use them, so you need it to sustain the network effects and enterprise sales.
Agree. This quote is being used out of context here. Niche software can and does succeed especially when it’s only supporting a single dev. This isn’t trying to dethrone an adobe product, or doesn’t need to.
A tool focusing on design is not “niche software” - every company of any size has designers. It’s trying to get professionals to use their software instead of Figma. Why would I move my team from an industry standard that they know or would be willing to learn because they know it will be important at their n+1 job?
Why did they move to figma from adobe? There’s tons of purpose built design software. I use a few different tools just for pixel art recently as I’m designing a game. I could use adobe or probably figma but this purpose built software made it super easy to focus on my one single design goal.
What you’re saying is basically a majority of SaaS shouldn’t exist because it could just be an excel spreadsheet. Why would anyone pay for a subscription or something when they already pay for excel right? Problem is spreadsheets are a blank canvas and can be difficult for people to build. Just like a design software like adobes and figma. This product is trying to focus on one particular use case of design software and simplify it. It’s not a horrible idea and can exist in the market. I’m not sure it will succeed but conceptually it’s not destined to fail for the this reason. I think you need to also define what success means. For a single dev, could just be a thousand paying users. He’s not necessarily trying to be figma.
My most successful company was a tool that focused on 10% of a ERP feature. One that I had used and implemented at corporates but knew ERP vendors were selling hard for having 100s of features of which I only cared about 20%. Not everyone cared about those same 20% but I found enough people that did and liked my opinionated take on the software. It would have never worked if I had this mindset.
Figma was a completely fresh take on UI design software and it was the best thing available at the time. It made incumbents look lazy.
Vecti looks like a Figma clone if its landing page is anything to go by. You're not going to have an easy time convincing people to migrate from Figma to a clone.
Right but we’re debating different points. I’m saying there’s room for non-feature complete products in the world, generally it’s not all or nothing. You’re saying this product specifically isn’t going to be successful.
I’m not saying anything good or bad against this product just that it has a right to exist and could work (whether it will or not is not what I’m arguing).
In my experience, what people use is very malleable to how easy/good the flows are they are presented with. Given 100 equal options, they might use 20, and nobody picks the same 20, but given 25 options, 20 of which present a very good experience, almost 90% will go with those 20 without complaints.
Maybe the problem with software is feeling the need to satisfy 100% of users instead of being OK with "only" 20%. Not everything needs to be a min/max problem.
As long as the 20% is enough to sustain your company, sure. You might have to charge more, however. Luxury brands do this, for instance (fewer consumers is actually a strategic choice to make the product more exclusive). “Pro” products also do this (though often “pro” means more features, not fewer).
The point is that 20% of features doesn't satisfy even 20% of users. It's going to be only a tiny fraction of that because something like 99% of potential users are going to need at least one feature outside the 20%. And if a competitor has all the features they need, but you don't, then you lose the sale.
He was talking about Excel. Google Sheets with a tiny fraction of Excel features destroyed Excel except for a tiny minority of hardcore finance and Windows users.
> what makes you think that the features that are personally important to you are the same features that other potential users need?
I think this is a weird question. Sure he can't be the only soul in the world to need only those features. Those 20% people need gotta overlap. So I think a more generous way to read your question would be "what makes you think that the features that are personally important to you are the same features that the mass audience need?". If that's what you meant then I'd ask why appealing to the mass audience so important? Why maximize sales and risk making your product worse if the core of your product is to make things you care about?
> everybody only uses 20% of a given program's features, but the problem is that everyone is using a different 20%
This is a phrase that gets repeated and it sounds clever. But it's completely at odds with statistics, specifically the normal distribution.
We should say, people use 80-90% the same features, and then there's a tail of less common features that only some people use but are very important to them.
This is why plugin systems for apps are so important. You can build an app that supports the 80% with a tightly designed set of core features, and if someone needs to go outside of those they can use/build a plugin.
Assuming that users only use 20% of the program and that the usage is evenly distributed, which would be a really big assumption right there, then there is still a finite number of users before you will have used up every part of program functionality between your user base and that any users past that amount will be repeating an actual and specific percentage of program functionality already assigned to some other user, unless you want to argue that functionality can be reduced infinitesimally in a sort of Zeno-like process.
If you agree however that functionality profiles will repeat among users given a large enough user base then it implies a particular limited feature set can still be totally adequate to support program development.
And that is with assumptions stacked against you succeeding, if indeed, as would seem likely, that some user profiles are more widely distributed than others it would follow that a successful product can just focus on those.
Could it be more people want Instagram instead of Photoshop? Take a picture, choose from one of 10 filters. Have a ~12 adjustable settings. Vs Photoshop's 1000s of options.
Like lots of people prefer Trader Joes (limited selection) to a bigger super market
> Joel Spolsky said (I'm paraphrasing) that everybody only uses 20% of a given program's features, but the problem is that everyone is using a different 20%, so you can't ship an "unbloated" version and expect it to still work for most people.
I remember reading something like this while talking about developing in C++.
VIM does this perfectly. Not a single feature is exposed to the user. Every feature the user might ever want is supported, they need just Google for which keyboard incantation to invoke it.
Makes me wish more apps followed the UNIX model of separating every feature into separate applications with well documented interfaces that only change when new features absolutely require it and otherwise are only updated for security patches.
One common case I notice this is with FFMPEG. Everything that saves a video needs its own dialog with different settings. It would make a lot more sense if you had 1 single polished FFMPEG frontend that everyone just streamed data to.
On the other hand, I'm afraid that if this did happen that FFMPEG frontend would look like a GNOME app and I would hate using it.
Me, on the other hand, love ffmpeg, because I notice my ytdlp using it and my vlc player sometimes using it and I have two homemade powrshell scripts using it to convert flac to mp3 and whatever. I don't want to open a program and figure out it's UI for those things. It has a job, it does it well, you can sort of pipe things to it and I'm very happy.
I'm not sure you understood what I mean. I'm talking about applications like Krita using FFMPEG to export their data as video. Sometimes they include their own FFMPEG instead of using FFMPEG installed in the system. Each of them has its own dialog. The only way to input custom settings for FFMPEG would be to export in a lossless video format and then reencode using FFMPEG, when you should be able to just "connect" a data stream to an FFMPEG frontend as the input and the frontend has all the options you might want to customize how that data is turned into a .mp4 file or .mov file.
Want to generate a video, it's just a few lines of code. Want to connect the user's camera (with permission), it's just a few lines of code. Websockets? About 4 lines of code.
There could be 1000s of options for each of those but they mostly distilled it down to what most people need, and they're cross platform.
Could you elaborate a little bit more, how a sole developer should do these things in a meaningful way, if even larger companies and start-ups fail with this?
The most basic way is to do a 30 min interview with 20 designers that cover a few each of freelance, small company, med company, large company. Find out which features they use and don't, and what their pain points are, and whether a tool with less features is something that would be majorly helpful or not very important.
Then do a round of validation with AdWords, can you get designers to click on the ad for something advertised as simpler and bloat-free, go to a landing page that explains what it has and doesn't have, and then put it their email to find out when it launches.
To me, that is the absolute bare minimum to make sure you're developing something that can be a business, rather than just a hobby for yourself.
And these are not my ideas or anything. They're pretty standard stuff, and there's a lot more you can and should do as well.
> what makes you think that the features that are personally important to you are the same features that other potential users need?
Good question, what's the pitch:
“Vecti is a browser-based UI design tool built from the ground up with one core belief, that creators deserve tools built specifically for them. Better performance, better privacy, and better alignment with their actual needs. A tool that just works, built by someone who genuinely cares about the people using it.”
Hmm. Did founders of Balsamiq or Figma not care about the people using it? And who if not creators were they built for?
“Share & Present - Set viewer and editor permissions at the team or project level. When it's time to present … let your work shine.”
Joel Spolsky said (I'm paraphrasing) that everybody only uses 20% of a given program's features, but the problem is that everyone is using a different 20%, so you can't ship an "unbloated" version and expect it to still work for most people.
So it looks like you've built something really cool, but I have to ask what makes you think that the features that are personally important to you are the same features that other potential users need? Since this clearly seems to be something you're trying to create a business out of rather than just a personal hobby project. I'm curious how you went about customer research and market validation for the specific subset of features that you chose to develop?