A user on our Slack, and some on reddit, have asked us why we've been sort of quiet on progress. Why no new blog posts? Why no new major releases? Why the seemingly dismissive attitude towards feature requests? Here was my response, and here's that new blog post you asked for :)
I spent the last few years personally responding to every single user inquiry or request. I also handled every single feature, bug fix, release, blog post, etc. At some point recently, this all began to take a toll on me, and was not sustainable. So I set out to hire a team. Hiring a team has been what I have been working on full time for the last 3-4 months. It really is one of the hardest parts of building a company. Now that the team is close to fully built, we’re sorting of establishing a game plan. You don’t just get straight to 100% throughput overnight. It takes organizing and orchestration. It takes planning, design, and intensive strategizing before a single line of code is written.
If we’re quiet, we’re working. Software development is hard and arduous. And we still don’t have a dedicated blogger or social media person. I run our Twitter, and I’m pretty bad at social media. But having a dedicated content person is just not our immediate priority.
In any case, I agree that the only way to know we’re actively here and actively working on improving SN is if you hang out in the Slack. Personally, I am a reserved character and have always worked in silence, and don’t put too much hype around upcoming features until they’re absolutely done and ready for shipping. The software development process is fragile and intricate.
We have a somewhat unique approach to feature requests, which at first glance may seem dismissive and anti-user: “We say no to feature requests.” This was a necessity early on to manage the never ending influx of feature requests and the finite resources available to develop and maintain them. We don’t say no because it means we’re never going to build the thing in question—we say no because we’re not going to make promises we aren’t sure we can deliver on yet. We will not build a feature if we're not absolutely certain it’s something we can maintain for the next decade. This is why we don’t have an official web clipper, for example. Can we spend a week or two building one? Sure. Can we provide immediate support and priority bug fixes to it when something goes wrong? Depends on our level of resources. But as of today, no.
The good news is that this is a full time obsession for many of us. And we’re not just sitting here, I promise you that. But we’re also not announcing our every move. Perhaps we can move towards being a more extroverted company in the future.
As a general note on how we build features, we won’t add new features into minor releases. If you ask for X feature and it sounds interesting to us, it’s unlikely we’ll just immediately bundle it into v3. Instead, how our process has typically worked is that every year or so, we release a new major version of our application. The features, design, and strategy for that release 100% centers around the kind of feedback and requests we’ve received over the last year. We have a really intimate temperature on where we feel the product needs improvement, and where we think the product excels. So while we can’t act on your feedback immediately, it’s definitely not forgotten. Most of my responses to feature requests typically take the form of "We'll keep that in mind!"—and that’s no cop out. We’re literally keeping that in mind. But that’s about all we can do in the short term. I’ve said yes to feature requests prematurely before, and ended up not shipping them for whatever reason, and it backfires, real fast.
So, here we are in 2020. We’re working on v4. You’re going to absolutely love it. But it’s going to take a soul-crushing amount of work to complete. I don’t dare make an estimate for how long it will take. But when it’s done, it will be the best work we’ve ever put out.
Thanks for reading ✓
