Hacker Noon Product Development Discussion with Product Team

LISTEN: iTunes

Austin Pocus: ...by the same tags, as I talk to them on a community forum community.hackernoon.com

Dane Lyons: You still have to balance the aesthetic with the actual usefulness... so if something is entirely mono space and small font, then you're hurting the accessibility and you're hurting the usability of the product. So, you gotta balance that out and sometimes just building something that is accessible and usable, it makes it more visually pleasing.

David Smooke: We want to keep going down this route of how do you make better curation -

Austin Pocus: If we build these things and we explore, we can come up with ideas that have legs on their own. We can potentially discover something that's greater than the sum of its parts.

Dane Lyons: How do we build a product that encourages people to spend more time reading and consuming words

David Smooke: We went with more of a route of catering to our users, building original software, and, in my opinion, raising the upside of our company significantly. But, this challenge creates a lot more work.

David Smooke: Welcome to this special edition of Hacker Noon podcast. I am David Smooke and today I'm joined by three quarters of the company: Dane Lyons, the chief product officer, and Austin Pocus, the full stack developer and today we're gonna talk about our new publishing platform. We've spent the last two weeks in London as part of our remote set-up, where two weeks, every quarter, we work out of the same location and figure out how much we hate each other with our close quarters. But today, we're just gonna talk a bit about the tech stacked, what's coming next, what we built, why we did it, where we struggled... So, what do you guys think of London?

Austin Pocus: It's pretty great; I love the food. I love the greenery; there's so many trees here, first of all, compared to, say, Detroit, where I'm from. It's such a stark difference.

Dane Lyons: Yeah, the pubs here are amazing. I'm very pleasantly surprised with the quality of potato dishes here. That was kind of unexpected. The beer is good. I am a little bit disappointed with the wine, and the chocolate, but you can't have everything.

David Smooke: Yeah, they have potato jackets, is the term here.

Dane Lyons: I know, I've got to try jacket potato.

David Smooke: Yeah, mine was just like a bunch of baked beans and cheese atop diced potatoes. I don't know why they called it jacket.

Dane Lyons: I like the English breakfast, the traditional English breakfast is pretty great. A little bit of baked beans with your breakfast. It's got a really nice combination of flavors.

David Smooke: I had some bangers and mash. But we did do work. We had an event here. Crazy tech stories where we had 6 or 7 Hacker Noon contributors tell their stories in person, but we hope to do more of those. But I think maybe the best place to start is, Dane, if you could give us a little bit of an overview of the product and the tech stack we have.

Dane Lyons: Yeah, so, ultimately we decided to build a headless CMS, and essentially what that is is we don't power our content pages through a traditional server. We're powering them through a CDN, so they're just static html pages: html, CSS, and JavaScript. So, on the content pages, we use View, and inside the application itself, it is powered by React, [inaudible 00:04:59]. We use the Google cloud platform pretty heavily and Firebase, specifically. We also use the Google CDN and a few other tools, but that's kind of the gist of it.

David Smooke: Yeah, what do you have to add to that, Austin?

Austin Pocus: I wasn't here, in time for the decision to use Firebase, and I'd like to hear more about how we arrived at that decision.

Dane Lyons: Yeah, so I think a big thing for me is we could defer DevOps. By going with Firebase, we really didn't have to devote a lot of people to figuring how to spin up servers and maintain servers. We could just not worry about that and focus much more on the product.

David Smooke: Yeah, and for me, they also offered us a hundred grand of posting credits. As our revenue stream is being threatened, we're moving to our own thing and it's gonna cost... we estimated it, even with the CDN solution, we were looking at 4 to 8k a month. When you're at 8 million page views a month, you do have to consider the trade off between ideal and cost. I mean, everybody does on their site or their app, but I definitely like that the hosting providers are very competitive and they want to bring in companies they think will grow and that's good for the first year.

Austin Pocus: Yeah, 100k always helps.

David Smooke: It does. So these 2 weeks, what have we accomplished?

Dane Lyons: It's kind of hard to say because over the 2 weeks, we've had a very forward-looking philosophy, so every day we get together and we talk about the current state of the product and the very immediate things we need to do to make it better and that's not quite typical stand-up meeting. A typical stand-up meeting will be divided between, what did you do yesterday and what will you do today.

David Smooke: Yeah, it's like the "blank slate" stand-up. What could you actually do in the next 12 hours to make this thing as improved as possible?

Dane Lyons: For me that's really important because traditional stand-ups, it's kind of like a culture of accountability. The backward looking mentality is making everybody be very accountable for how much work they got done and that distances and advises you to be very ambitious in what you'll try to accomplish in the future. An engineer would, instead of saying, "I'm gonna go try to accomplish these 5 or 10 things," they're going to say, "I'm just gonna focus on this one thing, because if I don't get it done, I'm going to be held accountable for it." So, you have a much more of a conservative mindset. For me, I would much rather everybody try to accomplish 5 or 10 things in a day and if you don't get it done, you don't get it done. You shouldn't be punished for being ambitious.

Austin Pocus: I feel like we have a much more of a culture of trust, where we're trusted to do what's best for the product and we know that David's doing what's best for the product. He knows that we're doing that. There's much less of a culture of cover your ass.

Dane Lyons: Right. I think in order to enable that, you need to have regular discussions about what's actually important in the product so people can make good decisions on behalf of the product.

David Smooke: And how the product fits into the business. Because it is most of the business, but the core of our business is the stories themselves. And without great stories coming in, and without great stories being distributed, it doesn't matter if it's a great communication between writer and editor, which is what we're working towards. Great communication between writer and editor.

Derek Bernard: This episode of Hacker Noon is brought to you by DigitalOcean. Join a community of over 3.5 million developers learning how to build and scale high-performance web apps on the simplest cloud platform, with a flat, pay-as-you-go pricing structure and monthly caps across all global data centers, DigitalOcean makes it easy to get the computer resources you need without the billing surprises you get from other cloud providers. Discover why developers love DigitalOcean, and get started with a free 100 dollar credit at do.co/hackernoon. Full stack developer, Austin Pocus:

Austin Pocus: We're using it to host a discourse site, so basically, they give us a machine and we run a "docker-ized" instance of discourse on there. It's a few clicks and discourse is ready to rock. With DigitalOcean, they have a marketplace where you just click, "I want discourse," you provision a droplet and you're good to go.

Dane Lyons: So going back, and thinking about everything we've accomplished in this 2 week sprint, I feel like we've actually accomplished a hell of a lot. It was an incredibly productive chunk of work. We still haven't pushed the button and launched our product to make it live, but we're in a much better state today than we were 2 weeks ago.

David Smooke: And we could hit that button, which is cool. We can hit it when we want, we have beta users working on it, operating in it, so it feels good. It also feels like last Monday was, part of me was like, it just happened, but also part of me is like, I've been in London for a year. I've gotten a little used to it in these 2 weeks. So let's jump into, jeez, we've built a lot with these 2 developers. 2 and a half. We also have Faith, part-time. A lot of front-end and design work. And we've had plenty of help from the community and other people. But how do you guys look at it in terms of the amount of work we had to do with only 2 developers, seems like a bit much.

Austin Pocus: I feel like I had to do whatever needed to be done. So, I was willing to do whatever needed doing. I wasn't fitting myself into a oh, I'm only working on the back-end, or I'm only working in React or anything like that. If we need to do a bit of DevOps work, spin up an Engine X server and reverse proxy our traffic, I'll do that. If we need to do database backups, I'll handle that. Whatever needs doing.

Dane Lyons: Yeah, and I think one thing that's also helped us is we have a very function-first mindset, so we are not afraid to build something that looks ugly that accomplishes the goal. And we're gonna make the product look more beautiful and be a much better experience long-term.

David Smooke: Let's hold up there. If we're gonna stay on brand, we gotta make this thing ugly.

Dane Lyons: Well, we're gonna make the most beautiful product we can with the most ugly color we have.

David Smooke: Yeah, I mean, maybe we should just make the design uglier, too, though. So we really steer into it. It's all about the content. It's all about the function.

Dane Lyons: Yeah, maybe that's the way it ends up. We have a lot of iteration ahead of us, and maybe we find that making nice little rounded corners, and nice shading and everything, maybe that's not the way we go. Maybe we double down on this brutalist aesthetic.

David Smooke: It's terminal-first philosophy.

Dane Lyons: Yeah, terminal-first. That's a good way to put it.

Austin Pocus: Yeah, I was thinking it might be neat if we had a reading interface where it was all mono space text, like it looks like it was typed out on a typewriter.

David Smooke: That'd be cool.

Dane Lyons: Yeah, you still have to balance the aesthetic with the actual usefulness. So if something is entirely mono space and small font, then you're hurting the accessibility and you're hurting the usability of the product, so you've gotta balance that out. Sometimes just building something that is accessible and usable makes it more visually pleasing because things are better lined up. Even if you're brutalist in your aesthetic, it still feels like there's some order to it.

Austin Pocus: Yeah, it still has to feel functional from a user's point of view.

David Smooke: And for our primary user is the contributing writer, and we've heavily invested in our own editor. Could you guys talk a little bit about what we did?

Dane Lyons: Yeah, so I've previously built editors and browsers before. I got a start-up that we built, an editor that allowed you to author emails. So then I had to make experience using draft-js and our tech staff kind of uses React, so draft-js is kind of a natural way to build a simple editor.

David Smooke: It's very popular.

Dane Lyons: Yeah, it's very popular but it's also kind of a pain to use. So we ended up using Slate. It's very generic in the sense that you have a lot of flexibility in what you do with it, but it's a very powerful editor. The foundation that they give you, if you were to go build that from scratch, it would be 6 months plus of work just to get a good foundation down. So, it's great that we have a nice foundation that we can build onto from there.

Austin Pocus: Absolutely. It's one of the most flexible libraries I've ever seen. It's very powerful in what it can do. It gives you commands to move the cursor around, highlight text, or whatever you need to do. It's much easier than working with draft, from what I've seen.

Dane Lyons: I will say that the documentation has been a little bit frustrating, but they kind of make up for that by having a very receptive slack channel that you can just dive in and ask questions. So I think that's a good way to go. They can start incorporating the questions into the documentation and it's just a good all-around product.

Austin Pocus: I actually kind of like the documentation.

Dane Lyons: I mean, everybody finds it difficult to documentation but the level of abstraction in the documentation is.. You have to take a deep dive into some of the bits of code to really understand how to extend it, which I think they could do a little bit better on that side of things.

Austin Pocus: Yeah, it's definitely a deep dive. But what's that expression? There is no dispute in matters of taste.

David Smooke: Yeah. My point of view, as an editor, the key to an editor is a good blank page. Which means, I am, from the perspective of, I am probably undermined all of the work that it takes to make a great editor. And then as I switch from making wire frames to being a quality assurance and testing this thing out, I realize how many fucking use cases there are across everything in an editor. It is crazy to supply for all these things. We've gone through a lot but it's infinite. There's infinite amount of cases to properly display the text people want. Copy, paste, type, change. It's so many different cases. We've also invested in other areas of the product that are really important. Can you talk about our other most important pages and what's behind them?

Dane Lyons: One of the biggest motivations in building, what people are calling these days, like a headless CMS, you power a lot of your pages through a CDN. It's just aesthetic html, CSS, and JavaScript, as opposed to powering them from a server and it would actually be far easier for us not to bill our infrastructure that way but the cost savings will be pretty substantial going that route. To me that's one of the biggest problems that we've kind of solved to this point but a lot of the work we've been doing is kind of foundational work, so I really see the interesting problems that we're solving are ahead of us and not behind us.

Austin Pocus: I've worked on the foundation a lot. Was early on when we were building up this headless CMS and I think Firebase lends itself really well to building one because it has these firestore hooks, they call them. Essentially, if you're not familiar with Firebase, it's a way to hook into document creation in the database, or document updates, document deletion

Dane Lyons: They're actually called triggers.

David Smooke: Are they triggers?

Dane Lyons: Yeah, they're triggers, but that's okay.

David Smooke: Let's jump into some paying points. It's a totally viable solution to go WordPress or somebody else. So much functionality already built there, so much open source software, or software that you have other people that you can pay to help you with. So there were really a lot of choices of, if the challenge is just how to display this library in a new environment, there are much smarter, simpler choices we could have made. So we went with more of a route of catering to our users, building original software, and, in my opinion, raising the upside of our company significantly. But this challenge creates a lot more work.

Dane Lyons: To me, the reason not to go with these other solutions, it's all about flexibility. Because while we could have built this thing in WordPress or Gatsby or one of those tools, which are fine tools for a common publishing use case, they're not necessarily a good use case for us because we have this environment where we've got a lot of editors and a lot of writers. The typical blog out there might have a team of 4 or 5 people working on collaborating on the blog, but we have thousands of people behind the scenes. So we need to have a much more meaty system to allow our writers and our editors to collaborate and effectively work together on producing content.

Austin Pocus: Yeah, I think that's a common problem when using open-source software is you run into these issues where it doesn't work well for your case. You either have to fork it or you have to put in a PR and hope they accept it. You always run into these sorts of issues.

Dane Lyons: I'm all for open source software. I think it's fantastic. When we use plenty of open source software in our tool, it's just that we haven't gone the route of using an all-in-one solution like WordPress.

Austin Pocus: Right, that's more of what I meant is the all-in-one solutions. Not so much React or VU or anything like that.

Dane Lyons: Right.

David Smooke: Yeah, there's a good announcement about open source yesterday.

Austin Pocus: Oh yeah?

David Smooke: GitHub is allowing people to directly donate and matching donations. Pretty smart.

Dane Lyons: It's fantastic.

Austin Pocus: It looks like GitHub is trying to eat the open source software world. They're taking over. They were already a big name, and now they're re solidifying.

David Smooke: Did you say Microsoft? Also, some of the bigger problems: the editor is an ongoing thing, but we've also, now that we want contributors to take over their content more, there's been a lot of work in the back and forth between editor and writer. Whether to put posts in the queue, or publish posts right away. What level of communication they have. Could you guys talk a little bit about the activity feed we have between writers and editors?

Austin Pocus: Oh yeah, so what I originally built was a way to see whether a draft had been opened by an editor, whether it had been edited, and whether it was published or rejected, so those were the key moments that I wanted to capture. I put them all in an activity feed and just displayed all of them sorted by date. It was a really simple solution but it's been really effective for us. It actually was, at one point the only way to see a published draft in our system before it hit the queue because it was in sort of a limbo state. You had this publishing queue where it would publish every ten minutes. I just removed that today.

Dane Lyons: One of the problems that this solves, as a writer, previously in the old system you would submit a draft to be published and you would wait and maybe 3 to 4 days later if we have a backlog, there's no transparency to see what that backlog's all about.

David Smooke: Yeah, basically, the only cases we would hear about are the extremes. Either, oh my gosh, I submitted and I was published within 2 hours, 'cause an editor saw it and jumped right on it or screw you guys, what's going on, it's been a week, where are you, are you off vacationing on Mallorca. So now most of the usage is not the extremes. They want to see when it's opened, they want to see when it'll be published. A simple activity, but if it's not baked into the software, or it's baked in for not these users, which right now it's not. The system we're using isn't about editors and writers collaborating and even with simple notifications and simple updates, we can really make a real step forward in how we better the day to day of our users.

Dane Lyons: Even with a fantastic system with fantastic editors, they can process an incredible number of stories per day. That lack of transparency causes a lot of anxiety for authors.

David Smooke: Yeah, it really does.

Austin Pocus: Absolutely. That's been a really exciting thing to our community as I've talked to them on the community forum, community.hackernoon.com, we've talked about some of the things we're building and one of the most exciting things that people really love is the activity feed. Just being able to know when they're published or when they're rejected.

David Smooke: And then the next step in the flow is, once you're published, it's about how is that story distributed and consumed. So here we're going to keep what's working in terms of page views and time reading. But look at going further down the line of when do 100 people tweet your story or who actually tweeted your story and that type of stuff also gets exciting. Of like, what is the ranking of your story in Google? There's areas in the stats that, we have to go further, and pick good partners and make good choices, but I am also excited about both sides of it. There's a whole level of communication that I think, I don't want to say missing from other sites, but it's something that we can do better than what we're doing today.

Austin Pocus: Yeah, we started out with a very simple solution for communication between writers and editors. So, we have an email option, and we have a direct message on the community forum. Going forward we're looking into highlighting text and adding notes. We're looking at live editing between author and editor so you can see the changes that are happening as they're happening.

David Smooke: Yeah, that's a little ambitious.

Austin Pocus: We thought about that is all I'm saying.

Dane Lyons: It's on the table. It's to be determined if we actually go that route or not.

Austin Pocus: Yeah, just a few exciting things that we're thinking about.

David Smooke: When you think about the amount of development hours that went into like, Google Docs and Dropbox Paper, to get to that point, it's pretty wild. And that's the only point. They're not worried about how wildly distributed your story is, or was it tweeted 3 times, tagging the author, which ours are. Which Dropbox Paper is not going to be doing. That would be a silly solution.

Austin Pocus: Yeah, that was a really cool thing that Dane built to auto-tweet the stories as they're published with tags.

David Smooke: Yeah, so the moment they publish, with hashtagging the first 2 tags, and then it hits a week later and a month later so it's a nice standard distribution. We want to keep going down this route of, how do you better curation, so the order of the tags you actually picked is really important. So the first 2 tags you pick for your Hacker Noon stories are gonna be hashtags when it's tweeted by Hacker Noon. Then your first tag is now gonna be displayed under the story when it's curated on any page on the site. So if you write a story where Ethereum is your most important tag, block chaining cryptocurrency, when it appears on those tag pages, Ethereum won't appear below the story. So continuing these systems where the order that you actually tag things will determine how we distribute it. We've started down this path and I'm really excited to go further.

Austin Pocus: In that same vein, we're also expanding the length of tags that you can add. So we're going from, I think, 25 characters, and we're going to have 30 characters. And we're also going to have 8 tags instead of 5. That's going to make a big difference.

Dane Lyons: We're also still building out our analytics but that feature tag, which I'm kind of tentatively calling it. But we can call it anything. So your first tag will probably influence pretty heavily on the analytics that you see per tag. One gap right now in your analytics for your story is you can't really see how you're doing. You can look at individual analytics per story but you can't look at it at a tag level. We'll be able to aggregate all of your tags, and we'll be able to show you how you're doing by tag in addition to the story.

David Smooke: I'm excited that going site-wide. And really saying, hey, where does block chain rank among most time reading. Where does the bitcoin tag, where does the software development tag, and how does that move over time? And whenever a big announcement happens, or as the industry is shifting, can we then say, reading time by tag is something we can comment on? And we can tell you how readers as a group are changing and what they want to read about technology. I think that's really cool, but I think we should talk a little bit about the north star and where we're headed. Maybe Dane, could you speak about our big 3 metrics and then how we're thinking about what are the stats that influence the choices we're going to make.

Dane Lyons: For me, the biggest metric is the time reading. That's the biggest metric that I think about on a daily basis. How do we build a product that encourages people to spend more time reading and consuming words. Say if a user's on the homepage, or if they're spending a lot of time browsing but they're not actually on a story, that's not necessarily going to be pushing on our north star metric forward. We really want to get people on stories and reading content. A lot of people get so obsessed with page views or clicks or something like that but we really want to optimize for reading time.

Austin Pocus: Yeah, and in that vein, we've had the additional stories by the author. We have the user profile, which is going to play a big part in author distribution, we're going to have a custom CTA on the profile. That's kinda cool. But we're trying our best to show you more stories that you're interested in, whether it's by the same author, by the same tags.

David Smooke: A few simple changes we're doing to what we have now, the end of the story is stories by the author. What recommended stories do you have now, a lot of it is for the network or for the platform or for the site. So now, it's getting someone to read a second story by the author, incentivizing that. Saying, hey, that's another time reading on our site. It's still good for us with our sponsorship at the top. We make money every time that happens, but it's very good for the author to go from one stories read to two stories read. And then if you really like the author and you go to their profile, instead of saying, join the network or follow them on the network, the biggest button on the page is they choose where that link goes and they choose what that text is. So if you want someone to contribute to your open source project, or you want someone to demo your Sass software, you write your own button and then when they get to your page, we hope that will be one of their better pages on the internet. As a source of traffic to the thing they care about most on the internet, which isn't on our site. It's somewhere else on the internet, it's on their own site. It's on their own company.

Dane Lyons: And then on the writer side of the equation, we're really optimizing for words published. To me, those are the two most important metrics. On the reader's side we want to optimize for time spent reading and on the writer's side we want to optimize for words published.

David Smooke: By making it a blanket stat like that, it's not about long stories or short stories. You can have a lot of short stories or one really great long story. To us, that's great. Both options are great. They mean we're a place that you want to publish on, and we're a place where people read your stories. And that's what we want to exist. And then our third most important metric is revenue. It's not investment, it's not users created, accounts created. Those things all matter; I'm not trying to dismiss them. But in terms of top three, those are the things that are going to drive the success of this country. Freudian slip! So yeah, words published, time reading, money made. That's what we're going for.

Dane Lyons: And then on the words published, I mean obviously there's going to be a quality component to that that we still need to figure out because publishing poor quality words is not something that we're trying to optimize for. That's still something that we're exploring. We're gonna have to figure that out.

David Smooke: We've upped our part-time editorial staff. We have 4 or 5 editors out there going through based on their subject matter expertise, which is the direction we want to go. Tools can plug on looking at how do tools spell-check and help your word quality and your word choice and that stuff is all gonna matter and we are at the end of the day a tech site and using tech to solve those problems is better in a lot of ways, but the quality control starts with, it has been and it will be, it's the second human rule. There's always another human that reviews your story. Hopefully that human can spend more time, and the incentives are created that they have enough time to judge the story and improve the story. As opposed to a completely, anyone-can-publish site, that's not us. It's something where, to publish on Hacker Noon, an editor will review your story.

Austin Pocus: Yeah, and eventually, we've talked about having community editors, where if you spend so much time on the site and you maybe published a couple of stories, if you've built up trust in the community, you should be able to edit stories. It's definitely something we wanna work towards.

David Smooke: We're not there yet.

Austin Pocus: Again, ambitious.

David Smooke: How do you think we'll iterate going forward? We talked about the numbers that's gonna drive our decision making, but also on a software level, we're getting all these suggestions. There's all these directions we could go, and this business, the time of the 3 people in this room and "Ling" is our greatest asset. How do you guys look at it in terms of choosing to spend your time and choosing to not spend your time?

Dane Lyons: It's always tough to find that balance. It's kind of like an explore versus exploit thing, where you could spend all day-- I see so many companies spend so much time just building new features. I kind of feel like, it's almost like people think that if I just have these 10 features, then I'm gonna hit that tipping point, and I'm going to have the best product in this market and then we're going to start making amazing money and I think that you've gotta really invest a lot of time in not only just building new things but fixing the things that you have.

David Smooke: I'd say improving. Because there will be small breaks but there's also things like, a page is never perfect. You can just keep putting time and money into a page. The editor is a whole business. That's a whole company that can do great and sell their editor to everybody else and if our editor is great and we fail in all these other things, that's still another viable business within the business. Not what's going to happen, but the point is, the level of detail and iteration you can do on a single page is endless.

Dane Lyons: Right, and that kind of comes back to the function-first design concept. You really need to have a rapid prototyping mindset where you have to be comfortable putting out stuff that is a little bit raw because if you have this polishing mindset

David Smooke: Our contributing writers certainly are.

Dane Lyons: It's all about exploration. You wanna put something out there and see if it has wheels, and then if it's got wheels, then you invest more time in making it better.

Austin Pocus: I'm glad you brought up exploration because I haven't really seen that at any other company unless it's directly tied to some feature that we're eventually going to implement or something like that. There's not much pure exploration at other companies that I've seen.

Dane Lyons: We're not gonna talk about it today but what I would really eventually like to get us to have this concept called dual track agile, where we've got like a discovery track and a delivery track and we need to be investing a lot of time in figuring out what we need to be building and trying to find unique ways to improve the thing that we have. I just think that that's so important, to build any good product.

Austin Pocus: Yeah, I'm really excited about the dual track agile system. It's so much more, it's so refreshing to see that and to have the freedom to say, okay, I'm going to see if I can add highlights to the editor today and that might be something that we pursue, it might not.

David Smooke: We're not gonna come up with new ideas if I do a waterfall and I'm just like, hey, here's the list, go at it guys. We'll come up with the ideas I said because I'm not paying for anything else. It's a pretty brutal business model or development structure and I get why a lot of people do it because you wanna get a product out. You wanna hit these minimums and a lot of software projects, the leader of the project is actually reporting someone else who wants to match his specs that he promised to the customer. Whatever the setup may be. I'm happy that we've gotten the business to the point where we don't have to operate like that. I think it increases our upside dramatically.

Dane Lyons: Absolutely.

Austin Pocus: Oh yeah. It comes back to the editor being a viable business on its own. If we build these things and we explore, we can come up with ideas that have legs on their own. We can potentially discover something that's greater than the sum of its parts.

David Smooke: I hope so.

Dane Lyons: I feel good about.

David Smooke: Yeah. Me too. It's really good to have beta users in it and it's good to get it out there. So if you have any ideas, a lot of the ideas have come from the community themselves, of what they've wanted, what writers want. Visit community.hackernoon.com. There's a product thread. You can see previews of what we're building and if you wanna reserve your Hacker Noon handle, that's auth.hackernoon.com and you can get a sweet handle. About 5 thousand have been claimed so get yours before Tom, Jerry, and who else has claimed. I'm David. I'm @David. You're @Dane. He's @Austin. We're on a first name basis now. Thanks for listening. Later!