kevsim

After relocating from the US to Scandinavia, people here are always give me crap for having worked in a cubicle farm. And I always tell them I'd go back to that layout in a second compared the open landscape nightmare we have everywhere here.

I'm pretty sure if you have to commit wire fraud to build your business, you can't really claim to be that great an entrepreneur.

Congrats on the launch! For teams that are using something like customer.io, how does this fit into the picture? Is it a replacement or a companion?

And to nerd out a bit - how was working with Lexical? We chose Slate.js for our editor in Kitemaker.co but it's not as actively maintained as it once was.

We used Webflow for our company's landing page for a while but for our uses it was more "slow code" than "no code". To get the layouts we wanted you still had to understand the quirks and intricacies of flex/grid so it was just a clunkier interface than writing code.

That being said, it got us up and running quickly at a time where we didn't have much time to spend on that stuff. I think it's a reasonable progression to start out with something like a no code tool and switch to code when you've got the time/people.

The typical way would be to report it to the data protection authority in the European country in which you reside. Then they'll decide whether to take any action.

Unsolicited praise - we've been using ToDesktop at Kitemaker for a while now and we're super happy with it. The team is always super responsive to our requests and the product has been very stable. We were rolling our own Electron app before and it was an annoying headache. Just having a tool that takes care of all the updates, Apple signing and is consistently adding new/useful APIs for us to tap into is a big win. I get that some teams aren't interested in having an Electron app, and that's cool, but if you are, give this a shot because it'll for sure save you time.

I guess if you can afford the jet, you can afford to have a helicopter waiting to pick you up?

Meaning your server?

Gotta say, not really looking forward to GPT generated recipes rendered by Stable Diffusion.

Just be sure to bring a raincoat

Yeah, need to select everything to read it.

For me, it was the exact opposite. It was a feeling of "finally, this is what I'm supposed to be doing". It takes all sorts, as they say.

I think Segment did something similar a while back. Instead of using Kafka for the queue of events in coming in, they built a queue on MySQL [0]

0: https://segment.com/blog/introducing-centrifuge/

This is somewhat similar to the Shape Up methodology from Basecamp [0] where there's a 2 week "cool down" at the end of every development cycle. So 6 weeks of feature development, followed by 2 weeks of bug fixing, refactoring, etc.

I've never done it in practice so I don't know how well it really works and there are some other parts of Shape Up that I disagree with strongly.

0: https://basecamp.com/shapeup

I've never seen tip #4 (Rewrite negative conditions) or anything like it before. I can't see how that improves readability at all. If I saw it in a code review I'd ask the developer if they forgot to fill in the body of the if statement.

> Is wearing blue denim jacket and jeans an anti-pattern?

The Canadian tuxedo is clearly a best practice.

I think this is the default for services like Intercom and you can't stop it [0]. It's super annoying.

0: https://www.intercom.com/help/en/articles/5053699-how-do-i-s...

We also had the OT vs. CRDT discussion with regards to our editor at Kitemaker (kitemaker.co), and also ended up with OT. For us there were a number of factors, but (in addition to the case you mentioned) it came down to the fact that (at that time) most of the CRDT libs like automerge generate huge diffs that we'd need to send over the wire and also that the open source editor we use (SlateJS) had operations that just slotted very nicely into OT.

Your editor feels really nice BTW. Well done!

Totally agree. "Hey Siri, start a timer for X minutes" and "Hey Siri, play Y on Spotify" are the entire extent of my voice assistant interactions.

Yeah, when we built our product (kitemaker.co) we introduced offline capabilities quite early because my co-founder often had very spotty wifi during train commutes. We ended up making all writes totally optimistic with data sync in the background. Has the nice performance benefit of the frontend never waiting for the server as well.

That's what I read it as and was a bit disappointed when it turned out not to be the case.

I find the 'never fix a bug and refactor in the same commit' advice somewhat questionable.

If the code is a mess and I'm going to refactor it anyway should I spend a lot of time trying to fix the bug in the old code only to refactor it afterwards? Or should I refactor and deliberately leave the bug in there only to fix it afterwards?

To me doing them together often makes sense and I don't remember code reviewers ever complaining. But maybe I'm missing something?

> Because an issue tracker is for tracking issues... not... oh nevermind.

That's exactly the point we are trying make. Issue trackers are good at tracking issues, but now people use issue trackers to track everything, from product development to task tracking, which they're often sub-optimal for.

> Yeah, because there is a lot of complex and different kinds of work out there, and building one system to do everything is a bad idea. A carpenter has multiple kinds of hammers. That's not a bug, that's a feature.

That's the bit I think we disagree on. My co-founder and I have both managed very large teams at large organizations. If you start splitting up everything into different tools, suddenly product is entirely disconnected from development and vice versa. We've seen it over and over where a tool becomes a "PM's domain" and is totally disconnected from the reality of the developers' work.

Now obviously you can make it work with discipline, but you can make anything work with discipline. We think Kitemaker makes it easier for product/development/design by creating one place for them all to meet. I agree that there are different types of hammers, we do not try to replace git/figma/slack but rather integrate with them.

I think we mostly agree at a high level, we just disagree where the split should be between different tools and you don't like the click-baity style of the article (that's fair and we'll try to work on it next time)

We've discussed introducing automation to move done things to the archive periodically (just to keep the board tidy) but we haven't gotten many requests for automatically closing stale things. Yet.

Maybe there's a bit way to surface these old things and remind teams to deal with their skeletons.

This is very insightful feedback. Thank you for that!

One thing people tell us they like about Kitemaker is the ability to have a historical view of things. Because all of those extra edge cases that pop up get captured right in the same work item (and because we have an activity and history view on the work item), it becomes a pretty good place to explore the history of how you ended up where you did instead of a bunch of disconnected design docs and tasks in an issue tracker.

Thank being said, your comment has my gears turning on how we could do an even better job of it.

Thank you for the thoughtful feedback!

Easy one first - pricing. It's always a challenge but we try to find something that's reasonable when compared to the competition. We're not big fans of tools that do limited time feature stuff (this feature only works for the first two weeks unless you pay) so this is what we're trying for now. We're very flexible with teams as well. If they don't feel like they've gotten a fair chance to try it out, we raise the limit and let them keep trying for free. We'll gladly take your money once you're satisfied.

With regards to GitLab or any other traditional issue tracking tool - if you're able to get this sort of a workflow where your team is really focused on the outcomes and not mechanically processing tickets, then that's great! We're not building the only tool in which this is possible, just building a tool that we feel does a great job of nudging people in the right direction.

Thanks for the tip! Zapier's SEO prowess is awe inspiring.

Not gonna lie, we wrestled with the title a bit and had some alternatives lined up. We'll take the HN feedback to heart, for sure.

Fair enough. The title was meant to be a bit provocative for sure.

The point we're trying to make is that a tool can help nudge you in a certain direction, and we're trying to make Kitemaker the tool that nudges you towards working in a way that gets the whole team focused on outcomes instead of focusing on small tasks.

If teams are able to achieve that in their current tool of choice, that's ok too. We just believe working in this way is healthy and productive and hope to see more teams thinking along these lines.

Appreciate the feedback! Nailing landing page copy is tough.

So you'd like to see something along the lines of "in Jira you'd do it like XYZ, in Kitemaker it'd look like ABC"?