AI, App Building, & Data Modeling // BrXnd Dispatch vol. 051

On transcript parsing, Airtable, and strategic problem

Almost a year and a half ago, I talked about using Airtable to prototype AI ideas:

Airtable is one of my very favorite ways to prototype ideas and works particularly well for playing with APIs as they have a built-in Typescript editor. For those unfamiliar, Airtable is basically a database not unlike PostgreSQL or MySQL, but it has a simple frontend resemblant to Excel or Google Sheets. The real power comes when combined with Automations, which, if you’re on the $20-per-month pro plan, includes the ability to write almost any Javascript/Typescript that interacts with your base. The magic of Airtable as a prototyping tool is that your database and code can all live in the same place, and thanks to Automations, Views, and some other niceties, you can build some pretty complex stuff with very little code and no worries about setting up your environment—which is the bane of the amateur coder's existence. (For context, most of my BrXnd Collabs tool runs on Airtable to this day.)

Since then, I’ve gotten to know Howie, the CEO/co-founder, who spoke at and sponsored my spring 2024 conference in NYC. In addition, I’ve been doing prototyping work with the team there and a handful of brands to build out various AI experiments and workflows in Airtable. As part of that, a) I want to share some of the stuff I’ve been building, b) offer some takeaways on what it means and where a tool like this fits into the broader landscape, c) give you all access to the tool if you want to use it yourself (skip to the bottom for that).

Amongst the many builds I’ve done, one I’ve been using a lot lately is what I’ve not so creatively dubbed Transcript Parser. It basically runs through this flow:

1. Catches all my calendar events and adds them to an events Table

2. Also associates each event with attendees based on their email address

3. When I have a meeting, Otter records it, and then I use the Airtable Web Clipper to copy the transcript into Airtable (sadly, Otter has no API—if anyone from Otter is reading this, please add one!).

4. It uses AI to parse the transcript in a way I like, which basically breaks it down to Key Points, Interesting Points, Next Steps, and Action items.

5. It also attempts to parse out the names of the people in the meeting based on the transcript. Since calendar events often just have email addresses, I need a way to associate those email addresses with names. So, as each transcript is added, any attendees who are currently nameless in the base have AI attempt to match their email address with the extracted name of one of the attendees. (This works remarkably well since most corporate emails include some combination of first and last names.)

6. After the summary is complete it sends it to a private Slack channel for me.

7. The AI then attempts to extract tasks from the transcript. 

8. Each task is also sent to Slack with an Airtable automation that allows you to say whether you’d like to add it to your to-do list or ignore it.

9. After you make your choices on tasks, another prompt takes the choices and the list of current task preferences and attempts to add more rules so that it’s always getting better.

10. Approved tasks are then emailed to my task management system (I used Linear)

11. Each meeting summary is also added to my Obsidian notes by writing a file to Github, where I sync. (This is awesome, and I have lots more fun Obsidian automations coming.)

If all this sounds complicated, it kind of is, and kind of isn’t. The reality is that the app is made up of just a few Airtable Tables (essentially database tables) and a relatively small amount of code to do things that the platform can’t already handle out of the box, with AI doing most of the heavy lifting to connect one bit to the next. As I have said in the past, the real magic of AI is as a fuzzy interface that allows you to connect anything to anything else.

So, what goes into building an app like this? Obviously, a bit of coding know-how. However, the first step in the process is really figuring out the data model. Ask any engineer how they start a project, and they’ll tell you the bulk of the strategic work goes into figuring out how to structure the data. Modeling is essentially the question of what should go where: which tables do you need, and how should those tables relate to one another? My Transcript Parser has the following core tables:

• Events

  • Event Name

  • Start Time

  • Attendees

  • Etc.

• Attendees

  • Email

  • Name

  • Company

  • Etc.

• Companies

  • Name

  • Domain

  • Summary

  • Etc.

• Transcripts

  • Name

  • Event

  • Summary

  • Etc.

Relationship diagram from my Transcript Parser app.

The trick of data modeling is not just figuring out what needs to go where but doing it in such a way that it can work for you instead of against you as you're building out your workflows. In this case, why have a separate Companies table? Well, you'll often meet with many people from the same company. So rather than keeping the company name, description, etc., along with the attendee info, I just keep one copy for each company. This approach, known in database design as normalization, ensures data consistency and efficiency by maintaining a single source of truth for each piece of information.

It's easy to keep those companies separate since a company's domain name is a good single bit of unique data to key off.

While these concepts may initially seem complex, they're fundamentally strategic. Like any business strategy exercise, you're trying to find the most concise way to represent a set of interrelated ideas. The difference is that instead of creating Venn diagrams on a slide, you're designing tables and relationships in a database. For marketers, this data modeling approach could mean structuring a customer journey map, where each touchpoint is a table with relationships to customer segments, content types, and conversion metrics.

This process forces you to think critically about your data. Key questions emerge: What are the core entities in your system? How do they relate to each other? What attributes define them? By answering these questions, you're not just organizing data—you're creating a digital representation of your business logic. This isn't just software architecture 101, it's a fundamental exercise in business strategy.

However, mastering this skill takes time and experience. While much of the AI focus in development has been on writing code, data modeling is in many ways a more crucial first step. It's the foundation upon which everything else is built. Code without structure is just a script. While scripts are great for automating small bits and pieces, if you want to tackle more strategic problems, you’ve got to think about the broader picture. (Top right of my 2x2 below.)

That more strategic quadrant is where tools like Airtable's new Cobuilder feature come into play. At its core, Cobuilder works alongside you to help you build an app in Airtable. But the first, and I’d argue the most crucial, step in that process is working with your description and requirements to develop a relational data model that works for your goals. 

Screenshot from Airtable’s Cobuilder

AI excels at this task for several reasons. First, the principles of relational databases are well-documented and have been refined over decades, providing a rich knowledge base from which AI can draw (there’s even a whole visual vocabulary of ER diagrams). Second, AI can quickly process and synthesize complex requirements, asking follow-up questions and ensuring it has the necessary information to solve the problem (something many product managers skip). And finally, because these models have such a broad knowledge base to work off, they have an awareness of almost any problem you might throw at them. As I’ve said, that understanding will probably only be median-level at best, but it’s still better than starting from scratch.

But critically, it also doesn’t take control of the whole process; it’s just offering a starting point for you to work from. On top of that, it squares away actually setting up all the tables, a process that can easily take 10 or 15 minutes of mindless work. This last bit is a much more typical space where we’re seeing AI solve problems (simple/time-consuming), and while it’s a lot less strategic than building the data model, eliminating rote work is a win in my book.

I continue to believe there’s tremendous individual and enterprise value inside these systems when put into the hands of the right folks. One of the things I’ve been saying lately, but I’m not sure I’ve written here, is that I feel strongly that even if these models never got better than what we have today, we still have a decade of runway to extract enterprise value from them.

So, what do we take away from all this?

1. Workflow apps with structured AI decision points are proving consistently effective. These "control flow agents," as dubbed by my friend Lance at Langchain, offer a more practical alternative to the open-ended AI agents people love to talk about but have shown little evidence of actually working.

2. AI is increasingly valuable in solving fundamental strategic problems, like data modeling. Its role as a partner in these contexts allows for faster and more effective problem-solving than previously possible.

3. AI's technical prowess extends beyond just code generation. Its ability to tackle design and architecture problems with similar structural patterns opens up exciting possibilities in various domains.

If you want to try out the Transcript Parser, I’m trying to figure out the best way to share it, but for now, leave your email here, and I’ll hopefully figure something out.

Also, although not completely required for this Base at the moment, I have also released some tools to do some stuff not currently easy in Airtable, like scraping. The GitHub repo is available here, and it’s reasonably simple to run it on Vercel. It gives you APIs you can call from Airtable automations to do a few helpful things.

I think that’s it for this week. Thanks for reading, subscribing, and supporting. As always, if you have questions or want to chat, or if you’re at a brand and want to experiment with building some of this stuff, please be in touch. I am having a lot of fun working with folks on prototyping various creative AI tools.

Thanks,

Noah