- My co-founder and I did all the Luggs ourselves in trucks we rented through GetAround for the first 4 months

- My co-founder and I's names, pictures, and phone numbers were hard coded into the app as the crew to fulfill the Lugg before we had crews or proper dispatching

- We launched without payments and would charge customers with a Square reader at the door

- Most mornings we would camp out in the IKEA parking lot in Emeryville, CA and approach their customers that were struggling to get their purchases in their cars and pitched them that we would deliver their items if they downloaded the app and made a request

- In the early days we didn't have operating ours and anyone could request a Lugg at anytime and my co-founder and I would hop in our rented truck and do it

A few months in we did a Lugg for someone that knew Sam Altman and made an intro to him for us. We met him for coffee, shortly after had a YC interview, and was later accepted in the S15 batch

So, um, thank you and sorry! (We didn't order at 10pm to be inconsiderate - we just saw the option and took it). Glad things have worked out since then - I still remember the experience and use it as a reference when I'm telling people about this exact sort of hustle.

With my very laconic reply I wanted in fact to convey my congratulations the Lugg creator for their perservance during the hard beginnings of their startup; plus, I strongly believe that the human level of the aspiring enterpreteneur's life is much more HNish in spirit, than endless discsussions circling around running LLM in the basement (or basement-as-a-service) without apparent customers, and somehow strangely the latter seems to be dominating HN comment space. Thanks for listening.

In part, I expect, due to the double full-stop which looks like it might be a miss-type ellipsis. It makes what could already potentially be seen as a sarcastic “cool story bro” response look even more so.

That, and the fact that HN generally disfavours short reaction comments (including, but not limited to, “Me too!”) which add nothing themselves other than perhaps (in the case of “me too”) an extra anecdata point.

Your follow-up post may well be downvoted too, because complaining about downvotes also being frowned upon (it is seen as adding unnecessary noise to a thread).

But I get your point, thank you. Although it is kind of scary people read that much between the lines.

Recommend you stop, unless you like coming off as an asshole..

It’s more reliable than any other short notice moving service I’ve used, but a little higher cost. I guess you get what you pay for.

I'd guess you need a lot of scale to beat a) on cost, but there's probably room to undercut b) or c) on short distance trips.

I face a similar kind of situation in a similar market, would love to hear your advice on something, feel it may complement what you are doing as well - can be reached at [email protected] for this if you'd be up to chat.

We got lucky though that it managed to fit into our car so we didn't need to. But nice to know it's an option!

Fantastic tagline, and very clear value proposition.

   * Manually create pre-configured accounts for potential customers, sometimes with up to an hour of entering in their existing data so things look familiar right from first login.
    * Investigate problems and repair live data, usually just by logging in as a user and using the tools in the product. Can they do this themselves? Sure. Do they appreciate our doing it instead? Oh, hell yes.
   * Have screen-sharing calls where we walk customers through the process of linking our product with third parties (e.g. OAuth pairing with Square so they can process payments).
   * Call customers who are want help or advice with _other parts of their business_ that aren't related to our product, but about which we know something. Don't know what you should put in your vendor contracts or what % you should charge for sales commissions? Give us a call; we'll help you out.

It'll work until it doesn't, I guess, but so far doing things that don't scale is how we scale.

This isn’t a knock by the way. Good customer service makes a customer feel like there’s someone just waiting at the company to help them. Kudos to you for providing that experience.

So while these aren’t great examples of “doing something that doesn’t scale (with the eventual goal of scaling)”, it’s a great example of “doing something that doesn’t scale (to provide a better product)”.

I think you’re referring specifically to Google and Facebook, and you’re right. I think the big difference is the amount of profit per customer.

Google and Facebook make a small amount from a large number of people so it makes sense that they could not profitably scale customer support. In the instances where they make a large amount of money off of a small number of people, mainly ad sales, their support is much better.

We also had months where one could get assigned to spending 3 whole days helping a customer port all of their emails and photos out of a corrupted windows outlook installation over to their new mac for no other reason than they'd asked for help getting it done.

Or where you would be celebrated for spending 5 hours with a 65 year old grandmother buying her first computer carefully going over all her needs and specs and down selling her from what the competitors had convinced her she needed (seriously, no 65 year old grandmother getting her first computer needs the hardware or associated software to cut together professional film in order digitize her collection of VHS home movies) and finish up with a sale of maybe $1300 and directions to competitor down the street because they have better photo printers than the few we carry in stock all on the (IMO correct) theory that a customer who can trust you to exactly what they need and nothing more and send them to a competitor for a better product is one who will come back again and again on the basis of that trust.

I don't know how expensive those two interactions were in the short term, but I do at least know that 65 year old grandmother became a regular customer and could not stop telling all the other customers how much she loved us. For as many problems as I did have with how Apple hamstrung their people, I do wish more companies were even half as good as that.

I don't like Apple too much and try to avoid their products, but can't lie never had such a good customer experience.

The last time I had to talk to a human (and it was two years ago) was because I accidentally left a fire stick behind in Puerto Rico two years prior and someone bought a few seasons of True Blood with my Amazon credentials. They still refunded me, even though it took me two years to notice the charge.

I can't find the article now, but I read a piece about the volume of returns and what happens to them ("reverse logistics"). Basically, companies find it's more profitable to always allow returns and keep the customers happy -- and often, they'll let the customer keep the "returned" product because even if the product works 100%, the cost to ship and verify is below what they'll make reselling it.

I thought this was an interesting contrast to LL Bean, who a few years back decided to end their lifetime guarantee, and naturally upset some lifetime customers.

I am convinced a robot just snags "one of each" from a bin, and if some packs are broken apart and separate... then they meet that logic.

No? I've had issues with an external monitor and had an applecare specialist debug a bunch of settings and then schedule a call with me for the next day after they heard back from the escalation team. Thankfully I bought a different cable which fixed my issue, but they are very nice for support from my experience.

I must also say Uber's CS is absolute garbage. I just cannot believe how bad they are. I have been unable to use uber for weeks and have been reaching out to them non-stop every few days. It is like speaking to a brick wall.

Try reaching out to their Facebook or Twitter/X profiles.

I was thinking more specifically of the Ubers, Lyfts, DoorDashes, Instacarts of the world. They are providing a consumer service, don't really control the end-to-end experience that well, and when things go wrong they are very difficult to work with on a reasonable resolution.

But it might be some version of Michael Seibels's classic "Who is your customer?" (https://youtu.be/C27RVio2rOs?t=10m11s)

A BigCo can hire a lot of CS people but the best they can do sometimes is "we hear you and we'll pass along your feedback".

(At least for the business. My sleep schedule would improve amazingly!)

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125249 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/131316 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/131469 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130988 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132806...

From there, you need to build a culture that is welcoming of "strangers" contributing code. You get these two things, you get nits and gotchas fixed directly from pain points customers are having, while product engineering is (mostly) focusing on feature dev.

Tier 0 are effectively secretaries who can file structured info around issue.

Tier 1 are dedicated support people who can follow scenarios and guide customers through the product.

Tier 2 are what you call "support engineers". They know the product, features, code, upcoming features and so on. For an in house product they are capable of making straightforward bugfixes.

Tier 3 is sometimes called "vendor support". For an in-house product this is effectively product development team.

As you can see, good supports bleeds into or blends with product development. This is how you get support answers like "this feature is planned to go live Y24Q1, but you can sign up to beta in exchange for feedback" or at least "This is not supported, but you can use features x and y to achieve similar result", instead of "Sorry, such workflow is not supported"

For example, when you're sitting there walking them through something they could do alone, are you just playing back some script, or are you getting an understanding of where they went "aha!" and making note of how you can embed that aha moment into the product itself?

It basically scales fine, the problem for companies trying to bump margin is it's roughly linear with customers...

If we were in the devtools business I would certainly consider that. Sadly, though, owners of small retail businesses tend not to be as comfortable with version control as one might hope…

This is definitely one that doesn’t scale as eventually they don’t allow devs to see prod data, so using user accounts is a no go at my org for that reason.

Makes things infuriating for both clients and customer support.

Which leads to some pretty boring days onsite, when “onsite” means “in the SCIF”

Though there's a big sliding scale there, between "not allowed to look at prod user data for privacy/etc reasons" and "the giant black hole of nothing-comes-out" in a SCIF.

I would say 95% of my intellectual horsepower at work goes into queries and analysis of production data tables, event streams, and logs to investigate issues or confirm key invariants are holding. Production is infinitely more creative than anyone sitting down to write unit tests. Organizations refusing to learn from it, as a matter of policy, either have incredible confidence in their testing and formal verification regimes… or much more likely don’t give a shit about correctness.

- The Airbnb founders took photographs for listings themselves.

- ProductHunt started out as a newsletter, with the founders themselves hunting and curating products.

- Reddit founders submitted links (wrote comments?) everyday using different usernames, to get the community going.

- Dropbox launched with a video demonstration and an email signup page to gauge viability. The product wouldn't be ready for another year, iirc.

- Doordash was a single webpage with a phone number (and 5 students?), serving just Palo Alto.

- Meesho was a WhatsApp group (one of the few teams in the batch that failed to raise money on Demo Day, afaik).

- Segment was a single javascript file viz. analytics.js.

clearly unethical behavior, but whatever...

they also removed third party apis and mod tools before an ipo. If one had bad thoughts they would think increasing their own app numbers and reducing tools to remove bot activity would be unethical ways to bolsters user counts before a sale. But that would not happen

However he defended the place publically, and gave an award called Pimp Daddy to violentacrez, which shows some level of consideration and recognition by the now CEO of reddit.

looking at it with the hindsight of time, the "free speech" defense rings a bit hollow considering the communities they were protecting at the time

> What did they lie about?

Fake users being piloted by the same person behind the screen. If that's not a lie, then I don't know what is.

We're talking about Internet discussion forums here.. The amount of fakery, lying, bullshit and outright awfulness that happens on forums every single day across the whole Internet is staggering.

If they used aliases to kickstart discussions and try to get people involved and contributing, I'm not sure that's something to get your pitchfork out about.

I can't remember if it was product hunt or not, but there was one such site that actually started as a way for the developer to feed attention to their other startup. Turned out producthunt (or whatever one I'm thinking of) became successful instead.

Can we please not celebrate scammy behavior?

> And I would find invented discussions less engaging

I would predict that I would, too - but, evidence suggests that it was engaging enough to get people interested, so maybe our predictions are incorrect.

In the case of something like Reddit, you come to read content, and once you've readit, you write it, and then read some more. I'm not sure you're ever really sold that you're even engaging with actual people.

These days, I frequently wonder what percentage of comments on any of these sites is genuine (although I happen to believe it's still a pretty high percentage). Its good to assume noble intent, but to also carry around skepticism.

It's much more broad than that. A common sales tactic is to pretend there are other folks interested in what's being sold; maybe this is to make it seem popular, maybe this is to push Buy It Now for a limited (maybe one) item. Some folks will have a fake interested party show up in person.

I would call all of that a scam, even if I'm paying the listed price and get what was promised.

Dishonesty is not sufficient to render something a scam - the scam-ee needs to "lose out" in some way. In this situation, I don't believe they did.

Years ago, I was trying to rent an apartment. After the visit, the owner, an old lady, invited me to some tea in her own home nearby.

Not sure how the conversation came to that, I think it started with me asking about a parking spot, but she told me that washing the car is for poor people.

"For someone that drives a nice new car like yours it doesn't matter too much if it's clean. It's the guy with an ugly old car that spends a lot of time cleaning it, hoping that it will look better".

I didn't rent the apartment, but I learned a valuable lesson: don't worry about a little dust here and there.

Who cares about laws? It's just bad karma. You are deceiving people for your own profit. Whether it's legal or not does not matter at all. it's just what douchebags do.

Is upvoting your own submissions on HN ok too?

(And no, self upvoting/ringvoting isn’t ok on HN and probably hasn’t been on Reddit for 17.5 of the past 18 years either. We’re talking about bootstrapping a totally new site in 2005, nothing more.)

Artifical users on dating apps are OK?

>The site is literally called Hacker News and it was built from the start to be a community of current/potential startup founders.

Im aware, so thats why probably ppl here are ok with those manipulative practices used to bootstrap.

Reddit’s practice was a simulation of activity to see what kind of activity was engaging. Nobody was defrauded or harmed and no legal or moral rules were breached.

This comment commits the beg-the-question fallacy of assuming the conclusion (fraud/moral breach) in its argumentation.

I understand that people have a need to believe that behind every fortune lies a great crime [1], but this is not the smoking gun people are looking for.

[1] https://quoteinvestigator.com/2013/09/09/fortune-crime/?amp=...

My point is that it's needlessly grumpy. It's fine if you want to be grumpy! But it's worth examining why this is a particular thing that triggers you. Far worse lies are told by politicians of all stripes every day, and we accept it as part of the system (particularly if it's a politician we voted for, not so much if it's one we voted against.) We should have a think about why we're getting tied up in knots over some shenanigans played by a couple of early 20-somethings almost two decades ago.

Who pretended that we were OK with politicians lying through every breath? Don't put words in people's mouths.

According to Dang there are (or were) 13,000 comments a day [1], if we assume "most" to be ~6501 with an average comment length of 65 words, that's 422,565 or ~211,000 words per day from our two gracious moderators. Assuming the standard working hours of nine to five, that would equate to 26,375 words per hour or 439 words per minute, coincidentally breaking many records.

1: https://news.ycombinator.com/item?id=33454140

(yes, I realise this comment is slightly OTT, but I was interested to see what the raw numbers would be)

While I was building out this feature, I'd stay up late in the night manually selecting clusters of houses and setting them for the customer, so the next morning they'd be greeted with what looked like our backend systems auto-magically picking the perfect cluster of houses.

The bonus of doing it manually for a while is that I found a lot of edge cases I would have missed otherwise. The initial release of the finished feature was rock solid thanks to what I learned.

This is one of the great benefits of doing things that don't scale. Reality has a surprising amount of detail, so to write code for a process you need to be an expert at that process. How do you become an expert at anything? You have to do it for yourself.

We were developing software for MS PocketPC, and at one point implemented some registration system that a colleague wanted to approve manually for each user. (Was kind of like a new test or something, can't remember the exact details anymore).

Anyway, me as an developer said: "You care crazy, this needs to be automated, what are you going to do when we get 100 registrations a day?". Business guy responded: "That's a problem I would love to have! I would happily validate 100 registrations per day, because that means we'll have the funds to automate it!".

Long story short, that specific system never took off and automating it would have indeed be a total waste of time.

Since then, I sometimes fall back to the question "is this a problem I would love to have?"

It's actually something I use all the time when on a small team. My argument goes something like this though: "lets work on it when we have an actual problem to solve, right now, we're just making one up." Basically, once manually doing something becomes a part-time job, then it is worth automating. Before then, it is simply an invented problem.

> As an example, Ries noted that Zappos founder Nick Swinmurn wanted to test the hypothesis that customers were ready and willing to buy shoes online. Instead of building a website and a large database of footwear, Swinmurn approached local shoe stores, took pictures of their inventory, posted the pictures online, bought the shoes from the stores at full price after he'd made a sale, and then shipped them directly to customers. Swinmurn deduced that customer demand was present, and Zappos would eventually grow into a billion dollar business based on the model of selling shoes online.

It also is very common for "AI" startups to have the AI just be manual work, though this can be controversial: https://www.404media.co/kaedim-ai-startup-2d-to-3d-used-chea...

We also definitely did it in the early days of my non-profit — we wanted to build a very optimized public records submission platform that handled mail, fax, etc., but in our early days I literally hand delivered records requests, which was super helpful from learning but at $2 per request was a huge money-not-maker.

When people bought them, the team would run out with a credit card and buy a car for real and then sell it to the online user.

True story.

This is different to the practice of buying up stock on sale and reselling on marketplaces.

Note that if strict, this would ban made-to-order sales that aren't marked as such to the customer.

We are in Phase One testing of our NPO flagship.

It has been designed as a native Swift iOS-only app (but the backend will feed anything).

It also has a few design "tricks" that probably won't scale to millions, but has been tested with tens of thousands (of fake users). They make it lightning fast, and it will be a sad day, if I have to sideline them, in the future.

We sign up users manually, one at a time. I'm developing a dashboard, to lubricate that process, but it will still be manual.

Fortunately (for us, but many for-profits would hate it), I think it will be a long time, before we get to the point where matters of scale become an issue. We Serve a small, demanding, demographic.

Also, we don't collect PID. Extreme privacy and security are a big part of our model. I deliberately avoid a lot of the dependencies that could introduce issues.

There's a barrier to being able to downvote, but the only downvotes I actually see on HN seem like they're given in bad faith. I'd love an option to turn off displaying downvoting at all since it's never useful to me; from my perspective random comments just fade off a page, usually in the middle of a thread.

Otherwise, it is absolutely relevant to the topic at hand. I described:

1) Native iOS-only (not something that will necessarily scale. A large part of our demographic uses Android, and I am regretful that we don't Serve them, but I don't write Android, and don't want to use a hybrid system or PWA)

2) Uses "tricks" to improve performance (I mention these may not scale into the millions. An example is loading a fast list of minimal info on all the users on the system, so we don't have to do realtime searches)

3) We do sign up users manually (BTW: lots of other posts, here, say pretty much exactly the same thing).

But it could also be because I mention that we don't collect PID, and that I eschew dependencies. These postures don't play so well, in today's tech industry. Dependencies are how to scale, but they can also add risk; sometimes, big risk. If we screw up our data, it could put people's lives, careers, and families, in actual, physical danger, so we're kinda anal about that.

But our app will be great. It absolutely Serves its users well, and we're already getting a great deal of positive feedback (We've only been testing since Monday). My main concern is that we may have to scale sooner than I expected.

If you are truly interested in what it will be for, feel free to get to me, offline.

Apparently they had a bell that would ring every time an order came in. They soon had to turn it off.

from https://allenpike.com/2023/dialup-world-isp:

"1. When a customer submitted their signup form to Dialup World, they would add a row for that new customer to their 20,000-row Excel spreadsheet.

2.Then, they would put that signup form in a pile with all the other signup forms of customers who had signed up on that day of the month.

[billing steps removed]

5. When a customer called to cancel their service, they would stop that customer from being billed further by simply – I shit you not – finding that customer’s signup form and trashing it. No signup form in the pile, no more bills going out.

You gotta hand it to these people. The seminal startup essay “Do Things that Don’t Scale” didn’t come out until 2013, and these legends were doing things that didn’t scale way back in the late 90s. They got 20,000 signups billed with the process equivalent of a shoelace and a discarded sauce packet."

Assuming they distributed the signup forms evenly amongst the 20 working days of a month, that would mean the billing group would have 1,000 bills to handle each day. Slogging day in, day out, forever. Might as well have named the group/department Sisyphus.

I personally answer every support email. My wife once asked me how many customers I had. Then she asked how many email support emails I’ve handled over the same time period. They were about equal (5 figures over 5 years)!

https://label.live/

Edit: on second thought, maybe I did things that DID scale. Hmm…

A giant university student housing department changed their FMMS system from Apple Newton MessagePad 130 from Symbol MC50's in the spirt of Barcodes and database for all the things! In that era, I had ~50 unique smart PDA-barcode scanners on my desk.

The final contenders came down to the MC9000, MC50, and MC430. The MC9000 was "too expensive" despite meeting all of the requirements, so the MC50 was chosen.

PS: I acquired an eMate 300 because it's quirky and interesting.

That's similar to me. Roughly the same amount of support emails and customer orders. The funny thing is when I looked deeper most people raising support issues didn't buy and most people who bought never raised a support issue.

On the subject of label printers one of the things I'm looking forward to in retirement is never touching a printer driver for a label or receipt printer again. They caused me so much aggravation.

Many times there’s a PDF for the printer “language.” Think ZPL or TSPL. But even then, each printer has quirks (two incompatible settings) or a setting that’s unitless (dots? mm?) and the best way to nail it down is by using a USB sniffer, capturing the commands, and then implementing similar custom controls and logic in the app.

By doing that I not only ensured they were up and running in good shape, but I learned what it's like to be the person installing and maintaining them. We have an installer in town who made the intro to that customer, but for this new product it was a big learning experience to be there, doing it myself.

I always thought about a product like that in my area but the "features" you mentioned (soil/climate conditions monitoring) are pretty simple, so I wonder if you're still able of finding a market (fit) for products like that, that "anyone" could build. Are you able to find customers, which I assume is B2B?

For example: one of the simplest things I've built this year is a device that reads an input and then turns on an LED and sends a message to a connected app (I didn't write the app) when the input changes state.

After I shipped the first one, the customer came back and asked for 10 more and they expect that over time they may need about 100 or so. I can do stuff like this all day long: it's technologically trivial, but world-altering to the people who need it.

My main problem is getting people who need these little machines to know how to find me.

I paid $11 for it, which is a lot more reasonable than the current $30, but if it helps a plant you like grow... I don't actively monitor it with an automation, but I recall poking at it with one of the NRF apps and seem to recall that the data format was open enough that you could monitor it outside the official app.

Excuse me? Could you please rewrite that one?

The very first version was an old Android phone sitting on my desk that I connected to Trello for messaging and Bria for voice calls, for a handful of clients.

We later launched an app, but we didn't build the app ourselves we licensed it from a 3rd party vendor who does white labelling, and we used their demo version to sell the first corporate customer, who's setup costs paid for the white label one-off licensing costs.

Then we developed a proprietary, scalable hardware platform to manage the connections so we don't have to use Android phones anymore, but we still don't have our own VoIP stack, so when customers express interest in a free trial, we have to firstly contact each one to make sure they're genuine (almost all free trial requests are from scammers). Once they have tried the product, they put their details into DIFFERENT TypeForm, then we have to manually enter those details into our VoIP reseller platform and create the users and devices in the PBX, then we have to email our mobile carrier to provision the numbers because we don't have a direct wholesale connection yet.

That whole process can be automated once we have a different VoIP platform and have wholesale carrier connections.

- Applied to devops jobs on Angelfish, target companies with 10-20 employees

- Passed their phone screen, learned about the particular automation problems they had

- Offered them a SaaS subscription with a promise to set up a working solution in my product for their problems.

- Explained that subscribing to my service would be much cheaper than hiring me.

Most declined, a few were offended at my bait and switch, but 3 of them became my early customers and used my service for years, eventually taking over and maintaining their own solutions.

I think identifying the right customers- other startups with VC cash that were too small to have too much red tape and had big problems without tools and staff- made this work in the early days. It was a blast working on this stuff back then.

I don't want to pay any cloud costs, so all the scraping, flashcard creation, etc are just shell scripts on cronjobs that runs every hour or so on my personal laptop. The back catalogue is persisted to my other devices via Syncthing, instead of living in S3. I give the deck a manual review every day before I send it off, which I guess also counts as dogfooding.

Most people didn't engage, but some did. I was able to nip some onboarding issues in the bud, and develop some evangelists as well.

Some bigger companies automate this, but I always found it feels weird coming from a big company. I was always careful to put "founder" in my email signature, so the recipient knew it was coming from me. And I never sent the email right after they signed up, which might make it seem automated — even though it wasn't.

It seems perfectly plausible that 95% of the customers of an app or online don't want to enter into an email conversation about the service - they just want it to be usable without need for further communication, and they aren't interested in getting involved in your wider sales strategy either.

1. Your first environment is production. Any other environment exists to protect production from yourself. I worked somewhere where the first environment was staging, then they built production. It was a disaster and staging eventually became production and the original production became staging.

2. If you've been giving away your product for free. Reach out to ALL your free customers before implementing pricing. There are probably edge cases / markets you haven't considered.

A good example here, was reading a reddit comment about some k8s management startup. So we decided to give them a try. The software was absolutely amazing for our bare-metal cluster! So, we went all-in. Then, we went to setup a new cluster a couple of years later to discover that it was no longer free. They never even told us we were grandfathered into an old free plan. Now, we probably would have paid them for a long time ... and told them their pricing was insane, a per-seat pricing would have been better.

Our cluster has hundreds and hundreds of cores for less than $500 per month. They want to charge per-core, and would cost >$2k. They were aiming for the "cloud market" where if you're paying them, you're paying them a small percentage of what the cloud costs. This is sensible, but unrealistic for our kinds of deployment, where simply launching a new server would increase our costs by hundreds of dollars instead of $50.

We reached out to them to make a deal, and they were unwilling to make a deal and treated us as though they did us a favor by grandfathering us in to a free plan all these years. Maybe they did us a favor, but they never communicated that so now we're dealing with sticker-shock and trying to figure out a way to move forward.

Needless to say, we left them with a bad taste in our mouth, and found a better tool. So, yeah, communicate to your free customers that pricing is coming but they'll be grandfathered in; and they can support you by upgrading to a paid plan.

That would have (A), triggered us to evaluate whether the tool is worth it from the get-go, (B), probably would have resulted in us purchasing a license, and (C), we would have been able to tell them much earlier in their journey that they're missing out on an entire market-segment with their pricing.

This is a little tangential but another good piece of advice is to avoid over optimization of the engineering stack. A giant monolith running on the largest RDS instance AWS provides a lot more runway than people realize.

The original sin of Software Engineering is building a really well architected system that solves the wrong problem.

The long-term goal was that scientists would describe their native software environments at a high level, and then the machine would build a Docker container that matched. In practice, your typical academic has no experience with containers/Linux/system-level dependencies. To prevent their walking away, I basically set up their software environments for them on an individualized basis when they reached out to us through intercom.

As PG says elsewhere, one of the main advantages of an early-stage startup is they can devote an insane level of attention to early users.

[0] https://codeocean.com/

The product is a technical documentation platform, and most customers are coming from an existing solution - be it an open source static site generator or CMS of some sort. The pain of migrating is usually a big factor keeping teams in their existing setup, and doing the migration for them eliminates a common objection.

We'll likely keep doing this even as we grow, but right now we tend to offer this service regardless of the size of the customer. The combination of great customer service and everything we learn while migrating the existing content makes it worthwhile.

If there was a mess-up, to save the cash bleed, I or one of the co-founders would hand-deliver the follow-up delivery ourselves, and apologize in-person. I would like to think our customers thought we literally went the extra-mile to ensure their satisfaction.

And because a lot of restaurants were set in their ways, if we had to send them a fax for a $1,000 order or call them by hand and manually speak to them the order item-by-item, we would. There are many delivery companies, but only a handful of institutional, famous restaurateurs.

Yeah I haven't updated my site in a long time. I left Netflix nine years ago.

The postcards went in with the merch and that package was sent to the person who bought the merch.

1. Manually copying and pasting data that can’t be easily programmatically extracted from PDFs/web pages and manually compiling a valuable dataset instead of scraping it, or using some scalable way to gather it such as getting it from users.

2. Finding users on Twitter who mention a specific pain/problem you’re solving and messaging them and having a conversation with each and every one of them.

3. Keep track of the news pertaining to your industry and manually finding journalists and sending them each a custom pitch related to your startup when a news headline or topic becomes popular

https://youtu.be/HSVFZ2Qbv3I?t=5681

Ditto for more “scalable” marketing like ads or PR. It’s (usually) best to save those until after you have a core group of happy engaged users that you cultivated by hand.

There are exceptions where people do the big launch or large-scale marketing right away and it works, but the risk of failure with that strategy is high.