In PG's essay he talks about manually doing what you later plan to automate and gives the example of stripe manually onboarding startups. Does anyone else have other examples?
At Lugg (<a href="https://lugg.com" rel="nofollow noreferrer">https://lugg.com</a>) we did a few things that would not scale.<p>- My co-founder and I did all the Luggs ourselves in trucks we rented through GetAround for the first 4 months<p>- 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<p>- We launched without payments and would charge customers with a Square reader at the door<p>- 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<p>- 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<p>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
"Do Thinks That Don't Scale" is probably the <i>absolute heart</i> of my (bootstrapped, two-founder) company. Off the top of my head, we:<p><pre><code> * 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.
</code></pre>
...plus probably dozens more that aren't fresh on my mind. We work flat-out to onboard every single customer, no matter how small, because word-of-mouth is our only growth channel and delivering a surprisingly human onboarding/support experience is the best way I know to generate great referrals. It doesn't scale, but it's also probably our main growth driver.<p>It'll work until it doesn't, I guess, but so far doing things that don't scale is <i>how</i> we scale.
Some examples:<p>- The Airbnb founders took photographs for listings themselves.<p>- ProductHunt started out as a newsletter, with the founders themselves hunting and curating products.<p>- Reddit founders submitted links (wrote comments?) everyday using different usernames, to get the community going.<p>- Dropbox launched with a video demonstration and an email signup page to gauge viability. The product wouldn't be ready for another year, iirc.<p>- Doordash was a single webpage with a phone number (and 5 students?), serving just Palo Alto.<p>- Meesho was a WhatsApp group (one of the few teams in the batch that failed to raise money on <i>Demo Day</i>, afaik).<p>- Segment was a single javascript file viz. <i>analytics.js</i>.
I had a product to help political campaigns canvas neighborhoods door to door. In the early days there was a "smart walk sheet" feature, which would magically pick the optimal doors to knock given how much time you had (e.g. 2 hours after work).<p>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.<p>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.
I manually review the ~3000 or so domains in Marginalia Search's random exploration mode every once in a blue moon. Takes like a solid afternoon but I'll be damned if it doesn't improve the experience quite a lot.
I have an example before this became a thing, and was actually framed as "that's a problem I would love to have".<p>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).<p>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!".<p>Long story short, that specific system never took off and automating it would have indeed be a total waste of time.<p>Since then, I sometimes fall back to the question "is this a problem I would love to have?"
If you're interested in this area, Lean Startup (book or general resources from that area) might be helpful. One example from the [Wikipedia Page](<a href="https://en.wikipedia.org/wiki/Lean_startup" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Lean_startup</a>):<p>> 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.<p>It also is very common for "AI" startups to have the AI just be manual work, though this can be controversial: <a href="https://www.404media.co/kaedim-ai-startup-2d-to-3d-used-cheap-human-labor/" rel="nofollow noreferrer">https://www.404media.co/kaedim-ai-startup-2d-to-3d-used-chea...</a><p>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.
Just remember to automate the manual process at some point.<p>from <a href="https://allenpike.com/2023/dialup-world-isp" rel="nofollow noreferrer">https://allenpike.com/2023/dialup-world-isp</a>:<p>"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.<p>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.<p>[billing steps removed]<p>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.<p>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."<p>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 bought a hundred different label printers off eBay/amazon so I could reverse engineer and test all the different protocols. Now my app works with most label printers on the market and manufacturer’s send new models to me without even asking.<p>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)!<p><a href="https://label.live/" rel="nofollow noreferrer">https://label.live/</a><p>Edit: on second thought, maybe I did things that DID scale. Hmm…
I'm building a new product for farm monitoring (IoT device that monitors soil moisture and other enviro/climate conditions). I spent a whole lot of time in the past few weeks hand-soldering circuit boards using prototype boards (one step up from breadboards), then drove ~10 hours to a remote town to install them on farms and stayed around for a few days to get/keep them working.<p>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 run BenkoPhone which is the only business mobile number app in Australia that supports voice, txt and picture messages, currently 211 paid users in 50 different companies and $100k ARR.<p>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.<p>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.<p>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.<p>That whole process can be automated once we have a different VoIP platform and have wholesale carrier connections.
In 2014, I built some tools to make it easier to automate AWS and Google Cloud deployments. I did the following:<p>- Applied to devops jobs on Angelfish, target companies with 10-20 employees<p>- Passed their phone screen, learned about the particular automation problems they had<p>- Offered them a SaaS subscription with a promise to set up a working solution in my product for their problems.<p>- Explained that subscribing to my service would be much cheaper than hiring me.<p>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.<p>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 have a small side project where I scrape a Finnish news site and generate high quality flashcards from its content for fellow language learners in the form of a daily email. I sell bulk access to the back catalogue for more serious learners.<p>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.
I build synthetic DNA. In the beginning (and still) I do a ton of steps by hand that I’ve slowly been moving to robots. Hours and hours at a bench picking colonies, designing sequences by-hand for customers instead of using software, writing robotic scripts for one particular customer’s needs, that kinda of thing
For a time, I emailed every B2C customer who signed up. I welcomed them, asked where they heard about BeeLine, and told them if they ever had any questions they could email me directly.<p>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.<p>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.
A couple of things:<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
My first employer is now a decently well known B2B SaaS and we didn't build user interfaces to manage various settings for a very long time. For example, we supported custom fonts, but we would have to jack into production to upload them and manually configure the database to make them available to a given customer. That ability didn't become customer-facing for a decade, simply because it was easier to file a ticket and make an SRE do it.<p>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.
I'm in a pretty low tech industry but that mindset basically describes every system I've built.<p>The original sin of Software Engineering is building a really well architected system that solves the wrong problem.
I was an early hire at a computational reproducibility startup for scientists [0]; the platform was basically an online frontend wrapped around a Docker container hosted on AWS, and the idea was that you'd put your code and data on the platform and have it be online-executable indefinitely, so you wouldn't have to worry about package updates, functions breaking, etc., because it was containerized.<p>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.<p>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.<p>[0] <a href="https://codeocean.com/" rel="nofollow noreferrer">https://codeocean.com/</a>
For us at Doctave (<a href="https://www.doctave.com" rel="nofollow noreferrer">https://www.doctave.com</a>), migrating customers from existing solutions manually ourselves has proved very effective.<p>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.<p>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.
During the pivot to Caviar (www.trycaviar.com), we were very cash-strapped and had to do most of the deliveries, customer service, and restaurant ops ourselves. We did this growing from 50 orders a month to over 150+ orders a day, non-stop.<p>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.<p>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.
When reddit first started, all merch was hand packed by Alexis with a note in it. At one point he sent us a stack of 1000 postcards and made all of us sign them, and then used those to pack the merch.
Some examples:<p>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.<p>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.<p>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
Amazon same day delivery was supposedly bootstrapped by ordering ubers via burner phones. Bill Gurley (uber investor) happened to find out during an uber ride talking to his driver.<p><a href="https://youtu.be/HSVFZ2Qbv3I?t=5681" rel="nofollow noreferrer">https://youtu.be/HSVFZ2Qbv3I?t=5681</a>
When looking for early users for a new product, it’s usually better to reach out directly to people one at a time or post in small communities like niche subreddits rather than trying to do a big launch on HN or ProductHunt with the hope of getting a lot of users all at once.<p>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.<p>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.
When we started Chimpy in 2014 (power bank rental company in Switzerland, later more EU countries) we got suitcases and hauled the charged power banks to the convenience stores and hauled back the returned ones. Not using cars, but using trains and buses. This was not efficient nor fun, but doing this got us through the pilot phase successfully until we had enough volume to work with a proper logistics company to do this for us. It also allowed us to speak to the people working at the stores and get direct feedback.
My database technology startup, Fireproof, recently hung out a shingle for custom app development, primarily as an adoption tactic. If we really do have the most productive tools for front-end devs to build data-driven apps, we should showcase them by writing code for real-world customers. Over time we expect services revenue to be a smaller slice of the pie, but if we can make creating the first round of social proof into a financially sustainable practice, we can scale with more confidence because we know we built what customers want. We just launched this today, so you'll have to follow up if you want to know how it goes: <a href="https://fireproof.storage/service-and-support/" rel="nofollow noreferrer">https://fireproof.storage/service-and-support/</a>
In ETL work I often come across a nightly job that is harder to implement than most for some snowflakey reason, and I just start my day doing it manually, which might just take a minute. At some point I will get so annoyed that I will take the time to figure it out properly.
There's a whole class of problems I call "small data" - under about 100 things (note: often your sample set is a year lookback, so for example new customers might be > 100 but only 100 for this year, still small data). Anything that looks like that is often able to be handled manually and probably should be until it's sufficiently useful to automate...things that look like this often are: customers, employees, infrastructure.<p>In general, put off automation for anything that's not every day or month that you can't just do in a few hours , e.g.:<p>* Parts of performance assessment & compensation tooling<p>* Sophisticated recruitment analytics (especially important because with small data it's often not precise or accurate/needs manual attention)<p>* Provisioning new stuff that doesn't happen often: databases, clusters..etc.<p>* Maybe the biggest bucket of stuff in general is analytics. Often times people try to get whiz-bang end result numbers with data sets of like 100. It's almost always the wrong move to have crazy analytics abstraction layers and automation when the numbers are small.<p>A potential simple heuristic might be something like: if it take a day or longer to automate, you need to save at least 5 days of time in the next 6 months for it to be worth it.
<p><pre><code> if (user.orgID === 'importantCustomer') {
bespokeFunctionality();
}
</code></pre>
I guess everyone will encounter this one at some point?
I violate DRY all the time in terraform. My process is roughly to write something that resembles a module, and when I need it again, I copy all the code and just change relevant variable values and see how it behaves. if I need to copy again a 3rd or 4th time, usually by that point I will have learned things that allow me to make a much better module/library than if I had relentlessly and mindlessly followed DRY.
when we started the vidalia onions project, nothing was automated. We'd accept order w/ stripe integration. We'd manually type in shipping info into UPS shipping terminal & print shipping label at packing shed. We'd then package & ship the Vidalias. Nowadays we've somewhat automated that through shopify & shipstation integrations. (ie. this project: <a href="https://www.deepsouthventures.com/i-sell-onions-on-the-internet/" rel="nofollow noreferrer">https://www.deepsouthventures.com/i-sell-onions-on-the-inter...</a> )
Original test automation application.<p>I wrote a new test automation application because in my primary personal application I need to run test automation in the browser, I needed it to be faster than prior existing solutions, and I needed it to be distributed to browsers on different machines of the same local network. The test samples for this new test automation application are just JSON data structures defined against a TypeScript interface, so the code editor literally tells you what properties are missing to complete a test and what the allowed values are.<p>Its faster than other test automation tools for the browser because it does not make use of CDP. Instead a test receiver is required to be embedded in the given page(s) which evaluates the tests and transmits the results. Its also faster because it only uses WebSockets and not HTTP. I was executing 89 tests comprising a total of 284 points of evaluation against event execution in the browser at 6.22 seconds from Node start to test completion.<p>This took tremendous trial and error to get correct, but now I have experience writing and executing test automation at a depth that almost nobody else has and can do it faster than all the popular test automation applications. It also required that I rewrite large portions of my primary personal application to make everything WebSocket based for faster execution across the board and also to greatly simplify the service/transmission architecture on both the browser and the Node layer.<p>This experience is winning me employment at higher rates when many senior developers are challenged to find new employment. Writing this new test automation did not scale at all and took tremendous time to get correct and stable, but now it allows scale and rapid execution of colossal refactors I could never do before. Since the test automation executes on the local machine only in less than 10 seconds I find that I was running it dozens of times a day for large feature enhancements.
ZeroCater started as a guy with a spreadsheet managing orders by hand:<p><a href="https://techcrunch.com/2013/04/06/how-i-started-zerocater/?query=4664" rel="nofollow noreferrer">https://techcrunch.com/2013/04/06/how-i-started-zerocater/?q...</a>
One of the things that we did at Kapwing (<a href="https://www.kapwing.com" rel="nofollow noreferrer">https://www.kapwing.com</a>) was manually edit videos using our own platform and sharing these videos with bloggers to try to convince them to use Kapwing. We could create a relevant video from an article that they wrote, and then share them the link to the project so that they could edit it directly with our tool.<p>Another random thing we did was try to make chalk posters on the streets of SF. We chalked our logo out in front of the 4th and King Caltrain station so that tech people would see it when coming out of the station. Unfortunately, that only worked for a day though, because the SF crews are very good at powerwashing the sidewalks.
This is in a different direction than most people, but i think the "SoftSecurity" approach of early wiki sites fits. <a href="http://meatballwiki.org/wiki/SoftSecurity" rel="nofollow noreferrer">http://meatballwiki.org/wiki/SoftSecurity</a><p>The idea being instead of blocking malicious people or doing automated detection, you should spend human labour to just undo them until they go away.<p>Early wikipedia from what i understand didn't even have a block function - instead if someone was too overwhelmingly problematic you had to find someone with server access to block the IP on the webserver level.
I once sent a snail mail letter from my little company to one of our subscribers in another country who was having trouble and emailed us about it several times but was apparently not receiving our email replies. It worked. :-)
Here is an example of a successful business bootstrapped that way: <a href="https://twitter.com/levelsio/status/1717183107529576672" rel="nofollow noreferrer">https://twitter.com/levelsio/status/1717183107529576672</a><p>Quoted here:<p>First version was an index.html +
@Stripe
link +
@Typeform
to upload photos, then I manually dl'd the photos and uploaded them to the GPU<p>Pic 2 is current version as a web app after 1Y: 100% automated, 1850 customers @ $79K MRR, renamed to <a href="http://photoai.com" rel="nofollow noreferrer">http://photoai.com</a>
Here's one I saw today on X<p><a href="https://x.com/levelsio/status/1717183107529576672" rel="nofollow noreferrer">https://x.com/levelsio/status/1717183107529576672</a>
The Y Combinator YouTube channel has videos with specific examples. <a href="https://www.youtube.com/watch?v=TCPjk8Tpb5c">https://www.youtube.com/watch?v=TCPjk8Tpb5c</a>
At my startup (<a href="https://polifinity.com" rel="nofollow noreferrer">https://polifinity.com</a>) we do allmost everything manually first and only build when we have "proof" that an idea works.<p>Examples:
- we do not have onboarding automation, instead a simple make.com trigger is send and then we do onboarding from a team member
- we have not build all parts of the product, but instead use very simple manual processes to simulate a LOT of the more expensive features - only after feedback we actually invest development time
- we have an intelligent reminder feature, that is done using a google sheet + make.com and manual mail; building the feature is not cost efficient anytime soon
- the core of our product is about product strategy. Instead of building a complex interface in the app, we offer (free) workshops that are more effective, but absolutely do not scale at all...<p>In my past startups we sometimes did even more extreme "do things that don´t scale" stuff:<p>- giving you personalized recommendations generated within 30 min. from a human<p>- B2B matching from a web-page, where actually a mail was send and we generated the matches dynamically from different sources => this worked out AMAZINGLY well<p>- complex reporting from a huge database -> report was generated by a data scientist within 2-3 business days and then based on feedback the feature was never implemented, as every report was different and lots of time required data not actually in the database
' Do Things That Don't Scale' is a good approach when you have very few customers, but you have to start investing time in stopping it once you reach a large number.<p>What is manageable when you've got 5 employees and 1 customer isn't manageable when you've got 10 employees and 10 customers, because that support load is inevitably becoming more and more of each person's day.
At my last startup, our product required information that didn't exist in the digital world - the table of contents of hundreds of medical books. So I used to spend nights and weekends visiting local Barnes & Nobles and university bookstores pulling down books and manually typing out the table of contents with chapter titles, pages numbers, etc. Quite possibly the most boring job ever! Most bookstores didn't mind my presence, but I did get kicked out of one (thanks Harvard Medical School!). I tried to use OCR and other techniques and it just wasn't accurate enough (this was a decade ago so the tech wasn't quite as advanced as it is now). Eventually the company got big enough where I could have dedicated staff to handle the process, but for a long time it was how I spent my free time.
TL;DR: my co-founder and I hosted hundreds of 1-hour co-working sessions ourselves.<p>In the early days of what is now Flow Club, my co-founder and I had built several apps to try to help us stay in touch with busy 30+-year-old friends. It was tough to get any friends to even install the apps we made on Testflight, much less use them. They were busy with work or family (and the apps just weren't compelling enough).<p>We started asking friends to come work together on Zoom (during the pandemic) like we used to do at coffee shops. We wanted to add some structure to these, so we made them 1-hour co-working sprints with a screen-shared pomodoro clock and agenda (5 minutes to share goals, 50 minutes of working, 5 minutes to check in), sent out the Zoom links to friends, and then started pre-committing to times at the beginning of each week and sending that out to an email list. Within a month, we had hosted a couple hundred of these sessions between the two of us and couldn't keep up with the demand or requests for more times of day as it spread to friends of friends. When an early user who we didn't know IRL and then my partner each separately asked if they could also host sessions, we were blown away. We didn't think anyone else would want to volunteer to host. Then when we realized both of them were actually better "hosts" than we were, a lightbulb came on for us that we could stop doing the unscalable thing we had been doing and build for hosts.
At Enchant (<a href="https://enchant.com" rel="nofollow noreferrer">https://enchant.com</a>):<p>- We launched without billing. Early customers used the product for free until we eventually built out billing<p>- In the early days, the "mailing list" was just a loop that would send an email to signed up customers using our cloud email service provider.<p>- We manually verify all new accounts before they can do certain things. Abuse prevention.<p>- We offer data imports from competitors. It's a semi-automated process - sometimes there's existing working code, sometimes it needs tweaking, sometimes it gets written as part of the process. Either way, it's a win if it helps someone make a purchase decision.<p>- We manually reach out to customers when a feature they voted for is released. This is also a great opportunity to gather further feedback.
Some stories that I've heard personally:<p>- Tony Xu (DoorDash) figured out that many early users were moms, and he would go and knock on their doors to ask them why they would use the product, and where other moms would hang out so they could get more signups. All of the founders also took shifts to drive for the app so they had to use it themselves.<p>- Tom Preston-Werner (formerly GitHub) emailed tons of OSS maintainers, including John Resig of jQuery, to try and convince them to migrate over to GitHub. He admits that it wasn't a great strategy though - project maintainers have to convince themselves to switch VCS systems.<p>- Jessica Mah (formerly inDinero) became a CPA in order to do accounting services for her startup. She would talk to customers and make sales during the day, and study for the certification at night.<p>- Ricky Yean (formerly Crowdbooster) struck a deal with an early customer/cafe owner to get paid in food, so they worked from the cafe all the time. They ended up building the cafe owner custom dashboards which later become their product.<p>- Nikki Durkin (formerly 99dresses) spent $10,000 at a time on Nordstrom, listed the clothes on her clothing marketplace, and then returned anything that wasn't sold or traded to users within the 30-day return window.<p>- Jake Jolis (formerly Verbling) would act as an English speaker trying to learn other languages at all hours of the night in order to improve the matchmaking on his language learning app. Most people were their to learn English rather than the other way around.<p>- Rujul Zaparde (formerly FlightCar) stood in front of a major airport parking lot for nearly 12 hours with a sign that said "ask us about free airport parking". He had the cops called on him three times that day.<p>- James Richards (formerly Teleborder) paid people from Craigslist $20 to sit and use their app in front of them. It led to a lot of valuable feedback, and they ended up hiring many of them later on.<p>- Walker Williams (formerly Teespring) drove an hour and a half to Petaluma in order to pack and ship bobbleheads for a long-term client that wanted to sell something other than t-shirts, despite the fact that the company... only sold t-shirts.<p>A while back I had this same question - and I ended up writing a book on it: <a href="https://www.amazon.com/Unscalable-Charlie-Guo-ebook/dp/B019EGX6WO/" rel="nofollow noreferrer">https://www.amazon.com/Unscalable-Charlie-Guo-ebook/dp/B019E...</a><p>There's a bunch more in the book - I was lucky enough to also talk to the founders of Codecademy, General Assembly, and Zenefits. But those were some of the ones that I still remember pretty well.
Imagine each task you might possibly do for a customer (the responses to your post suggest many). At some point, 0% of the task is automated. You can do it for customers 100% manually.<p>If you do this for all of the tasks people will pay you to do, you can get a sense of "which ones are slow, time sensitive, easy to automate, or frequent"<p>Once you have that, you can now prioritize work that will make those tasks more efficient. If you just thought about tasks in a vacuum, you wouldn't have any empirical data that tells you what is worth doing. By doing things that don't scale - by doing things completely manually - you've also figured out a roadmap for the next few days/weeks.
Andrej Karpathy manually classifying ImageNet. <a href="https://karpathy.github.io/2014/09/02/what-i-learned-from-competing-against-a-convnet-on-imagenet/" rel="nofollow noreferrer">https://karpathy.github.io/2014/09/02/what-i-learned-from-co...</a><p>Manually doing the task yourself is a tremendously helpful exercise anytime you are doing machine learning, and often overlooked. It is hard work, especially since to do it right you'll often have to build custom labeling tools before you can even start. But you will discover all sorts of issues and come up with much better ideas for improving the system.
Build on modular frameworks to localize accountability, automate edge-case testing to save time later, and automate deployment as needed.<p>Poor design planning casts a long shadow, it is a relatively interesting career cleaning up defunct projects in addition to training staff you don't fire for being malicious and or stupid. Sometimes one can't fire problems or fix a poorly thought out design within the resource budgets... at that point one walks away if they are smart.<p>Sometimes companies survive arsed IT, but many do not... For example, a 73% LLM written article wouldn't necessarily get you fired, but likely a 73% pay cut due to sub-optimal market utilization.<p>Remember to have fun, =)
I'm working on my first startup building a technical product (no customers yet - still developing). No idea if I'm doing this right, so let me know what you think.<p>I'm building a bunch of templates based on my own professional experience as well as from talking to experts and random business owners who could be potential pilot customers.<p>This helps me get both product validation and research gaps. Hopefully when I do start reaching out to my pilot customers things will be set up for them on day one. I have a few who are interested and if they decide not to use it I can at least go after others in the same sectors and set them up easily.
There was an online car sales startup years ago where they put up the web page and ordering stuff before getting any buying or delivery stuff in place. When they got their first order, the boss said "well, go buy the car!"
Counter examples might be useful. Many startups implode under the weight/pressure of doing the wrong things that don't scale.<p>It should lead to growth/revenue/whatever your north star is.
I wrote about how we did it at Intercom here: <a href="https://www.intercom.com/blog/how-intercom-got-our-first-customers/" rel="nofollow noreferrer">https://www.intercom.com/blog/how-intercom-got-our-first-cus...</a><p>In short it was a combination of individual customer outreach our CTO jumped on Skype (yes Skype) to help with installing, I did handholding through onboarding, I ran "webinars" to like 4 people, or less. Everything was just tiny tiny steps.
When I founded my bootstrapped startup, I would go as far as opening PR's within the customer's codebase to integrate our dev tool on their behalf.<p>But most common one is probably pricing. Start out with cheap (or free) pricing to capture early adopters, even if it's not economical long-term. If/when you gain traction and momentum, gradually increase prices until the unit economics make sense.
While building physical simulation workflows, the input for calculation steps was intentionally not autogenerated from some config file but retained a template that require users to check. This way, it is easier for scientists to have a good idea so that they know they are doing the "right" calculations.
In the early stages of product dev I tend to do direct customer interaction (user research, customer troubleshooting, frontline support), instead of farming it out to junior team members the way I do with more mature products. This gives me a deeper sense of what users think about our product.
ProtonDB started with a lunchtime reddit post and a public Google Sheets link I seeded with three of my own tests. Came back from work with a thousand rows in it. In a few weeks I built a frontend around it. The 30k row data migration was brutal but in hindsight was absolutely worth it. AMA.
I was in an online fashion market place company that wanted to test 60-minute delivery in the same city.<p>We bought a few bikes and had employees ride out to customers, just to check if there was an actual demand. Turned out there was not and the idea was dropped with a low investment.
If you read the other essays he also says you do things manually as the founder first to learn the specifics that matter but then you scale it (typically by hiring someone, or via code) when you have learned very well how it should scale.
I’m manually importing stock portfolio holdings for users in <a href="https://jch.app" rel="nofollow noreferrer">https://jch.app</a> so they can export from their brokerage without conforming to a specific format.
At my company we were B2B2C so a lot of features had to be built for the B2B side and also the B2C side.<p>B2B side asked for an analytics dashboard, we manually sent them Retool apps segmented with their data hardcoding ids in the query.
There's a pretty good book dedicated to this exact question: <a href="https://unscalablebook.com/" rel="nofollow noreferrer">https://unscalablebook.com/</a>
I manually signup users.
They leave their email on the website, I then go and create user in Auth0 and send them invitation.<p>Planning to change this flow now before going public.
At Monzo we stuffed cards into envelopes by hand, printed mailing labels on thermal printers using slapped-together Python scripts, and filled up mailboxes in the local area every night. We kept doing it pretty much like this until we were sending out several thousand cards per day.<p><a href="https://monzo.com/blog/2017/06/09/journey-of-a-card/" rel="nofollow noreferrer">https://monzo.com/blog/2017/06/09/journey-of-a-card/</a>
basically you can do manually everything that could be automated, and should be automated if high volume.<p>- Manually send user welcome email, trial expiration email, etc...<p>- Manually fix some errors although the process could be automated.<p>- Manually cleanup logs, db tables, etc...<p>- Manually check every service, db, website, etc... is up
I honestly feel like this advise was applicable 10 years ago when it was written. Especially int he age of AI, but it's really going to depend on the business you're in, if you're business is automated business intelligence, vs mail order bbq sauce or something.<p>Not to mention the greater number of tools opensource and paid available to automate most of the stuff that would take a dev a little longer to do.<p>But also from a technical standpoint, if it's a 1 or 2 time task, and it's quicker to do manually, don't bother automating it.
I debugged our ML container and wrote yamls for initial version of demo<p>Also met customers and talked to them one by one travelling across the country, each time having a detailed game plan for what we wanted to learn and what we wanted to get back from the customer
We used Google Sheets as our primary DB for a long time: <a href="https://www.levels.fyi/blog/scaling-to-millions-with-google-sheets.html" rel="nofollow noreferrer">https://www.levels.fyi/blog/scaling-to-millions-with-google-...</a><p>We still use it for some off cases but have Postgres now.
to me its marketing, sales, and support. things that i avoid learning and doing when thinking that "if i build the product the users will come".