Ymmv, but I will never use Quill for a production project again.
We started using Quill 1.x around 2016, I initially liked it a lot. Jason proactively reached out to me when I first tweeted about considering Quill, and he was helpful when I had questions about the implementation.
Fast forward to 2019, we were running into some bugs, Quill 1.x was in maintenance mode, and 2.0 was effectively undocumented [1]. I reached out to Jason on Twitter [2] to get a sense for the timeline, and he basically told me to get lost. (Also his company Slab now blocks me on Twitter, though I imagine he just meant to block me from his personal account.)
Everyone has stressful days, especially when building a startup, so maybe that was just a bad time for me to reach out. My best guess is that they were focused on their own company (fair!) and barely had the time to maintain Quill for their own internal usage, let alone release it as open source. If that's the case, I wish they'd been upfront about it.
5 years later, Quill v2 is finally live. I'm glad to see Slab is still around, and I hope they have the bandwidth to publicly maintain Quill going forward. But if you're thinking about using this in production, I would push on what their commitment is to supporting it, and have a plan for if they stop responding.
(Jason, if you're on this thread, no hard feelings, water under the bridge. Feel free to ignore or chime in with your own perspective.)
Thanks for the kind comment. While I'm sorry that the service wasn't the right fit for your family member, I'm glad that our support team handled it gracefully.
Storyworth is a meaningful business with a lean team and a big emphasis on work/life balance. We’re looking for experienced, full-stack engineers with strong product skills who are interested in flexible hours (20-30 hours/week) with good pay.
Storyworth helps people record their family stories and print them in beautiful hardcover books. We’re profitable with no need to fundraise. We’re a small team by choice, with low overhead and few meetings. Everyone is remote and works flexible hours, including our leadership team.
We’re hiring a couple of engineers who enjoy building products end to end, from the UI to the database query. We’re looking for optimistic, self-motivated people, who value working at the top of their craft AND having time for the other things they care about. Our stack is Python (Tornado), Mongo, Svelte and Tailwind.
We rarely have open roles, so if this sounds interesting, please read the full role description and follow the instructions to apply:
We’re looking for a full-stack engineer to join us at StoryWorth (www.storyworth.com).
This role is a good fit for you if you want to work on a meaningful consumer product, and if you work best with a lot of responsibility on a small team.
We’re a service that helps people record their family stories and print them in beautiful hardcover books. We have raised a seed round, have paying customers who love us, and are on track to be profitable.
You’ll be taking over the core engineering of the site, scaling it as we grow and implementing major new features. Because of this, we need someone with significant engineering experience (3-5 years full time work). You should be comfortable Python, Javascript, HTML and CSS. Bonus points if you have mobile experience and an interest in design.
Our development process is very collaborative. We'll wireframe a new feature together, you'll put together an end-to-end prototype, and we'll iterate from that. We care more about clean maintainable code than domain expertise. Our stack includes Python (Tornado), Mongo, Swift, Heroku, Stripe, Twilio & Mailgun.
If you want to apply, email me a short note about why this posting caught your attention and we’ll go from there.
PS: Unfortunately we can’t sponsor a visa at this time, but we’re open to remote candidates if you’re a particularly good fit. Also, this role likely isn’t right for you if you graduated in the past year or recently completed a hacker school.
It's hard to overstate how much easier the Twilio API has made it for developers to interact with SMS and phones.
When I first built StoryWorth, it only worked over email because I thought voice recording would be too complex (both to use and to implement).
However, users kept asking for it so I finally bit the bullet... and it was way easier than I expected. Using the Twilio API, I had voice recordings over the phone working within days.
The team is also super friendly. Less than a month after our launch, someone reached out to me and they wrote about our company on their blog:
You're absolutely right, you could do this yourself. In practice though, I've found that people really like the questions we suggest, and the fact that we automatically send the questions, reminders, etc. It just makes things easier, and therefore more likely to happen.
As for the personal touch, the question is really just a prompt to trigger a meaningful conversation which might otherwise not have happened.
Oooh, like a family history version of Han Solo in carbonite :)
I do think the printed books give it some of that longevity. They may not last 1000 years, but I love the idea that someone's great-great-great-grandchild could read their stories a couple of hundred years from now.
As a long time reader, I'm hesitant to post a promotion on HN, so I want to give a little more context. Just last week one of our customers called me after her mom passed away, to thank us for all the stories she had gotten through StoryWorth. So while it is my company, I see first hand how it helps people connect with their families and how much it means to them.
I hope you don't mind me sharing it here today, but appreciate your feedback either way.
STORYWORTH (YC, seed) | San Francisco, CA | Full stack web engineering lead
StoryWorth (www.storyworth.com) is a service that makes it super easy to record family stories. We're launched and have paying customers. We've been covered in the NYT and recently swept the RootsTech Innovator Challenge.
We're a team of 4 – technical founder (myself), community, marketing and iOS eng. You'd be joining us as the full stack web lead, taking over development of new features from me. Our stack is Python (Tornado) and Mongo on Heroku (+Stripe, Twilio, Mailgun...).
This role is for you if you're a generalist looking for a lot of responsibility on a small team, and want to work on a meaningful consumer product with a real business model.
I would love for a portion of my Spotify subscription to be discretionary, so I could proactively reward bands I love. In fact, I would gladly pay $2-5 extra a month for this feature.
Here's how it could work. Every month, I'd get an email with the top 20 artists I listened to that month (stats! fun!). By default, my contribution goes to my most listened artist. I don't need to do a thing.
If I want, I can manually go in and change the contribution to another artist – say I listened to the new Kanye album a ton, but would rather give my extra dollars to my second-most-listened, way-less-famous artist.
I believe a lot of people get real personal value out of supporting artists they believe in. Right now, the best way to do this is to go to shows and buy merch.
Optional donations as describe above are an opportunity for Spotify to increase the amount of money spent on music, while generating lots of goodwill from users and artists alike.
We're looking for two fine folks to join our core team:
* iOS Engineer. You’ll be responsible for building our mobile app from scratch, working closely with me on the design and with our web engineer on the backend. Prior experience building an iOS app is required.
* Full-stack Web Engineer. You’ll be taking over the core engineering of the site from me, scaling it as we grow and implementing major new features. You need to be comfortable with Python, HTML and CSS. Bonus points if you have an interest in design.
StoryWorth makes it easy for people to privately record their family stories. Each week, we email our customers a question about their life, for example “What do you remember about your grandmother?” or “Tell me about the day you got engaged”. All they have to do is reply with a story, either by email or by phone. We save their stories and share them privately with their family.
These roles are right for you if you...
* want to work on a meaningful consumer product.
* want a ton of responsibility on a small team.
* want to be part of forming the culture of the company.
* value your work/life balance (we do too!).
If you're interested, email me at [email protected] and tell me why our listing caught your eye!
It is indeed, which makes for a nice backup. In fact, a lot of our storytellers never visit the site, interacting with the service entirely over email.
It's still great to have a copy online for backup, editing, sharing with new family members (e.g. spouses), or ordering printed books.
Haha, that "old guy" is actually my dad, but I won't tell him you said that :)
I think it's very understandable to be skeptical of online privacy these days. There is no such thing as perfect privacy, but there's a wide spectrum between a fully public Twitter account and a Gmail account secured with 2 factor auth.
Where you strive to be on that spectrum influences your product decisions, and that in turns affects the interactions your customers have. In our case, the goal is to encourage meaningful conversations between close family members, rather than broad public sharing.
I'm building the core team at StoryWorth and hiring for two roles:
* iOS Engineer. You’ll be responsible for building our mobile app from scratch, working closely with me on the design and with our web engineer on the backend. Prior experience building an iOS app is required.
* Full-stack Web Engineer. You’ll be taking over the core engineering of the site from me, scaling it as we grow and implementing major new features. You need to be comfortable with Python, HTML and CSS. Bonus points if you have an interest in design.
StoryWorth makes it easy for people to privately record their family stories. Each week, we email our customers a question about their life, for example “What do you remember about your grandmother?” or “Tell me about the day you got engaged”. All they have to do is reply with a story, either by email or by phone. We save their stories and share them privately with their family.
We have a launched product with paying customers across the country who love our service. You're a good fit for these roles if you crave a ton of responsibility on a small team. If you're the kind of person who learns by doing, you'll be learning faster than ever before. Both roles require 3-5 years of experience.
If you're interested, I'd be happy to tell you more. Email your resume/linkedin/github profile to [email protected], I can't wait to hear from you!
* Google has a large and very competent design team. They are not changing things "for the sake of changing them." More often than not, changes are made in response to issues discovered during usability studies.
* You are not the user. I am not the user. The designer is not the user. In fact, for a project as large as Android or Gmail, there is no "the user". You're always making trade-offs between power vs. common, new vs. existing users.
* Existing users are inherently conservative. By definition they mostly like things as they are or they wouldn't be users. You have to weigh their needs vs. those of future users. A big part of that is understanding how many people are upset about the change (all vs. vocal minority), how quickly they get used to it (if ever), and how you can mitigate this.
* Ideally, you want to make "Pareto efficient" changes, that make everyone better off. The only thing easier than doing what you've always done is when the new UX is so easy and intuitive you instantly understand it.
* You do not want to version your UI, just like you don't want to make everything a setting. This is a recipe for maintenance headaches, and endless wasted cycles supporting an ever-shrinking minority of users.
* This being said, it's very helpful to release a redesign as a beta, and let users switch back and forth for a while while you iron out the kinks. This in itself gives you good data.
At the end of the day, design is all about trade-offs. It's very easy to criticize a change because you don't like it, but it's a lot more interesting to think through why a change might have been made. If we're going to be critical, let us be constructive.
I'm building the core team at StoryWorth and hiring for three roles:
* Marketing and Partnerships lead. I’m looking for someone who can think creatively about our customer acquisition strategy then be highly analytical about executing on it.
* iOS Engineer. You’ll be responsible for building our mobile app from scratch, working closely with me on the design and with our web engineer on the backend. Prior experience building an iOS app is required.
* Full-stack Web Engineer. You’ll be taking over the core engineering of the site from me, scaling it as we grow and implementing major new features. You need to be comfortable with Python, HTML and CSS. Bonus points if you have an interest in design.
StoryWorth makes it easy for people to privately record their family stories. Each week, we email our customers a question about their life, for example “What do you remember about your grandmother?” or “Tell me about the day you got engaged”. All they have to do is reply with a story, either by email or by phone. We save their stories and share them privately with their family.
We have a launched product with paying customers across the country who love our service. This is an opportunity to be part of the core team that is going to help every family in the world record their story for generations to come.
You're a good fit for these roles if you crave a ton of responsibility on a small team. If you're the kind of person who learns by doing, you'll be learning faster than ever before. All roles require 3-5 years of experience.
If you're interested, I'd be happy to tell you more. Email your resume to [email protected], I can't wait to hear from you!
We started using Quill 1.x around 2016, I initially liked it a lot. Jason proactively reached out to me when I first tweeted about considering Quill, and he was helpful when I had questions about the implementation.
Fast forward to 2019, we were running into some bugs, Quill 1.x was in maintenance mode, and 2.0 was effectively undocumented [1]. I reached out to Jason on Twitter [2] to get a sense for the timeline, and he basically told me to get lost. (Also his company Slab now blocks me on Twitter, though I imagine he just meant to block me from his personal account.)
Everyone has stressful days, especially when building a startup, so maybe that was just a bad time for me to reach out. My best guess is that they were focused on their own company (fair!) and barely had the time to maintain Quill for their own internal usage, let alone release it as open source. If that's the case, I wish they'd been upfront about it.
5 years later, Quill v2 is finally live. I'm glad to see Slab is still around, and I hope they have the bandwidth to publicly maintain Quill going forward. But if you're thinking about using this in production, I would push on what their commitment is to supporting it, and have a plan for if they stop responding.
(Jason, if you're on this thread, no hard feelings, water under the bridge. Feel free to ignore or chime in with your own perspective.)
[1] https://github.com/quilljs/quill/issues/2435
[2] https://twitter.com/nickbaum/status/1177240103925796865