I apologize if this is more technical than what you’re here for, but it’s what I’ve been focused on lately, and I wanted to share.

Lammy is a simple LLM library for Ruby I wrote over the last few weeks. It doesn’t treat prompts as just strings. They represent the entire code that generates the strings sent to a LLM. The abstraction also makes it easy to attach these methods directly to models, avoiding the need for boilerplate service code.

The approach is inspired by Python’s ell. I haven't come across a Ruby port yet, so I decided to start experimenting on my own.

Why?

I wanted to create a simple library that would let me use LLMs in my Ruby projects without dealing with a lot of boilerplate code.

Using something like Langchain felt too complex for many of my needs. Another option would be to integrate a library directly with a framework like Ruby on Rails, leveraging its conventions. You could, for example, store prompts in the database or as views. But that seemed like overkill for what I needed, and it would add a dependency on the framework, making it harder to use in simple programs.

Personally, I don’t think prompt engineering needs to be that complicated, which is why the ell approach—treating prompts like simple functions—really resonated with me. I wanted to bring something similar to Ruby. I don’t see why LLMs can’t be treated like databases in Active Record, where all the complexity is abstracted away. You can query without needing to think much about the underlying SQL. With Lammy, the idea is similar: you just define your prompt in a method on a model and call it like any other method.

Installation

Bundler

Add this line to your application’s Gemfile:

gem "lammy"

And then execute:

$ bundle install

You can find a basic example of how to use Lammy in Rails in the lammy-rails-example repository.

Gem install

Or install with:

$ gem install lammy

and require with:

require "lammy"

Usage

Lammy currently supports OpenAI’s models and Anthropic’s Claude. You can use any model that supports the OpenAI API or Claude. Make sure to set the OPENAI_API_KEY environment variable for OpenAI models or the ANTHROPIC_API_KEY for Claude models.

Chat

Lammy allows you to interact with a chat model using the llm decorator. The llm decorator accepts a modelargument, where you specify the name of the model you’d like to use.

class User
  # To be able to make LLM calls, we first include `L` at the top of our class
  include L

  attr_reader :name

  def initialize(name:)
    @name = name
  end

  # Take a message as input and return a model-generated message as output
  llm(model: "gpt-4o")
  def welcome
    # User message goes here
    "Say hello to #{name.reverse} with a poem."
  end
end

user = User.new(name: "John Doe")
user.welcome

# => "Hello eoD nhoJ, let's make a cheer,\n
# With a whimsical poem to bring you near.\n
# Though your name's in reverse, it’s clear and bright,\n
# Let's dance in verse on this delightful night!"

System message

You can provide a system message to the model through the context method. This is an optional approach that allows you to give the model additional context. I chose not to use the system method because it’s a potentially risky Ruby method.

class User
  include L

  # (...)

  llm(model: "gpt-4o")
  def welcome
    # An optional system message
    context "You are an AI that only writes in lower case."
    # User message goes here
    "Say hello to #{name.reverse} with a poem."
  end
end

user = User.new(name: "John Doe")
user.welcome

# => "hello eod nhoj, let's make a cheer,\n
# with a whimsical poem to bring you near.\n
# though your name's in reverse, it’s clear and bright,\n
# let's dance in verse on this delightful night!"

Structured output for OpenAI’s models

You can request OpenAI’s models to return a structured JSON output by using the schema option in the decorator. This is an optional feature that allows you to define a structured output format for the model. To handle arrays of objects, use L.to_a, and for a single object, use L.to_h.

class User
  include L

  # (...)

  # Define a structured output schema for Lammy to handle JSON responses.
  # For a single object instead of an array, use `L.to_h`.
  llm(model: "gpt-4o-2024-08-06", schema: L.to_a(name: :string, city: :string))
  def friends
    "Hallucinate a list of friends for #{name}."
  end
end

user = User.new(name: "John Doe")
user.friends

# => [{"name"=>"Alice Summers", "city"=>"Austin"},
#   {"name"=>"Brian Thompson", "city"=>"Denver"},
#   {"name"=>"Charlie Herrera", "city"=>"Seattle"},
#   {"name"=>"Diana Flores", "city"=>"San Francisco"},
#   {"name"=>"Eli Grant", "city"=>"New York"},
#   {"name"=>"Fiona Collins", "city"=>"Chicago"},
#   {"name"=>"George Baker", "city"=>"Los Angeles"},
#   {"name"=>"Hannah Kim", "city"=>"Miami"},
#   {"name"=>"Isaac Chen", "city"=>"Boston"},
#   {"name"=>"Jessica Patel", "city"=>"Houston"}]

Prefilling assistant responses for Claude

Anthtopic decided to improve output consistency and implement JSON mode by allowing users to prefill the model’s response. Lammy enables this feature through its array syntax, along with the L.user and L.system helper methods.

class User
  include L

  # (...)

  llm(model: "claude-3-5-sonnet-20240620")
  def welcome
    # Provide a list of messages to the model for back-and-forth conversation
    [
      # User message goes here
      L.user("Say hello to #{name.reverse} with a poem."),
      # When using Claude, you have the ability to guide its responses by prefilling it
      L.assistant("Here's a little poem for you:")
    ]
  end
end

Although only Claude models prefill responses, the array syntax can be applied to both OpenAI and Claude models. For OpenAI’s models, this feature is used to continue the conversation from where the previous message left off, enabling multi-message conversations like the one in our upcoming example.

Streaming

You can use the stream method to stream responses from the LLM in real time, which can be much faster and help create a more engaging user experience. To receive chunks of the response as they come in, pass a lambda to the stream method.

class Bot
  include L

  llm(model: "gpt-4o")
  def talk(message)
    # Use the `stream` method to stream chunks of the response.
    # In this case, we're just printing the chunks.
    stream ->(content) { puts content }
    # Nothing fancy, simply transfer the message to the model
    message
  end
end

bot = Bot.new
bot.talk("Hello, how are you?")

# => "I'm here and ready to help. How can I assist you today?"

This is a simplified explanation of how you can use the stream method. For a complete example, refer to this file. This implementation allows to hold an actual conversation with the model, which is the most common use case for chatbots, and does it using Lammy’s array syntax.

Vision

You can use a vision model to generate a description of an image this way:

class Image
  include L

  attr_accessor :file

  llm(model: "gpt-4o")
  def describe
    L.user("Describe this image.", image: file)
  end
end

image = Image.new
image.file = File.read("./examples/assets/ruby.jpg")
image.describe

# => "The image is an illustration of a red gem, specifically a ruby.
# The gem is depicted with facets that reflect light, giving it a shiny
# and polished appearance. This image is often associated with
# the Ruby programming language logo."

The L.user helper method must be used to attach the image to the prompt.

Custom clients

For a more robust setup, you can configure the client directly and pass it to the decorator.

# Helicone is an open-source LLM observability platform for developers
# to monitor, debug, and optimize their apps
$helicone = OpenAI::Client.new(
  access_token: "access_token_goes_here",
  uri_base: "https://oai.hconeai.com/",
  request_timeout: 240,
  extra_headers: {
    "X-Proxy-TTL" => "43200",
    "X-Proxy-Refresh": "true",
    "Helicone-Auth": "Bearer HELICONE_API_KEY",
    "helicone-stream-force-format" => "true",
  }
)

class User
  include L

  # (...)

  # Pass the Helicone client to Lammy's decorator
  llm(model: "gpt-4o", client: $helicone)
  def description
    "Describe #{name} in a few sentences."
  end
end

Embeddings

You can use the embeddings endpoint to obtain a vector of numbers that represents an input. These vectors can be compared across different inputs to efficiently determine their similarity. Currently, Lammy supports only OpenAI’s embeddings endpoint.

class User
  include L

  # (...)

  # Text embeddings measure the relatedness of text strings. The response
  # will contain a list of floating point numbers, which you can extract,
  # save in a vector database, and use for many different use cases.
  v(model: "text-embedding-3-large", dimensions: 256)
  def embeddings
    %Q{
      Hi, I'm #{name}. I'm a software engineer with a passion for Ruby
      and open-source development.
    }
  end
end

user = User.new(name: "John Doe")
user.embeddings

# => [0.123, -0.456, 0.789, ...]
# This will be the embedding vector returned by the model

Now you’re able to store this vector in a vector database, such as pgvector, and use it to compare the similarity of different inputs. For example, you can use the cosine similarity to determine the similarity between two vectors. More work with embeddings is on the way, as this is just a basic implementation. I wanted to start small so I can build and expand later.

License

Lammy is open source and released under the MIT License.

As I’ve mentioned before, I’ve been working on an ebook, and now it’s finally finished! It’s about 107 pages long and focuses on how today’s builders are developing apps using LLMs and other AI models. The content is a blend of technology and business—it’s not highly technical, as it centers around case studies and products, but it also dives into some implementation details. I think people in the startup world will like it. I had previewed parts of it on my blog, but now it’s fully done and available online for everyone to read.

It includes case studies on AI products and companies like Sweep, Playground, Nibble, Czat.ai, ChatGPT (of course), Fin, Strut, Meta Smart Glasses, Rewind, Humane, Rabbit, Character, and more. If you read it and would like to be featured, feel free to reach out. I’m open to expanding the content.

About the book 

In most industries, I’d be considered middle-aged or even young by some standards, having just passed 30. However, in tech—I’m old. (Can’t imagine how people who remember the dot-com bubble must feel.) This means I experienced the earlier wave of AI firsthand, which eventually became known as machine learning. I witnessed attempts to create products similar to ChatGPT using technology that we now recognize as a dead end. Archaic.

But it also means I’m uniquely equipped for this new generative age. Many topics that are new to those who recently discovered the benefits and challenges of, say, chatbots are familiar to me. I learned them the hard way. In 2015, I tried to build a company around this technology. But it was too early, and we failed. Now, I read the same pitches I once made on the landing pages of others and think, what if.

Thankfully, every failure brings gifts too, known as experience. The goal of this book is to share that experience with you, my reader, and equip you with the skills to:

• Grasp the fundamentals of generative AI based on practical case studies with just the right amount of theory
• Incorporate gen AI methods into your product design efforts
• Create new applications, ventures, and startups using generative AI technologies such as OpenAI’s GPT-4, DALL-E, or open-source alternatives like Llama and Stable Diffusion
• Hone your ability to effectively prompt these models
• Navigate the complete journey of crafting products powered by generative AI, from budget allocation and design to selecting between in-house and third-party solutions, and then to building prototypes

The book discusses various industries that could be transformed by generative AI, providing case studies to explain these impacts. It also explores both real and hypothetical examples of products to show how this emerging technology is reshaping the way the tech industry approaches the design, prototyping, and implementation of apps, services, and experiences.

Who should read it

This book is intended for intermediate-level readers eager to apply generative AI models, particularly in the realm of new product development. When I refer to “product design,” I’m talking about more than just the user experience or user interface. I mean the comprehensive, high-level process of developing a product from start to finish. Keep in mind: design isn’t just what something looks and feels like—the design is how it works.

While this book is technical in nature, coding skills aren’t a prerequisite for grasping its content. It’s tailored for professionals—be they engineers, designers, project managers, executives, or founders—who have already brought products to market and are now seeking an introductory guide to integrating generative AI into their process.

Instead of focusing too much on technical challenges, this book maintains a high-level perspective. This approach allows non-engineers to understand how they can meaningfully contribute to their team’s AI initiatives without necessarily running code themselves. For those with technical expertise, the book offers insights into practical applications of their deep knowledge of AI model internals, especially when it comes to developing and launching new applications.

If you’re not familiar with the core terminology of modern artificial intelligence—concepts such as models, prompts, training, tokens, and hallucination, to name a few—this book will provide some foundational understanding. However, we won’t dwell on these terms excessively. If you find you need a deeper dive into such topics, it would be beneficial to consult additional resources before returning to this book.

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

Hi, I’m Kamil Nicieja, and today I’ll be discussing the various types of Ruby on Rails architectures.

But first, let me share a bit about myself. I’m currently the lead software engineer at Plane, a Y Combinator startup. In the past, I’ve co-founded a few startups myself and authored books on testing and product management. I recently moved to San Francisco, just two months ago, so I wanted to say hello and ask—what’s the preferred flavor of Rails around here?

Let's start with vanilla Rails, the starting point for most developers.

This part will be pretty straightforward, but it’s important to set a baseline. We have a model, some concerns, callbacks—the usual components that everyone is familiar with because it’s the Rails way, taught to most of us when we’re just starting out.

In vanilla Rails, the models are often “rich,” meaning they contain a lot of code. To manage this, much of the code is typically extracted into concerns. For example, you can see a straightforward part of a model moved into a role concern.

Here’s a more complex example. Since we’re at GitHub HQ, I thought this would be a fitting choice. In this example, we have a Repository model with a Pull concern that allows you to fetch git repositories from the API, along with the commits. This shows that it’s not just simple tasks that can be handled with this approach—pretty much anything can be managed this way.

Now, with this approach, we might encounter a problem: what if we have some code that interacts with multiple models but doesn’t naturally fit into any of them? 37signals addresses this by placing such transaction scripts into separate domain concepts and treating them as models as well. This way, it becomes another noun in the ubiquitous language of the domain.

The biggest benefit of this approach is that it’s fully supported out of the box and is part of Rails’ well-known magic: it just works.

Let’s move on to the second approach. I briefly mentioned it earlier when I talked about transaction scripts. This approach builds on that concept, and I like to call it service-oriented Rails.

When working with vanilla Rails, some developers find that the standard approach tends to overload the models with too much code. To address this, they look for clearer, more refined abstractions, leading them to start experimenting with different approaches.

They likely end up with something like this: services, form objects, view components, and representers for handling views and APIs.

This is actually the approach we’re currently using at Plane, and we’ve even developed our own custom library to support our specific needs. I’m going to give you a quick look at it. Unfortunately, it’s not open source, but if you’re interested in this kind of approach, there are similar options available, like the Trailblazer framework or the dry-rb stack.

Let’s start from the basics. We define a simple service object, which we refer to as an “operation."

At Plane, we typically wrap all our operations in transactions and manage side effects using after_commit blocks. In this example, I’ve explicitly made the operation transactional to demonstrate how it works. If I wanted to create a non-transactional operation, such as one that interacts with an external API, I would simply set transactional to false.

All operations can be called asynchronously by simply adding the async prefix to the chain. This feature is quite useful, as it helps you avoid the boilerplate code associated with background jobs that only exist to call other service objects.

Another great feature is the built-in support for typed parameters. As you can see here, we use a Params struct to explicitly define all the arguments that the operation can take, along with their types and even default values.

Similarly, responses can be typed as well.

Now, let’s talk about recording operations. This feature is particularly useful for debugging or meeting compliance requirements. Parameters and results are stored in a database table, allowing you to easily track and review the operations that have been executed.

Another handy feature of our library is the ability to ensure an operation is performed only once by using a nonce key. In this example, the operation is executed just once, and any subsequent attempts with the same key will simply retrieve the previously recorded response.

We also support remote operations that can communicate across multiple microservices. In the example, you can see that by adding a remote method at the top, the operation acts as a server, making it available as an RPC over RabbitMQ.

Here’s the client-side call, which we can make from another Rails app. By adding the remote prefix to the chain when initializing the operation, the library handles all the communication between services. You can simply enjoy the result without worrying about the underlying complexity.

That wraps it up. While none of this is groundbreaking, it’s still a powerful, simple, and flexible architecture that extends the vanilla Rails approach without being disruptive. The main downside we’ve encountered is that by making operations so convenient, engineers may start relying on them for almost everything. In vanilla Rails, we had the issue of overloaded models, and here, we risk ending up with anemic models that only store basic data and overloaded operations. So, it’s important to stay mindful of design and use this approach thoughtfully.

Time for the third approach, domain-driven Rails.

Alright, so we’ve covered two patterns so far, but we haven’t ventured too far from classic Rails architectures yet. One of the main challenges with Rails is that, over time, it tends to encourage tight coupling. If you’re not careful, everything starts talking to everything else, and making changes becomes difficult because you end up needing to refactor half the system.

That figure is from a book called “Architecture Modernization” by Nick Tune, where I served as the technical editor. Unfortunately, Rails tends to land at the top of the diagram, characterized by strong and sometimes intrusive coupling.

Here’s the book if you're interested. It’s a great read, though I might be a bit biased!

So now, let’s take this problem and its solution to the extreme by decoupling as much as possible. In the upcoming code samples, I’ll be using a gem called rails-event-store to demonstrate how this works.

We’ll begin by introducing the command pattern into our codebase. Here, we use a command bus to execute a command.

The goal here is to decouple the action from the actor. Now, multiple handlers from different subsystems can respond to our commands, and we don’t need to worry about their responses. Our job is done once we’ve communicated what we need.

Next, we add a command handler. This handler is responsible for building what's known as an aggregate root.

As you can see, an aggregate root is a pure Ruby class that represents our domain model. The key distinction here is that it’s not an Active Record model. Another important aspect is that the state of the model is derived from events. When our command triggers the add_item method, this method fires an event, and the model’s state is constructed from a sequence of events. This is all part of the decoupling process. For example, we could have a non-Ruby system sending these events, and it would still be compatible with our domain and the code.

Now, you might wonder how we use this in our application layer since it’s completely separated from the domain layer. The answer lies in building a bridge called a read model. A read model is an Active Record model that we create in response to an event. Once created, we can use it just like any other vanilla Rails model. The advantage of this approach is that the read model can be optimized specifically for whatever we need in the view. For example, in this simple case, I’m setting the status to “Submitted,” which could be directly displayed in the view.

Alright, let’s weigh the pros and cons. On the plus side, this approach aligns well with event-driven programming, making it a good fit for microservices-based architectures. It’s also quite reusable—you could, for example, develop a decoupled billing domain once and reuse it across multiple apps. Additionally, because of the loose coupling, it’s more resistant to changes.

However, the downside is the complexity we’ve just introduced. I mean, did you see that code? Something as straightforward as adding an item to a basket suddenly feels as challenging as a journey to Mordor. The reality is that CRUD architectures are almost always good enough for most applications.

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

I have written about prompting multiple times now.

For example, in Smart Reactivity, we talked about a prompt that guides the AI to evaluate changes from the target audience’s perspective to write a sumary. This method forces the model to assess the significance of these features based on customer perception. Then, we instruct it to prioritize the list according to what matters most to the customer. This strategy allows apps to become more responsive with minimal user input.

Smart Reactivity

With the rise of AI, apps are set to become more reactive without much user input.

Kamil Nicieja · Before GrowthKamil Nicieja

However, if we revisit these posts now, we’ll see that the inputs and outputs we discussed were relatively brief. Even if the prompts were complex, they consisted of a few paragraphs, and the model’s responses were similar. But what if we wanted the AI to write an entire book, for example? When I typed this prompt into ChatGPT, I got just nine paragraphs of something the model considers a “book,” which they obviously are not.

So the question is, is there any way to guide the model into writing a book, even though it can’t do it on its own?

It turns out the answer is yes. If you, as a prompt engineer, know how to write a book, you can hand-hold the model step by step. First, you ask it to generate a few topics and choose the best one. Next, you have it write an elevator pitch for the book to determine the approach to the topic. Then, you instruct it to create an outline based on this pitch. For each chapter from the outline, you have it develop a plan. Finally, for each bullet point, it writes a few paragraphs. The model might not be able to hold everything it wrote in memory, so to reduce the length of the prompt, each time you prompt it to write a new chapter, you provide the outlines and a summary of what it previously wrote. And yes, it writes the summaries on its own, too.

As a result, at every step, it will generate a few paragraphs, then use these paragraphs to generate more paragraphs, and so on. The outcome might not be easy to digest, since LLMs are not highly creative, but you just guided the model through an extremely complex process.

The technique we just used is called chaining. It involves generating a desired output by following a series of prompts. In this process, a sequence of prompts is provided to a model, guiding it to produce the desired response. Each prompt addresses a subtask defined by the prompt engineer, and they are executed in sequence, each one feeding into the next, continuing down the chain of tasks until we arrive at the final result.

Time for a practical example.

No Work Is Ever Wasted

What if you’ve launched your app, poured your heart into it, and still crashed and burned?

Kamil Nicieja · Before GrowthKamil Nicieja

In No Work Is Ever Wasted, we discussed chain-of-density, a prompt that the Salesforce AI team rolled out as a fresh approach for LLM-based text summarization. We’ll take the result that prompt generated from one of my articles and build upon it by chaining it with a couple of other prompts.

Your article talks about “productive fictions” like 17th–century philosopher Blaise Pascal’s Wager and societal values like meritocracy, illustrating moral stances, human traits, and the impact of market demand. It underscores the pragmatic optimism and societal equilibrium emanating from these unverified but beneficial beliefs, which serve as practical guides, balancing life and societal constructs.

Productive Fictions

Why not categorize your beliefs into those that are productive and those that are not?

Kamil Nicieja · Before GrowthKamil Nicieja

We'll take the result of the summarization prompt from the previous section and build upon it by chaining it with a couple of other prompts.

Model input:
Take the last summary you wrote and prepare a list of ideas for different social media sites based on it. Each idea should be tailored to the type of content that works best on each platform.

Model output:
Based on the summary of the blog post, here are tailored ideas for different social media platforms:

Twitter: Create a thread explaining "productive fictions" with examples like Pascal's Wager and meritocracy, and how these unverified beliefs positively impact societal values and behaviors. Include engaging questions to encourage discussions.

Instagram: Post a carousel of visually appealing graphics that illustrate the concepts of Pascal's Wager, meritocracy, and their benefits. Use concise text overlays and captions to explain how these ideas contribute to societal balance and pragmatic optimism.

TikTok: Make a short video explaining the concept of "productive fictions" using simple terms and relatable examples. Use visual aids, animations, and on-screen text to make the content engaging. End with a question prompting viewers to share their own examples of beneficial beliefs.

(More ideas follow…)

You may have noticed that depending on the platform, the AI suggested different content forms. On Twitter, it’s text; on Instagram, it’s images; on TikTok, it’s videos. This is another reason why chaining can be extremely useful. In this example, we can take the ideas generated by the LLM and feed them to a visual model or an audio model.

For now, let's focus on just one modality. We’ll feed the model with its own instructions to write a Twitter thread based on the summary it wrote.

Model input:
Create a thread explaining "productive fictions" with examples like Pascal's Wager and meritocracy, and how these unverified beliefs positively impact societal values and behaviors. Include engaging questions to encourage discussions.

Model output:
1/10 🌟 Ever heard of "productive fictions"? These are beliefs that, while unverified, bring positive impacts to our lives and society. Let's dive into some examples and see how they work!

2/10 📜 One classic example is Blaise Pascal's Wager. Pascal argued that it's rational to believe in God, even without proof, because the potential benefits (eternal happiness) outweigh the potential costs.

(More tweets follow…)

Great! We could use this simple chain, for example, in an app meant for content creators to help them automate processes related to self-promotion. As the app designer, you set up the process step by step by writing the prompts in a chainable way, teaching the model to act almost like you would instruct a human. The AI then takes care of the results.

You might have noticed I haven’t been writing as much this year compared to last year. This is because I’ve been busy with a few side projects that I’m not ready to announce yet. (Soon!)

I always wanted Before Growth to be a place for builders and practitioners, not just filled with theoretical articles. So, I guess it was expected that occasional breaks would be necessary. Otherwise, I’d be working full-time on the newsletter, which would keep me from actively engaging in the field.

This wasn't clear to me from the beginning. I experimented with different models, including paid subscriptions. I turned them off some time ago when I realized they no longer made sense. So now, all content on here is free! If you haven’t read the previously paid articles, feel free to do so now. If you were one of the paid subscribers, thank you for your support. I hope to continue earning it by writing quality content.

On a related note, I do believe side projects are extremely important for every creative person. This blog itself started as a side project. Before that, I worked on Changepack, my open-source Rails app that uses AI to write changelogs for teams. That project led me to write more about LLMs, which inspired me to start a newsletter. This eventually led to organizing my essays into an online ebook. None of this was planned; it all happened serendipitously.

But I’ve noticed that this is what tends to happen when you’re active and open to opportunities. Many of my friends, some of whom read this newsletter—you know who you are!—complain that they’d start some side project that would be fun if they only had a good enough idea. But I think that kind of misses the point. All ideas are good enough. None of them are good enough. You’ll only know once you start and work on them.

And sometimes, course corrections are needed, like this one! This isn’t something to be too hard on yourself about. Personally, I think it’s more productive to go with the flow and see what sticks. In my experience, what sticks is usually what’s fun to do. Yes, some grind, perseverance, and determination are required, and the more serious you get, the more of it is needed. But it’s difficult to force yourself to do something that doesn’t seem fun over a long period.

And if you develop some marketable skills along the way? That’s fantastic. But if not, that’s okay too. One of the key benefits of side projects is the idea of recovery. Setting time aside to work on passion projects isn't just good for your mind; it can also make you more productive and bring you greater life satisfaction.

So, I’ll get back to you soon with three small projects I’ve been working on. One is a summary of last year’s period on Before Growth. Another is a personal look forward into the future. The third one is almost completely unrelated to anything I’ve written here so far, but it’s probably been the most fun to work on.

Let’s see how it goes.

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

I’ve noticed that smart people don’t like repeating themselves. Polite ones might repeat things a couple of times, but if you meet someone who’s more direct and wants you to keep up, they’ll get increasingly annoyed if you don’t.

I think the reason is simple. Smart people usually absorb new information quickly and have good memories. They are proactive in finding new data points, which has contributed to their success. They naturally expect others to do the same. That’s their first instinct is to think, “If I know this, why don’t they?” and they’ve often had to learn to suppress it to avoid coming across as jerks.

But when they start leading people and organizations, they run into a wall. As a manager, there’s no other way: you must keep reinforcing the same message ad nauseam until everyone is on the same page.

It’s not because people are stupid. Think of a new hire. If they were stupid, you wouldn’t offer them a position. There’s simply a temporary information asymmetry between them and the rest of the team. As communication gets more complex with more people involved in a project, this gap grows in unexpected ways, even among long-term employees.

If any of this sounds familiar, here’s how you can make your job easier.

Whenever you find yourself repeating something to a second audience or in a different situation, it’s likely you’ll need to say it again and again in the future. To reduce the time you spend repeating information, write it down. Then, the next time you need to share that message, you can simply provide it in written form.

If it’s something all team members should know and remember, add it to a company-wide wiki for good measure. This is a great habit to develop for yourself and the entire organization, generating lots of useful information over time.

If you adopt it and do it consistently, your team will see the benefits and be encouraged to do the same. People usually don’t like producing documentation and see it as a chore. However, if you explain that it will save them a lot of time in the long run, they’ll eventually recognize the benefit. Even better, show it.

This advice comes from The Great CEO Within by Matt Mochary, who coaches many of the fastest-growing technology companies’ CEOs in Silicon Valley. In his book, he shares highly effective leadership and business-operating tools with CEOs and managers everywhere. I highly recommend it.

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

A year and a half later, after the hype subsided just a bit, I think of large language models as on-demand intelligence accessible through APIs. Whenever my software needs to use fuzzy logic or analyze unstructured data, I can just send an HTTP request and get the insights I need.

Let’s consider a real-world scenario. Imagine an applicant tracking system that filters candidates using specific keywords. Each resume must be reviewed by a recruiter to see if it matches their criteria. For example, they might be searching for a candidate with seven years of experience in a particular technology.

The top companies often get hundreds—if not thousands—of applications, resulting in a lot of repetitive manual work. Moreover, recruiters are usually not experts in technology. To compensate, they come up with their own heuristics, which might lead false positives or false negatives.

With large language models, rather than depending on these filters, we can tap into AI’s intelligence by making an API call. (Shoutout to Patrick McKenzie on Twitter for the inspiration behind this prompt.)

Suppose you’re looking for someone with at least seven years of Python experience. A developer’s resume indicates they’ve been using Django since version 1.8. Explain why you’d decide to include or exclude this candidate.

…and get a response:

Include them. Django 1.8’s release in 2015 implies over 7 years of Python experience.

I wasn’t sure myself since I’m a Ruby developer. But after looking into it, I confirmed this is the right decision. Great!

Building an applicant tracking system like that without AI would require engineers to either integrate a complex expert system directly into their product, or allow recruiters to set up a rigid job application workflow on their own. But LLMs can easily read the job listing and the resume by using their extensive knowledge—on demand.

So here’s the best way to understand how these models are useful today, despite not yet being smarter than humans: if you assign them specific, concrete tasks, they can help you achieve good results efficiently. Turns out, my perspective on AI systems hasn’t changed much over the past decade: they can deliver what a thousand interns would, but much faster and at a lower cost.

The major difference this time is that the tech stack has become much simpler to use due to commoditization. What used to be accessible only to Big Tech only has now become available to everyone.

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

A friend of mine, who isn't into programming, recently asked me if I could suggest any articles or books that could help them understand a technical concept better.

I suggested a book—and also recommended using ChatGPT as a tutor, which I’ve been doing more often myself.

The app is essentially a talking encyclopedia. (A Borgesian nightmare.) It easily breaks down barriers previously caused by a lack of skill, talent, or knowledge.

Not sure how to do something? Pair up with ChatGPT, Claude, or Gemini. Tell it about your current skill level and ask for guidance. It will adapt to your needs, allow you to ask follow-up questions, and even provide practical examples when possible.

I don’t often use it this way for tasks within my expertise, but it’s great for everything else. Just this week, I teamed up with it to brush up on some basic legal concepts related to my business. I later verified the information with a lawyer friend, but thanks to that previous chat, I already had a good understanding of the topic, which saved my friend some time getting me up to speed.

It's a simple concept, true, but we’re still early. Most people don’t use any large language models daily yet. And these apps are… broad, to put it mildly. The interface is essentially just a text box, leaving it up to you to figure out how to make it useful for your needs or to learn from how others are using it.

It’s also a sign of how education will evolve in the coming years. Everyone will have access to a personal tutor knowledgeable in any subject, available 24/7 right from their pocket.

I personally see large language models as “floor raisers.” They elevate everyone’s basic abilities almost immediately when used—as opposed to “ceiling raisers,” which would push you into the top 1% of a skill, something no LLM can currently achieve.

Using these tools, everyone becomes just a bit more skilled—which is amazing.

🙏 My work is reader–supported. You can get a membership here!

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

📚 My new ebook Generative AI in Product Design offers case studies on AI and just enough theory for you to build your next app with gen AI. Get your copy here!

🙏 My work is reader–supported. You can get a membership here!

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

📚 My new ebook Generative AI in Product Design offers case studies on AI and just enough theory for you to build your next app with gen AI. Get your copy here!

As AI startups grow, there’s a trend of sharing memes on Twitter about massive bills from OpenAI. Some companies are posting about receiving bills of $8,000 or even $25,000, which can amount to about 10% of a startup’s monthly recurring revenue.

In the past decade, we’ve seen similar situations with cloud service bills. Back then, teams didn’t worry too much because if their services gained popularity, they had access to almost unlimited venture capital. However, in today’s climate, with the end of the zero interest rate policy era, companies need to be much more mindful of costs right from the start.

So, the big question is, how can we reduce costs? Naturally, the main solutions include developing more efficient models and improving hardware. However, we can also apply software engineering or prompt engineering techniques to cut expenses. This article explores the following strategies:

• Trimming prompts and responses to minimize token usage
• Implementing caching, including both exact matches and semantic caching for approximate matches
• Optimizing models through fine-tuning and deploying smaller models trough the AI router design pattern

This post leans more towards the technical side. I’m deeply interested in practical implementation techniques. I want to ensure Before Growth doesn’t turn into a purely theoretical business blog disconnected from real-world practices.

Let’s dive in.

Condensing prompts and responses

We’ll begin with the basics. Since the primary cost from LLM cloud providers comes from the tokens used, reducing the number of tokens in each request can lower expenses. Because we can’t always manage user input, it makes sense to look for efficiencies in the system’s prompts and ChatGPT's responses.

• System prompts can be manually shortened or we can use a tool like ChatGPT to do it for us. As I explained in Corrections, the LLM itself often has the ability to rephrase its own prompts in a way that makes them more compliant, and this technique is effective in reducing their length as well.
• We can also use summaries. For example, we can summarize a document once, incurring the full cost, and then use the summary for further processing. This approach reduces the number of tokens used while preserving the most important information.
• For the model’s responses, we can request it to be less verbose or to follow instructions such as replying in just a single sentence.

Corrections

Uncovering the quirks and capabilities of ChatGPT using Ruby on Rails.

Kamil Nicieja · Before GrowthKamil Nicieja

While these strategies might seem simple, they’re not trivial. If you look into the leaked system prompt for ChatGPT, you’ll discover that its developers have explicitly instructed it to conserve computing resources. This includes directives to avoid verbosity, such as the guideline to “never write a summary with more than 80 words” in the prompt. If OpenAI sees savings opportunities in commands like this, you can benefit from them as well.

If you’re really looking for something more advanced, there’s LLMLingua by Microsoft. This tool uses a compact, thoroughly trained language model like GPT2-small or LLaMA-7B to pinpoint and eliminate unnecessary tokens in prompts. This allows for efficient processing, achieving up to 20 times compression while keeping performance loss to a minimum.

To me, investing in such frameworks really pays off when you’re handling highly complex prompts or when doing stuff like retrieval-augmented generation. However, as the tech evolves, we’re seeing new features, like Google Gemini’s 1 million token context window, enabling users to literally put entire books into these models. If history from the past decade has shown us anything, it’s that people will continue to push the boundaries in unexpected ways with these technologies. So, approaches like these could become increasingly valuable as well.

Exact caching

Caching is a technique familiar to programmers across many fields, not just those working with AI. If you’re using a framework like LangChain, which is optimized for developing applications powered by language models, you might find caching features already built in. This means you can easily incorporate it into your app without much hassle.

Here’s an example.

from langchain.globals import set_llm_cache
from langchain_openai import OpenAI

# To make the caching really obvious, lets use a slower model
llm = OpenAI(model_name="gpt-3.5-turbo-instruct", n=2, best_of=2)

%%time
from langchain.cache import InMemoryCache

set_llm_cache(InMemoryCache())

# The first time, the input is not yet in cache, so request should take longer
llm.predict("What's GitHub?")

CPU times: user 13.7 ms, sys: 6.54 ms, total: 20.2 ms
Wall time: 330 ms

%%time
# The second time it is, so we go faster
llm.predict("What's GitHub?")

CPU times: user 436 µs, sys: 921 µs, total: 1.36 ms
Wall time: 1.36 ms

When the framework accesses the cache for the second time, it skips connecting to your provider’s API and fetches the same answer from the data store. This not only reduces costs but also offers a speed benefit of almost 15 times.

However, there are downsides, such as increased complexity but I won't go into more detail on that—every engineer knows how caching can generate problems. And to be fair, you don’t necessarily need LangChain to set up exact caching. It’s easy to implement in any programming language or framework. For example, the effort would be similar even in Ruby on Rails, which is my usual coding environment.

But there are some unique downsides to caching with LLMs that many might find new. One major issue is that the response from the model will remain unchanged until the cache expires. This might work well for certain AI products, but it’s less than ideal for others—particularly those focused on content generation. For example, if you ask an LLM to write a blog post and it produces the same one every time, it clearly is not very good at its job. However, in the case of a customer support chatbot, this might not be a concern at all.

Semantic caching

The second issue becomes visible soon after implementing exact caching. One user might say “Tell me a joke,” while another asks “Do you know any jokes?” Because these sentences don’t match exactly, the cache will be bypassed.

This is where semantic caching and tools like GPTCache become valuable. GPTCache uses embedding algorithms to transform queries into embeddings, employing a vector store for similarity searches on these embeddings. Through this method, GPTCache can recognize and fetch similar or related queries from the cache, enhancing efficiency.

We can integrate GPTCache with LangChain to enhance our previous example.

import hashlib

from gptcache import Cache
from gptcache.adapter.api import init_similar_cache
from langchain.cache import GPTCache

def get_hashed_name(name):
    return hashlib.sha256(name.encode()).hexdigest()

def init_gptcache(cache_obj: Cache, llm: str):
    hashed_llm = get_hashed_name(llm)
    init_similar_cache(cache_obj=cache_obj, data_dir=f"similar_cache_{hashed_llm}")

set_llm_cache(GPTCache(init_gptcache))

%%time
# This is an exact match, so it finds it in the cache
llm("What's GitHub?")

"GitHub is a developer platform that allows developers to create, store, manage and share their code."

%%time
# This is not an exact match, but semantically within distance so it hits!
llm("Explain what GitHub is.")

"GitHub is a developer platform that allows developers to create, store, manage and share their code."

This time, even though our second query wasn’t identical to the first, we still managed to hit the cache successfully.

This solution has its drawbacks, too. With a semantic cache, you might face false positives during cache hits and false negatives during cache misses. So, not only have we added a caching system that increases complexity, but we’ve also introduced a particularly complex type of cache. Hopefully, when we weigh these challenges against potential savings, they will justify the effort involved.

Fine-tuning and model-swapping

If you prefer not to use caching, there’s another strategy to consider. We’re in the middle of the AI boom; with the tech improving quickly, everyone wants to use the latest, state-of-the-art models. However, it can sometimes be more practical to opt for a less advanced LLM and tailor it to your specific needs through fine-tuning.

Fine-tuning is a method where a pre-trained model undergoes additional training on a smaller, specialized dataset. This process adjusts the model’s parameters to improve its performance on tasks related to this new data. It’s like an experienced chef refining a new recipe by tweaking their methods. This approach enables the model to become more specialized, boosting its effectiveness on specific tasks without having to be developed from the ground up.

For example, if we assign a task to GPT-4, it might perform well 80% of the time, while GPT-3.5 might only succeed in 60% of cases for the same task. However, by fine-tuning GPT-3.5 with sufficient specific examples demonstrating how to complete that task, it can eventually match the performance of its newer counterpart.

Research shows that fewer than 1000 data points can be enough for effective fine-tuning. Just 100 data points led to a 96% improvement in GPT-3.5’s ability to answer questions in JSON format, and 1000 data points were enough to surpass GPT-4 in generating raw responses. While GPT-4’s pricing is $0.03 per 1000 tokens for inputs and $0.06 per 1000 tokens for outputs, GPT-3.5’s costs are much lower, at only $0.0005 per 1000 tokens for inputs and $0.0015 per 1000 tokens for outputs. This represents a 60x cost improvement!

If you're interested, here’s a 4-step playbook you can follow.

Step 1. Begin with the most advanced model required for your application’s needs. For 95% of companies, this would be GPT-4, but probably not Turbo, as you’re aiming for the highest quality outputs. These will serve as the basis for fine-tuning a smaller model.

Step 2. Keep a record of your requests and responses in a format that allows for easy export.

• The facts are always friendly, every bit of evidence one can acquire, in any area, leads one that much closer to what is true.
• Why does Sam Altman need $7 trillion?
• Should a semiconductor company be worth more than the energy sector?
• We discuss Sora, a new text-to-video AI model from OpenAI.

🙏 My work is reader–supported. You can get a membership here!

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

📚 My new ebook Generative AI in Product Design offers case studies on AI and just enough theory for you to build your next app with gen AI. Get your copy here!

Funding… funding finds a way

Carta’s new research points out that overall investment has dipped in nearly every stage of venture funding when you look at 2023 compared to 2021. Yet, when you dive deeper into the numbers, something interesting pops up. Money flowing into pre-seed companies—which means those raising under $1 million through SAFEs or convertible notes—has actually jumped over 50% from 2021.

However, it’s worse for companies in the mid-to-late stages where the downturn continues with little improvement. To get back on track and push through the financial gloom in 2024, there’s a real need for a boost in late-stage venture investments.

Why does Sam Altman need $7 trillion?

Scott Alexander recently shared some intriguing thoughts on the scaling up of GPTs, explaining why Sam Altman of OpenAI is looking for ways to dramatically increase the world’s computing capacity. According to Alexander, GPT-6 might need about 10% of the world’s computers, enough energy to rival a large power plant, and more training data than we currently have access to. This could mean setting up a data center as big as a small town, powered by an extensive setup of solar panels or maybe a nuclear reactor. Alexander also mentioned that, as things stand, creating GPT-8 seems impossible. Even if we make leaps in synthetic data, harness fusion power, and take over the entire semiconductor industry, it still wouldn’t be enough to make it a reality—not without a breakthrough.

This insight also seems to suggest that OpenAI’s current strategy revolves “just” around linear scaling. There are no hidden projects in the pipeline. The focus remains on developing larger models and making incremental improvements—until we devise a more efficient architecture. And there’s definitely room for improvement; after all, human brains achieve similar or better results without needing as much data or training.

Should a semiconductor company be worth more than the energy sector?

Still on the subject of chips, Nvidia’s share price is hovering around $700 as of this writing, making it more valuable than the entire S&P 500 Energy Sector with a market cap close to $1.8 trillion. I recently chose to invest in it, along with a few other companies, and then found out that a good portion of financial Twitter seems to think the stock is in a bubble. Lucky me. As always. But is it really? (Knowing my luck, probably yes.)

To be honest, I’ve got no idea. I’m not a professional investor, so take my words on stocks with a grain of salt and do your own research. I’m just sharing my observations from the last couple of months. Some folks are drawing parallels between Nvidia’s rapid growth and Cisco’s during the dot-com bubble, which isn’t a far-fetched comparison. Both companies provided the infrastructure for new trends like the internet or AI. Early in the growth curve of a trend, it makes sense to back infrastructure providers since the eventual winners aren’t yet clear, and in many cases, haven’t even emerged. But there’s always money to be made by selling shovels during a gold rush.

Other analysts argue that chart comparisons can be manipulated to prove anything, depending on your starting point. They note that Nvidia’s stock would need to triple in the next 433 days to reach the levels seen during the dot-com bubble. Some even set a price target of $1,200 for it. However, if Nvidia's price were $1,200 today, its valuation would surpass Apple’s… You can see why I’m feeling anxious, right?

No matter your thoughts on Nvidia, it’s clear the market is showing some bubble-like behavior right now. Supermicro, under the ticker $SMCI, just experienced a 20% drop in a single day from its peak, now trading at around $800 a share. To put that in perspective, it was trading at about $100 per share in early 2023, marking an 800% increase in just over a year. Yeah, reasonable, nothing to see here. What does Supermicro do? To be honest, I wasn’t familiar with the company until I started digging into this. They sell servers, apparently. And in 2024, is that really worth so much? Probably not—but in June 2023, there was a spike in demand for Supermicro’s AI systems optimized for large language models, thanks to NVIDIA chips. So, that “explains” the surge…

If that doesn’t scream bubble, then I’m not sure what does.

There are other telling economic signs too. Cash has become a more appealing option than stocks, which means there’s less reward for taking risks and more for just holding onto cash. This scenario last played out just before the dot-com crash. Currently, we’re witnessing an extraordinary wave of insider selling. Jeff Bezos just offloaded shares of Amazon valued at $6 billion, while Mark Zuckerberg sold $840 million worth of Meta shares, Netflix’s CEO sold $40 million, and Palantir insiders sold another $35 million. The last time we saw this level of selling activity was in 2022, right before the Nasdaq took a 30% hit. Meanwhile, Japan and the UK are facing recessions, Germany narrowly avoided one despite its economy shrinking by 0.3% in 2023, and the European Union's economy technically grew by 0.1% last year—but yeah, it’s not really that optimistic…

Though it’s a bit off-topic for this newsletter, I know a lot of us are into tech investments, so I thought I’d share how my thinking on the matter is shaping up.

Bits

• Sora is an AI model developed by OpenAI that’s capable of generating realistic video from text prompts. It’s pretty mind-blowing. Definitely give it a look if you haven’t yet, though I’d be surprised if you haven’t come across it already. It’s blowing up on Twitter. There’s not much more I can say right now since it’s still not widely available to the public.
• Zuckerberg believes that glasses will become the mobile devices of the future, while headsets are set to be the laptops of the future. Yeah, I can see that happening.
• OpenAI is currently testing a feature that allows ChatGPT to recall things from your chats, aiming to make future conversations more useful. This is actually something I suggested in my blog post about context windows. So, if anyone from OpenAI is reading this, I’m open to sharing more insights and ideas!
• A mob recently wrecked a driverless Waymo car in San Francisco. For more than ten years, I’ve toyed with a story idea about riots breaking out in the city, sparked by massive job losses among two key groups: drivers, due to autonomous vehicles, and retail employees, because of self-checkout grocery stores. This incident would serve as a gripping start to the tale. To make the story even more relevant today, I’d include the angle of office workers being laid off because of advancements like ChatGPT. But it’s all just a story… isn’t it?
• CrewAI is a framework designed to manage role-playing, autonomous AI agents. It encourages collaborative intelligence, enabling these agents to work together smoothly to handle complicated tasks.
• Air Canada has found itself in a position where it needs to stick to a refund policy that was unintentionally invented by its chatbot. It's a good reminder that ChatGPT started off as a research demo, largely because the technology it’s built on can still be a bit unreliable and not always prepared for widespread deployment.
• A review of Walter Isaacson’s “Elon Musk”. There’s a lot in there that didn’t vibe with me, but I do echo the sentiment that Isaacson seems to ignore the truly fascinating aspects of leaders like Musk or Steve Jobs, who also had a biography he wrote. For example, the part where Musk’s first son passes away is quickly covered and then it’s straight back to rocket science, human emotions be damned. That’s actually where I started to lose interest in the book. “Steve Jobs” felt similar in that respect. If you’re looking for a deeper dive when it comes to Apple’s founder, I’d point you towards Brent Schlender’s “Becoming Steve Jobs,” which is much better. It genuinely attempts to paint a full picture of who Jobs was, capturing both his flaws and his brilliance, instead of reading like a boring history book.

Today’s topic

Imagine two founders.

The first entrepreneur is new to this and hasn’t launched a startup before. They’ve managed to secure their first investment meeting, but the fact that they don’t even have a hundred users is making them feel insecure. In an attempt to make things look better, they tweak the numbers in their pitch deck, making it seem like all their users are actively engaging every month. Or they stretch the truth in a different slide—maybe not exactly a lie, but more like they leave out a tiny detail or phrase something in a way that’s a bit more positive than it really is. They’re hoping that by the time anyone double-checks these figures, the startup will have grown to match these numbers anyway. No harm done.

The second founder comes with experience, feeling confident from a successful exit in their past venture. Just like the first, they’re at the beginning stages, but their numbers are even less impressive, with only tem daily active users. A few days after the first founder, they present the raw numbers to the same venture capital firm.

Who do you think is more likely to get funded?

The second founder has the edge. At this early phase, investing in people is the smart move. So, if someone with a proven track record approaches you, it’s likely you’ll invest. They’ve succeeded before, suggesting they can do it again. However, given the abundance of capital in these funds, and considering that early-stage VCs and startup accelerators often discover relatively unknown talents and fund their ideas, the less experienced founder isn’t necessarily at a disadvantage.

However, following the next investment committee meeting, it turns out that the less experienced founder does, in fact, end up losing. Why?

VCs and other people in power tend to get really good at spotting when someone’s not being completely honest with them, especially if it’s to get something they want. If they take a closer look, they’ll realize the foundations aren’t that strong. Having a small group of users who are really into what you’re doing is way better than “having” lots of users who look like they hardly pay attention. The second founder can easily share stories about how their project made a real difference for each of their users, and even provide references. The first founder, on the other hand, might not have those kinds of stories to tell and could end up bending the truth too far by inventing them, too, crossing further into outright dishonesty. Like a death spiral.

Fame, money, and ambition can lead people to make some questionable choices. It’s not by chance that shows like “Silicon Valley” on HBO highlight manipulating investors, employees, and the press as a common issue in startup culture. I don’t think it’s a deep-rooted part of our culture, but we do see it pop up now and then, with cases like FTX grabbing headlines. When there’s a ton of money at stake, it’s easier to drift away from your original values. And just to be clear, I’m not saying that all first-time founders are out there juicing the numbers; it’s just a story that a friend shared with me, told anonymously.

Personally, I strongly believe that the truth always surfaces eventually. The situation with FTX and other similar cases proves that point. In our story, treating the truth as something to be avoided actually backfires, because the founder ends up not getting the investment anyway. As Dostoyevsky wrote, “Your worst sin is that you have destroyed and betrayed yourself for nothing.”

I get where the first founder is coming from. Even in situations at work that aren’t worth billions of dollars, if I feel like I messed up, there’s sometimes this little voice in my head whispering, “Maybe we can just... hide it?” Nobody wants to look bad or get the blame when things go bad. So if I keep quiet, maybe no one will notice. Maybe I can tweak the truth just a bit so it doesn’t look like my fault. I think everybody hears this voice from time to time. But it's never worth listening to it. Being open and simply dealing with the issue is always the better route. If you end up losing your job over being honest, the worst case scenario, then maybe that’s for the best. In my experience, working for someone who can’t handle the truth comes back to bite you eventually. They will use that against you sooner or later.

Carl Rogers, the famous psychotherapist, once said, “The facts are always friendly, every bit of evidence one can acquire, in any area, leads one that much closer to what is true.” He believed that facing reality is how people grow. Often, people might cherry-pick information that aligns with their preferred viewpoint. While this might feel comforting, it can lead to a denial of reality or attempts to twist it—as we’ve seen in our story. Rogers argued that we should embrace new information, even if it proves our previous beliefs wrong or makes us uncomfortable, because truth has a healing power that helps us move forward.

I agree. Don’t be afraid.

Scoring a 7 out of 10 in, well, pretty much anything is quite good, you know? Not super amazing, but definitely better than just okay. What a nice, comfortable spot to be in. Fuck 7s.

We’ll also explore nine exciting new startups to understand where some markets might be going in the next few years, thanks to the current boom in AI technology.

Quick hits

• Slingshot is working on the next wave of video games, where characters and gameplay are driven by generative AI. This concept sounds really cool! I expect that future waves of indie games will use mechanics like these, much like how they currently do with randomly generated maps.
• Smobi is a marketplace designed to simplify the process of purchasing businesses valued at $5 million or less by overseeing the entire transaction directly through their platform. If Opendoor can revolutionize real estate sales and OpenStore can manage Shopify shops, then why not provide a similar service for small and medium-sized businesses?
• Fragment integrates human supervision into automated processes, an approach known as human-in-the-loop. While the current wave of generative AI is getting smarter by the day, it’s getting clear that it isn’t capable of replacing most human jobs. However, what AI excels at is quickly and automatically evaluating large data sets. Fragment enables human agents to step in to handle fallback or review tasks when the AI encounters errors.
• Flint lets teachers leverage AI for personalized learning experiences by creating chatbots to tutor or assess students through one-on-one conversations. With Flint, teachers can establish rules for the AI, specify reading levels, and set grading criteria. The AI then adapts to each student’s level and provides assistance when they encounter difficulties. When UX research shows that Bing Chat's responses are calibrated at a 13th-grade reading level, similar to what a university freshman might encounter, while ChatGPT responds at an impressive 16th-grade reading level, there’s a clear need for a tool that kids can use.
• Casehopper is streamlining the immigration process using AI. It’s clear that the legal industry is ripe for some disruption due to LLMs, even though changing how lawyers operate will undoubtedly be challenging—as it always is. It’s reasonable to expect that certain legal workflows, such as visa processing, will become more efficient with the latest technology.
• Patents can be another similar example. Solve Intelligence uses AI to help attorney write patents.
• Corgea helps businesses fix vulnerable code, reducing engineering costs and time by 80%. Through AI-driven code fix generation, it streamlines the process, allowing engineers to approve fixes efficiently. Security is often not a top priority for startups until they grow bigger. But with AI helping out, that might change.
• And Contour does the same for QA and end-to-end UI tests. The main trend in the coming years might be using big models like this one for specific needs. People who know a lot about certain problems will tweak these models to work better in different industries and situations.
• Sideko uses OpenAPI to make SDKs for your API that really work. This is a great idea because making libraries can be a hassle for developers. If it’s automated, it’s a big win for engineering teams eveywhere.

🙏 My work is reader–supported. You can get a membership here!

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

📚 My new ebook Generative AI in Product Design offers case studies on AI and just enough theory for you to build your next app with gen AI. Get your copy here!

Today’s topic

Imagine this: Your HR department wants to run a pulse survey to gauge your team’s feedback on a regular basis. Now it’s your turn to contribute. They ask a question like, “How likely are you to recommend your company as a place to work to people you know?” Your experience at work has been generally positive—not great, not terrible—but there have been a few bumps along the way. Though maybe it’s just you…? In the end, you opt for a respectable 7 on the ten-point scale.

On another day, your manager asks you to rate them in a performance review. Despite having reservations about how they handle feedback when under pressure but, after all, who doesn’t get defensive when cornered? Wanting to avoid unnecessary drama, you settle on another solid 7.

It's a few days after the new year. As you try to pick up the habit of journaling with a shiny new app, it gives you a writing prompt that asks you to rate your day and explain your reasons. Deep down, you sense that things have been a bit off for a while now… but perhaps it’s just the winter blues? The cold and darkness could easily be to blame. Besides, you pride yourself on being a positive person with a strong sense of agency. You convince yourself that things haven’t been too bad after all. In the end, your rating lands on a 7 once again—there’s still hope for improvement, right?

Do you see where I’m going with this?

A seven often is as a non-answer, crafted to avoid causing offense to anyone—including yourself. This is perfectly normal. We humans are social creatures. We want to maintain harmony and avoid upsetting others without a reason. Even when there is cause for criticism, we may still go to great lengths to sidestep confrontation if we don’t deem it absolutely necessary. This approach is not a bad day-to-day strategy; it often fosters cohesion in groups.

However, there are times when prioritizing truth-seeking is more important than maintaining cohesion. In each of the three scenarios outlined earlier, it would better if individuals were compelled to choose the confrontational option. The workplace cannot progress if feedback on issues is withheld. A manager cannot address and improve their behavior if they remain unaware of its impact. And if you convince yourself you’re fine when you’re not, you may delay the acknowledgment of the need for change.

So next time you design a system meant to uncover issues, have people rate stuff on a scale from one to ten—but with no sevens.

Eliminating the “safe” option will prompt them to consider which extreme they lean toward—are things good or bad? This encourages everyone to recognize that it’s fine to feel dissatisfied and that raising concerns is expected. Hopefully, it also creates an environment where problems are addressed in a peaceful and productive manner when brought to light. However, that’s a separate matter altogether, and it’s important for you not to panic when people finally start telling you the truth.

• OpenAI suggests that AGI is close, but then they launch something like the GPT Store. You’d think if they were really close to making AGI, they’d do something bigger or more important with it, right?
• Staying on the topic, another new platform: Apple Vision Pro and its use cases.

🙏 My work is reader–supported. You can get a membership here!

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

📚 My new ebook Generative AI in Product Design offers case studies on AI and just enough theory for you to build your next app with gen AI. Get your copy here!

Do you use custom GPTs?

A few months back, OpenAI introduced the ability to customize ChatGPT with specific instructions, additional knowledge, and various skills. These custom GPTs can assist in learning board game rules, teaching math to children, or designing stickers. Following this, OpenAI launched the GPT Store, making it accessible to ChatGPT Plus, Team, and Enterprise users. This store offers a selection of popular and helpful GPTs.

I haven't talked much about the store yet, but I did have some thoughts on GPTs themselves at their launch:

• Creators were attracting even up to 8,000 users with some successful bots on ChatGPT’s platform. They benefited from SEO as OpenAI’s public catalog ranks high on Google, too.
• Some users felt the new features weren’t very useful, believing they can create similar prompts themselves. This mirrored early views on Dropbox, where tech-savvy users felt they could replicate its services. In my opinion, the challenge lied in making GPTs' advanced features more accessible to those with less technical expertise.
• I wasn’t certain about whether GPTs are apps, chatbots, or autonomous agents. The evolution of the concept of GPTs itself might have been based on the plugin concept—but the original plugins weren’t highly successful.
• Some started using custom GPTs to integrate company documents, showing potential as knowledge bases.
• GPTs might be evolving into Character AI, focusing on artificial personas, though their potential to become platforms for autonomous agents is uncertain, with Actions allowing GPTs to interact with the real world through APIs, potentially evolving into platforms performing tasks independently.

Did any of this happen?

OpenAI reports that users have created more than 3 million custom versions of ChatGPT. However, I haven’t come across any that have went viral, say, taking over Twitter in a single night. It seems that these customizations are primarily used for internal workflows—which is exactly how I use this feature myself. Let me show you.

I've developed three GPTs for my personal use: Summarize, Rewrite, and Density.

• The first two aren't overly complicated. Summarize does just that—it summarizes articles into bullet points for busy, intelligent readers. I use it to assist in drafting Bits for this newsletter.
• Rewrite was also straightforward to create: it rewrites text to sound as if it were written by a native English speaker. I draft all my articles by hand, but editing takes up a significant amount of time because English is not my first language. It’s not that my English skills are lacking, but for some reason, when I edit on my own, I spend hours tweaking and adjusting, never quite satisfied with the outcome. Rewrite solves this.
• Density is the most intricate of the three. It’s a technique developed by the Salesforce AI team, offering a new method for summarizing text using LLMs. Given that many people use LLMs for summarization, the chain-of-density method stands out due to its strong performance in human preference studies, highlighting its value. Remarkably, this approach integrates smoothly with the standard GPT-4 without any need for fine-tuning, underscoring the potential for discovering effective prompting strategies. I turn to it when the basic Summarize doesn’t work very well.

But they’re not apps, chatbots, or autonomous agents as I anticipated. They are shortcuts. That’s precisely how I created them for my use—I integrated them into my custom instructions:

Treat “/rewrite” as a shortcut for “Rewrite as a native speaker would:”

Treat “/summarize” as a shortcut for "Summarize the following article using bullet points. Keep in mind I have limited time and need a concise, intelligent overview.”

Now, I don’t even have to type the command; I can simply select a custom GPT from the sidebar or, if I'm already in a conversation with ChatGPT, summon any specific GPT using @, similar to mentioning someone in a group chat. This feature is cool and useful since custom instructions are capped at 1500 characters—yet this approach isn’t exactly revolutionary. A similar point came up in my article about AI-powered hardware when I compared it to the previous generation of devices such as smart speakers:

I brought up Alexa for a reason. Although I’m keen to try them, I haven’t yet experienced Meta’s smart glasses firsthand, so my thoughts are speculative. I suspect that even with the integration of a multi–modal large language model, this product may face challenges similar to those encountered by Amazon.

I own an Echo smart speaker and mainly use it for basic tasks like setting alarms, reminders, playing music, and checking the weather—nothing transformative. This limited scope of use is one reason why Alexa hasn’t established a sustainable business model, incurring an annual loss of about $10 billion. It was only with the advent of ChatGPT that a mass–market product of this genre truly took off, rapidly becoming the fastest-growing consumer app ever.

This raises an intriguing question: Will smart glasses follow the trajectory of Alexa or that of ChatGPT?

It appears that even ChatGPT struggles to match the success of its base version. Though the product remains highly useful, the platform doesn’t seem as appealing—not just to me, but likely to the broader audience as well.

I've discussed ChatGPT with my friends who use it for various purposes—some for coding as technical users, and others for more casual tasks. None of them use custom GPTs, likely because they don’t deal with highly repetitive tasks often enough to feel the need—and see the benefit. For instance, if you’re a programmer, you don’t really need a specialized GPT; chatting with the base model or using your text editor’s Copilot does the job well enough. (And if you’re a casual, you’ll use ChatGPT to help you draft emails or do homework for you, which the base model does great, too.)

This leads me to believe that custom GPTs may carve out a niche in the enterprise market. Picture a typical company where every team has highly repetitive workflows or tasks they’re looking to automate. These could be shared internally, making them accessible to all employees. Some of these GPTs might also function as knowledge bases. For example, the HR department could upload frequently asked questions about company policies to the platform. This seems like a practical application. While not groundbreaking, it’s a solid product that OpenAI could successfully offer to many companies.

However, regarding consumer-oriented apps, I’m not as convinced.

• Low customer awareness remains a challenge. ChatGPT, being a general tool, and GPT-4, currently the top model globally, are so effective—even GPT-3.5 handles simple tasks well—that many individuals don’t see a need for a custom GPT. This presents a conflict of interest for OpenAI: maintaining the quality of the base model is crucial to keep users engaged.
• The ability to market effectively is constrained. Text does not serve as an effective user interface for sales, impacting various e-commerce sectors that are unlikely to see significant benefits from adopting the GPT Store. From my experience—I’ve given it a shot. Not with ChatGPT, but I attempted to sell real estate using the Messenger platform. It was unsuccessful because chat platforms don’t offer a better UI for browsing inventory.
• The limited ability to deep-link presents a significant hurdle. Everything that is written using ChatGPT stays in ChatGPT. However, developers aim to leverage platforms for user acquisition, trying to then guide users towards their own apps. This introduces another conflict of interest—as OpenAI will prefer to retain user engagement within its own ecosystem. And unlike Apple which doesn’t make all the apps for iOS, OpenAI’s main product already can do most of the things that GPTs made by others can do!
• The absence of analytics is another notable limitation. For example, a significant area poised for development is the attribution of media, specifically crediting the underlying content that fuels AI queries. This involves determining how revenue should be allocated among publishers. However, we have yet to reach this level. In fact, GPT Store apps feature hardly any analytics!

Another new platform: Apple Vision Pro

While the majority of reviews are positive, people are still exploring and trying to understand the most effective applications of spatial computing.

I think Apple isn’t viewing this as a new platform or a step towards the metaverse, but rather as an incredibly advanced type of monitor. I get it, because so many industries obsess over monitors—graphic designers, programmers with 3-4 monitors at work, and I myself spent a lot on my gaming monitor… yeah, yeah, I know. If Vision Pro is comfortable and has good battery life, instead of buying 4 monitors, I’d just sit down, put it on my head, and have a whole wall as a monitor for my MacBook. That’s why I believe Apple invested in top-class lenses that eliminate the pixelated view like in cheaper VR devices, which also explains the high price.

For me, this makes sense—when I work remotely, I have my entire setup at home. But when I travel, say to London, I’m stuck working on a small laptop. With this device, it's like carrying an infinite number of monitors with me. Maybe the high price isn’t a huge barrier at the moment, considering the market and applications they’re targeting?

Everyone has their methods for looking smart in meetings. Drawing Venn diagrams. Suggesting to take a step back. Some always ask, “Will this scale?” regardless of the actual context. Over my career, I’ve observed another common tactic: saying “We need a balanced approach.” Everybody loves balance! You just can’t go wrong with it.

Except this approach falls short in startups, as they inherently demand a high tolerance for greatly unbalanced environments. Let me explain.

In the early stages of a startup, the focus should be intensely on achieving product-market fit, which means skewing everything towards product development and growth. This includes hiring, setting priorities, allocating resources, and discussions in meetings. Things like policies, perks, consensus-building across departments, structured order, and stability are not priorities—those are concerns for larger companies. Ignore them; if you don’t, you’ll die.

If you’re a gamer, this concept is similar to what’s known as min-maxing. Min-maxing is a strategy where a player maximizes a specific desirable trait, skill, or power in a character while minimizing everything else as less important. The result is a character extremely powerful in one aspect but significantly weaker in others. This is a deliberate choice for gamers; for startups, it’s often the only way to survive. It’s natural selection—they simply don’t have enough people, resources, funds, or time. The stakes are high. If you can’t min-max your way to the next important milestone, you’ll die.

The milestones change at each stage of a startup’s journey. Once the product-market fit is achieved, the next objective is scaling. After scaling, the priority shifts to making unit economics viable, followed by preparing for an IPO. Throughout these stages, one constant remains: compared to an average mature corporation, a startup at any given point in their lifecycle will seem unbalanced. Every startup, even the generational ones, appear almost dysfunctional at some point. Take major success stories from the past, like Uber, for example—there were skeptics who doubted its profitability even long after its IPO.

To thrive in a startup, whether as a founder or an employee, you need to grasp this reality. Employees, while having less at stake compared to founders, often face a tougher reality than their peers in larger companies. Consider a scenario where your CFO announces that the company is less than 100 days from shutting down unless it becomes profitable, as securing another bridge round is no longer feasible. This is a challenge many startups are currently confronting, especially with the shift in funding conditions following the end of the ZIRP era.

Or imagine being an employee at Figma, a startup that has achieved remarkable success by any standard. The excitement when news of Adobe’s $20 billion acquisition offer came in. As an employee with equity, you might have started imagining ways to spend your share—a reward for your hard work. The situation took an unexpected turn when Adobe called off the deal in December, citing uncertainties in obtaining antitrust approvals in Europe and Britain. What was once a real valuation turned into paper value once again; your profits, illiquid again. Despite no fault of your own, the next day requires you to return to work and refocus on another big exit opportunity—possibly an IPO. This path could take years and is not without risk. (WeWork, anyone? Not that it can be directly compared to Figma, of course. But the risk is always there.)

This isn’t a balanced situation.

It’s simply a min-maxed outcome of min-maxed work.

🙏 My work is reader–supported. You can get a membership here!

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

📚 My new ebook Generative AI in Product Design offers case studies on AI and just enough theory for you to build your next app with gen AI. Get your copy here!

Did a friend forward this to you? Subscribe now to get the latest updates delivered straight to your inbox every week.

If you’re working with just two engineers to develop a video streaming app, you’re likely setting yourself up for failure. A photo app might be more feasible, but even then—it’s likely to be flawed.

Some ideas require more resources to be successful.

I made this mistake with my previous startup. We tackled real estate using AI in a few promising but distinct areas. We divided our product into modules, each based on some traction we’ve seen—but attempting to execute all of them at once led to a product that was perfectly mediocre in every aspect that mattered.

Now, years later, I understand that our approach was similar to that of other startups like Rippling. Rippling innovates in HR, IT, and finance. On their website, they showcase 9 products in their HR Cloud, 2 in their IT Cloud, and 5 in their Finance Cloud, totaling 16 products—so the strategy isn’t inherently flawed.

However, Rippling's situation is different; they’ve raised $1.2 billion over seven rounds and have, according to some public sources, around 2,500 employees. We had a million in seed funding and a team of about 10 people. And that was probably too high a number—as we had to compromise on experience to fill so many roles with the money we raised.

Rippling’s founder, Parker Conrad, had previously co-founded Zenefits, another successful startup valued at $4.5 billion, whereas we had limited entrepreneurial experience. While it’s not impossible for first-timers to achieve success, we didn’t. Even if we had found more success, we would likely have needed to raise much more funding to realize our vision in the first place, creating a sort of catch-22 situation, as we wouldn’t get it without more credentials.

If I had the chance to start over, I would still keep the long-term vision in mind but concentrate on the most promising single product, dedicating years to refine it. I believe this focus is crucial, as even with more resources, our lack of experience would have been a hurdle. We struggled with making swift decisions, managing technical debt, and made some poor hiring choices. With more experience—or perhaps a bit of luck—we might have managed to stick the landing based on our original plan. However, under our actual circumstances, perfecting one product first and learning from our mistakes would have likely been a better strategy. This would have taken more time—but it would also have reduced our overall expenses, allowing us to invest more as time went on and we achieved new milestones.

I sometimes wonder why we didn’t do it that way. Part of the reason might have been our observation of other companies, similar to Rippling, achieving success with similarly broad strategies. We believed we could replicate their success—but lacked the insight to recognize that these startups were at a different stage compared to us. A more realistic comparison would have been with their earlier, less impressive versions when they were just starting out.

Another factor was our impatience. We lacked the confidence that a single product, initially underperforming with just a few customers, could improve and attract thousands. We observed that introducing a new product brought in 20 new customers, and another addition brought 10 more. This immediate growth encouraged us to continue expanding our product suite. But this approach had its limits. It became inefficient as our expanded offering wasn’t compelling enough for a broader audience beyond early adopters. The size of our product suite also made it difficult to move swiftly or make significant changes, as we were reluctant to sacrifice any part of it.

A slow death, possibly preventable, that we unwittingly brought upon ourselves.

🙏 My work is reader–supported. You can get a membership here!

📣 Before Growth has grown through word of mouth. Want to help? Share it on Twitter here, Facebook here, or LinkedIn here.

📚 My new ebook Generative AI in Product Design offers case studies on AI and just enough theory for you to build your next app with gen AI. Get your copy here!

Did a friend forward this to you? Subscribe now to get the latest updates delivered straight to your inbox every week.

• The number of people in startups focusing on peripheral activities like podcasts, newsletters, and investing appears to be growing rapidly. Why?
• Tech’s health check
• Is Rabbit R1 the future, and why not? (It looks cool nonetheless.)
• OpenAI launches GPT Store.

I started this newsletter for several reasons.

Firstly, following my last AI startup, I wanted a less tech-heavy project. As a programmer, I’m aware of the common pitfalls in our field, like the tendency to become fixated on development, hoping someone will discover and use our app. This time, though, I chose to prioritize distribution. The scripts behind a newsletter are quite simple—and aside from creating content and engaging with readers, distribution is the most fascinating aspect of running it.

In other terms, launching a newsletter is easy, but attracting a large readership is challenging. And I wanted to improve my skills in the latter aspect.

Secondly, I’ve seen the benefits of having an audience among my peers who started at the same level as me. Unlike me then, they focused on regular writing. If I were to I launch something, it would go unnoticed, but their launches would attract many users. This is a big edge for anyone starting a new business. While I’m not great at platforms like Twitter, Instagram, TikTok, or YouTube, I do a good job at writing. It makes sense to connect with people who might appreciate my work through it.

Thirdly, a realization that came only after I began—and it wasn’t my original thought, but I like it a lot— is that this project represents a shift from a big TAM founder to a smaller TAM startup. (TAM as in Total Addressable Market.) My previous approach as a founder was typical of a zero-interest-rate policy environment: target the largest market, address the biggest problem, and easily secure more funding from investors after enough progress. This approach taught me a lot, but these days are now gone. What if I applied the skills I developed in pursuing large markets to a smaller-scale project like a newsletter?

Here's an example of this very idea in action: newsletters. You’ve seen the jokes about the smartest people in the Valley starting a Substack instead of an ambitious VC-backed startup.

Who are they? Big TAM founders. People who have the experience and skills to tackle something with huge potential. What are they doing? Working on a small TAM startup (at least a noticeably small-er TAM than they’re believed to be capable of tackling). And why? Because they see a higher chance of success, even if the potential outcome is smaller.

—Big TAM Founders, Small TAM Startups

Writing newsletters, much like starting podcasts, often gets a bit of a bad rap because of how easy it is and how easily people delude themselves into thinking what they have to say is interesting—even though, in reality, it’s pretty basic. And even those with valuable insights are often asked: why write about building stuff instead of, you know, actually building it? This is a great question, and I thought about it deeply before launching Before Growth. That’s also a key reason I wanted to share my thoughts with you.

I agree that actively building things is crucial, which is why I don’t plan to replace my daily startup job with this newsletter even if I could. Instead, I view it as a strategic hobby. If I were to try a new, significant project, I’d likely scale back my writing here. My goal is for this newsletter to be a practical resource, grounded in information based on real-world experience. Should an opportunity arise to gain more of that experience to share later, I would seize it and return to writing afterwards. This approach feels intuitively right to me.

So let’s see how this goes.

Your questions, answered…

As an employee, how does negative capability affect the culture and decision-making processes in an early-stage startup?

This is a question that was sent to me by a reader after the last article in December—and it’s a good one. I think lots of frustration that I noticed early-stage employees have about their founders can be derived from tolerance to negative capability: both their own and the founders’.

Let’s consider a simple example. Here are two contrasting thoughts: as a startup, you need to have incredible patience, because it may take years for your work to really impact the world at large, and meanwhile pretty much everybody except some nerds will ignore you, but at the same time you need to move with incredible urgency on a weekly basis, because otherwise your project will most likely die.

We can now translate this to a more practical situation, one you probably encountered if you have every worked at a startup: let’s say you work at an early-stage company where sales are in a slump and the CEO is urging patience for the vision, while at the same time rousing the rest of the team for more urgency. To me, this makes sense: the best way out is often through. But I’ve seen people react with some resentment, because, after giving their all, they found it difficult to understand why they’re asked to give even more while the main problem, from their perspective, lies in another department. It’s very human.

In times like these, it’s important to foster a culture of togetherness—founders should maintain balance while also making sure everybody feels like they’re rowing the same boat.

Tech’s health check

Last year marked the downturn in the tech sector.

2023 was the toughest year for startup liquidity since the global financial crisis 14 years ago. There was a 38% decline in venture capital firms actively making deals, equating to 2,725 fewer firms engaged in dealmaking. The industry saw only 474 funds raised, the lowest since the venture capital boom started in 2013. Total funds raised dropped to around $70 billion, a significant decrease from $173 billion in 2022. The data indicates that funding is now more concentrated in a smaller number of elite funds.

Concurrently, tech companies are downsizing and laying off staff. Already in mid-January, companies like Discord, Google, Amazon, Twitter, Twitch, Humane, Unity, and Cloudflare have announced layoffs. They’ve also cut back on spending with vendors, leading to the most significant churn in years for non-essential SaaS services.

The current situation has huge downstream effects. Firstly, there’s been a sharp decline in startup formation, with more than a 40% drop. The funding landscape has essentially divided into two segments. The first segment is the seed round, which is high-risk. Think young AI startups—especially ones build on top of huge platforms like OpenAI. Despite the risks, these startups often find it relatively easy to secure a few million dollars due to the huge potential upside and the industry’s enthusiasm, allowing them to test a few initial hypotheses.