DALL-E/Every illustration.

Why Building in AI Is Nothing Like Making Conventional Software

Introducing Source Code, your backstage pass to Every Studio

74 6

There’s a fundamental loop underneath everything we do at Every: Write -> build -> repeat. Building exposes you to aspects of the world that were previously hidden. Writing helps you to find a precise, concise way of expressing what you know and why. This loop isn’t necessarily linear—sometimes we start with building and move to writing, sometimes we start with writing instead—but it does lead to, we think, a particularly effective way of creating new things. 

That’s why, today, we’re launching Source Code, a new column where we bring you into our product studio as we tinker with what comes next. This first piece, by Every entrepreneur in residence Edmar Ferreira, is an incredible articulation of building products in AI, why the key risk of new AI products is feasibility, and how to deal with it through fast experimentation. Sign up to be the first to try our products as an Every Early Adopter.—Dan Shipper

Was this newsletter forwarded to you? Sign up to get it in your inbox.


When I started building my first AI project at Every Studio, I approached it the same way I’d built products in the past: Identify a clear problem, map out a solution, build an MVP (minimum viable product), and iterate from there. It’s a fairly straightforward, software-driven approach: Build fast, test, learn, and improve. 

But it didn’t work—so I asked myself: How is building in AI different from building in conventional software?

I joined Every Studio with an ambitious goal: to build nine products in three months—one project every 10 days. My first project, Mindtune, is an AI-driven alternative to traditional adtech and social media algorithms. My hypothesis is that people are fed up with the formulaic, impersonal content in their social media feeds, and that AI offers an opportunity to deliver a more relevant, personalized experience. 

I started Mindtune with demand validation because this is where traditional software projects tend to fall apart. You build landing pages, talk to potential customers, analyze competitors—and only then do you invest resources in building out the product. Founders have been following this template for so long that it’s like a reflex. We don’t necessarily stop to ask ourselves, is building this thing even possible? 

Building with AI requires us to break our habits and approach building in a different way. AI products bring with them a unique set of risks, and if you don’t understand them, you’re bound to make mistakes.

As I was building Mindtune, I identified three risk profiles that helped me see exactly what kind of risk I was taking on—and, more importantly, what would determine whether it succeeded. I’ll dive in to each of the risks, how they relate to each other, and how AI disrupts the traditional startup “risk chain.” My hope is that founders and builders can save themselves a few wrong turns in the idea maze by better understanding where the risks in their idea lie—and how best to defuse them.

The startup risk chain

There are three types of risks involved in any startup: feasibility, value, and viability. 

  1. Feasibility risk: Can we actually build it? This is the classic engineering challenge. SpaceX, for instance, faced feasibility risk when developing its reusable self-landing rocket. 
  2. Value risk: Can users extract value from it? This is the heart of product-market fit. Airbnb was a great example of value risk—most people initially thought it was a ridiculous idea, assuming no one would ever want to stay in a stranger’s home. 
  3. Viability risk: Can our business extract value from it? Facebook and Google famously struggled with viability risk early on. They knew they had a product people loved, but it took time and experimentation to find a sustainable business model.

The way these three types of risk interact is critical. Think of them as a chain: Feasibility → value → viability. If your product isn’t technically feasible, the other two risks don’t matter. If it’s feasible but not valuable, you’re stuck again. And even if users love your product, you still have to figure out how to make money from it.

Create a free account to continue reading

The Only Subscription
You Need to Stay at the
Edge of AI

The essential toolkit for those shaping the future

"This might be the best value you
can get from an AI subscription."

- Jay S.

Mail Every Content
AI&I Podcast AI&I Podcast
Monologue Monologue
Cora Cora
Sparkle Sparkle
Spiral Spiral

Join 100,000+ leaders, builders, and innovators

Community members

Already have an account? Sign in

What is included in a subscription?

Daily insights from AI pioneers + early access to powerful AI tools

Pencil Front-row access to the future of AI
Check In-depth reviews of new models on release day
Check Playbooks and guides for putting AI to work
Check Prompts and use cases for builders

Comments

You need to login before you can comment.
Don't have an account? Sign up!
Jennie Pakula about 1 year ago

Really great post. Interesting to consider with AI for legal services - part of the feasibility risk is ethical, and it's likely that current regulatory frameworks around unqualified practice are not going to be able to properly capture the real risk profile here.

Edmar Ferreira about 1 year ago

@JPak this makes a lot of sense and it will become more relevant as the model capability increases.

Oshyan Greene about 1 year ago

Very good and timely (for me) outline of key considerations for builders in this new environment! I think for many people the pivot to "deep AI" will be infeasible but that doesn't necessarily mean the project is did. One of the exciting things about the AI revolution-in-progress is how quickly the baseline models improve *without* your input. So one reasonable option, given the pace of foundational model improvement, is simply to set the project aside for even a mere 3-6 months. There is a very real chance it will be viable when you pick it back up again, which is just insane and to my knowledge hasn't really been the case for cutting-edge tech pretty much ever (in terms of how long you'd have to wait for someone else to figure out the core problems you're facing).

There is also the key factor of foundational models being so highly accessible so immediately, which again has largely not been the case with other tech TMK, whether through genuine withholding (not explaining how your tech works, much less open sourcing it), or de facto inaccessibility (the new tech is hard to understand or make use of due to its complexity). AI has the incredible qualities of moving very quickly *and* being something that almost anyone can immediately make use of the moment it is updated. A new foundational model comes out and it's almost immediately exposed via the same or a very similar API (and chat interface) as you've already been using. New features like custom training, Embeddings, etc. take a little time to figure out to be sure, but are still incredibly accessible compared to many "open" but technically challenging platforms and systems of the past (try writing your own IMAP client for example).

But yes, the broader points of the article remain strong. This is just more color and nuance to the playing field.

Edmar Ferreira about 1 year ago

@Oshyan "So one reasonable option, given the pace of foundational model improvement, is simply to set the project aside for even a mere 3-6 months. There is a very real chance it will be viable when you pick it back up again, which is just insane and to my knowledge hasn't really been the case for cutting-edge tech pretty much ever"

This is an excellent point! I have some projects on my backlog that I revisit from time to time to see if the models have become good enough.

Manoel Lemos about 1 year ago

Thanks for writing that, Ed! It's a valuable piece of content and a helpful framework for everyone out there building AI-based products. Keep rocking, writing, and publishing! ;-)

@myfamilylovespaper about 1 year ago

In a few months, I am going to embark on a project to build a knowledge bot in my company to assist the Product Managers. This frame is going to help to approach the project. I would have started with wireframes, like you said. Thanks for writing this.