My ~spicy~ startup takes

I wanted to share some of my ~spicy~ takes that apply best to developer and infra-centric, earlier-stage startups.

As always, there’s nuance to all advice, so apply with care.

Don’t do unlimited free tiers

If you’re running a cloud service, offer a free trial period with a time limit.

Limits based on the number of seats, usage, or scale can be gamed and will continue to drain resources indefinitely. It’s post-ZIRP and margins matter. Don’t set expectations for an indefinitely free tier at the outset; it is nearly impossible to walk that back without harm to your users or brand.

Better yet, offer a free version of your product that users can run locally. Win-win.

Design your product to be incrementally adoptable

For critical infrastructure where switching costs are high, forcing users to rip out their old system to take a bet on your new one is a hard sell. Find pieces of the old experience that are broken and relatively isolated that can be improved using your product. Alternatively, find parts of the overall architecture that can be easily swapped out with your product instead of asking users to redesign their entire system.

In summary: create a wedge, prove your value, and expand.

Don’t build SaaS when you can buy it

I’ve written about this before but avoid building any of the following in your product and buy as much of it as you feasibly can.

• User Authentication and Authorization

• Billing, Metering, and Payment Processing

• High Availability, Backup, and Recovery

• APIs / SDKs / CLIs

• Audit Logging, Analytics, and Reporting

• Subscription Management

• Customer Relationship Management

• Compliance and Legal

• Security

• Documentation and Support

Building this all yourself is a huge time and resource-suck especially if you include the cost of complexity and maintenance. You almost definitely have to hire an L4+ engineer and pay them upwards of $200k + stock options to build and maintain these services.

Building custom infra in-house can make sense

It can be immensely valuable to rebuild existing infrastructure like databases and storage systems if there is a step-function increase in performance and/or efficiency that you can pass on to users.

Yes, it is a significant upfront cost to build these pieces of infra, but they can pay back huge dividends if they allow you to advertise your product as faster, better, and cheaper.

Sample apps and code >> documentation

In an ideal world, you would have high-quality sample apps/code snippets and docs. The reality I’ve seen is that most startups over-index on documentation.

Our attention spans are minuscule and we scan pages to get the information we need before we peace out. If your product is extremely complex and requires a deep understanding of concepts to understand how to even use it (guilty)—well first, maybe consider simplifying that, and then, sure write away in your docs.

Startups can get further by sharing great sample apps and practical code snippets. Users can survive without lengthy docs and explanations for a pretty long time IMO.

Invest proportionally in day 0, 1, 2 experiences

Your product and engineering investments in day 0, 1, and 2 experiences should be proportional to where your users are in their adoption curve, weighted by how many users there are at each point and how much they’re spending.

To use an oversimplified example, if you have 100 users at a given point in time.

• 50 users just started onboarding on day 0. ARPU is $6. Value = $300

• 30 users hit day 1 operations. ARPU is $10. Value = $300

• 20 users hit day 2 operations. ARPU is $20. Value = $400

Based on the value generated, you should roughly spend 30% of your engineering resources on day 0 and day 1, and the remaining 40% on day 2 experiences.

Of course, becoming this data-driven is difficult, and sometimes solving the churn problem higher up in the funnel is more advantageous than improving the experience at a later stage. When you’re starting out, you have no day 1 or 2 users, so you’re entirely focused on day 0. It becomes such a strong habit though, it can be hard to change even when your user base expands. And at that point, it’s too late. I touched on this topic briefly in my last post on product-led growth too.

This is why I think this is a nice rule of thumb.

It’s fine if you don’t get pricing exactly right the first time

Pricing is a never-ending, imperfect exercise.

It’s mostly fine to go with a strong hypothesis that you test out and then let your users/market tell you if you’re wrong in either direction. It’s probably better to undercharge instead of overcharge in the beginning. As you add value to your user and enhance the product, the price can go up too. This is better than arbitrary price increases.

There are a lot of resources available on pricing but the gist is in the early days, don’t worry about getting it exactly right.