Do Things That Don’t Scale (2013) | Hacker News Reader

Do Things That Don’t Scale (2013)

paulgraham.com

209 pointsjs774537 comments

I’ve been working on a programming language for a while, and this is one of the key bits of advice I’ve had in the back of my mind during that time.

People have come along and contributed occasionally, but for the most part, I’m doing everything: writing the compiler, standard library, documentation, editor integration, blog posts, evangelism of the programming paradigm, and so on. Despite the fact that I don’t scale, I’ll happily sit down with someone who’s trying out the language, help them get up to speed, and fix all the bugs and usability issues they report. It’s that kind of connection to people that not only drives interest in the project, but drives me to stay motivated.

I can’t say I fully understand my own success…or even whether it’s success. I’m not selling anything, just making the language I want to use. Maybe a few hundred lines of code have been written in the language by someone other than me. I’ve accumulated >450 stars on GitHub for a product that doesn’t even do anything yet. It’s certainly surreal, but it’s been pleasant. :)

What's the language called?

This is from his HN profile:

I’m writing a stack-based functional programming language called Kitten: https://github.com/evincarofautumn/kitten

Thanks—only reason I didn’t mention it was that I didn’t feel the need to advertise. I mainly wanted to give my thoughts on how this article’s advice has been a positive thing for the project—seeking out users and taking measures to help them and make them happy directly.

This is Paul Graham's best piece. Really nails down what it takes to make a business successful.

Any stories of fellow HNers with their startups doing this?

We do :)

As customers sign up we ask if they want stickers and then send out a handwritten letter alongside a set (example: https://www.instagram.com/p/BWA5q95jADc/?taken-by=cleverbeag...).

For our first 100 customers we basically did all the setup work for them. Basically did a screenshare, clicked for them, told them what to do. Would sometimes leave the call, and spend 1-8 hours clicking for the customer.

Learned how customers wanted the product to work, and gained initial customers. Lost money on the setup but who cares.

Now setups are a 30 minute phone call where we teach customers how to click themselves.

Curious, what software did you use for screen sharing? were customers ok with this? Was your app so complex that you couldn't guide them through the phone or it was a deficiency in the UX/UI of the app?

> Curious, what software did you use for screen sharing

Started off with Join.me. I then threw out my windows PC and installed Ubuntu, so it stopped working. I did appear.in a few times, but the quality stunk. Mostly moved to my setup team, that mostly still uses join.me.

> were customers ok with this

Oh they loved it. The competition is "Here is a youtube video and some docs, have at it". We actually took the time to get to know our customer and dive in, help them navigate the setup etc.

> Was your app so complex that you couldn't guide them through the phone or it was a deficiency in the UX/UI of the app?

Both! Necessary complexity is high, but so is accidental. Working on reducing accidental a little every day. Not willing to kill off too many features in the name of simplicity, but willing to at least make the common path a lot easier to use.

Spent a month in university libraries handing out candy and asking groups of students to try out our sharing platform. We then would take what we learned that day and code changes/fixes before we left or when we got home so we could go out again in the morning.

And, how'd it go?

They are now a small company with a lot of diabetic users.

(2013)

Reply on news.ycombinator.com