Transcript
I am Arthur, one of the co-founders of Softr, and I am responsible for everything tech. Today, with Guillaume, we are going to do a live build. Softr started about four and a half or five years ago as a much simpler version than what we have today, and now we have more than a million builders creating applications on the platform.
The year 2025 was when Softr became truly full stack. Before that, it had a lot of powerful features, but it relied heavily on external data sources like Airtable, Google Sheets, SmartSuite, and HubSpot. As we added more data sources, we realized that many people arrived without having their data stored anywhere yet, requiring them to create accounts and learn external tools.
External databases also became slower over time, so we wanted to build a more scalable and faster solution. That led us to create Softr Databases, and we had a similar journey with workflows. Early on, we had integrations with tools like Zapier and Make, but those systems ran strictly in the background without a feedback loop back to the application layer.
Users often had to write custom code to glue everything together. With the introduction of Softr Workflows, Softr became a complete full-stack platform comprising databases, the application layer, and native workflows that talk seamlessly to each other. You also have UI triggers, allowing you to display a wait screen and specify actions while a workflow runs, which significantly improves the user experience.
Today we are building an application live based on a real business use case. We want to create an app that takes a meeting transcript, runs an AI analysis on it, and extracts actionable tasks. In meeting transcripts, we often see who spoke or who was assigned specific duties, so the AI can extract those tasks and assign them directly to the right users in the app.
In the second part of the app, logged-in users will be able to view their assigned tasks and drag and drop them onto a calendar to schedule their work. Because a drag-and-drop calendar is custom functionality without a direct native component, we will use the Vibe-Coding block to generate exactly what we need. We can start by looking at the form and the data structure prepared for capturing these transcripts.
In the database, we have a table for users, containing a couple of demo profiles. We also have a meetings table where the form will submit entries and store incoming transcripts.
These meetings will be first captured here, and then the workflow will run to create tasks. After that, you will be able to drag and drop them in a custom calendar. Starting with the database is probably one of the best ways to begin once you have a good overview of what you want to build. Nailing the structure of the database is a crucial part.
From a technical standpoint, I usually try to keep tables as small as possible. Many times during troubleshooting, we realize customers have tables with over a hundred fields. Unless it is truly necessary, it is best to split those into multiple tables.
You should also think about your primary field. Here we have email, which is unique in this context and makes sense. For other tables, like meetings, the title might work fine, but I usually prefer to create ID fields using a record ID field rather than relying on titles with spaces or special characters.
So the rule of thumb is one table per object. Here we have users, meetings, and tasks, which are all distinct objects. A task is not a meeting, but it can be the outcome of one, which is why we can have multiple tasks related to a single meeting.
We also need to think about the relationship type, which people often ignore or leave as default. For example, if a task belongs to only one meeting rather than multiple meetings, make sure to set that relationship as a single link rather than multi-link. You could also set up a workflow where discussing a task in a future meeting updates the documentation of an existing task.
Now we can create the form to capture the transcript of the meeting. In the interface builder, we have the default form that comes with the application. We can connect it to tasks and meetings, and then adjust the form fields so they make sense.
Filling out a form is already a manual task, so we can identify fields that can be deduced automatically. The title could be AI-generated from the transcript, while still allowing users to manually edit it later if needed. Since transcripts do not always contain a clear date, we should keep date as an explicit input field.
We will map the text area to the transcript field so you can paste in notes from Google Meet transcripts or any other tool, and let the AI do the processing work. For the date field, we can set the input type specifically to date rather than date and time.
Once the form captures the information, it saves it inside the database. We can test submitting the form first without the workflow attached to make sure everything works properly. We can preview the app, select today's date, and submit the entry.
We have a test one going, which is great. Now we are back here in the steps, and we want to add an ending. We could either select the workflow as a destination or as a form ending.
It is convenient that the destination is the data source. Whenever there is a submission to that form, it creates a record, but we will add an extra aspect to run a custom workflow whenever we hit submit. That is the automation we will create now.
We will create a workflow, which is a special type because it is connected directly to your form and has a connection to the UI of the application. That gives you the convenience to create directly from here and jump straight into the workflow. It really helps to create the next steps after this form is submitted, like sending the user to a different page based on the submission.
This provides a UI where you can show a screen and end the interaction in a certain way. Those are the kind of features that you usually miss when connecting to a third-party workflow engine, because they are not nicely integrated with the app builder. With native workflows, we have the luxury of connecting those pieces together.
I used to build workarounds with webhooks and custom code for a waiting screen. Right now, it is completely built in, and you have this loading screen that makes the user wait until all the intermediate actions proceed.
Let us try testing this. It says no record found because we need to go to the app, preview again, and send one more test before we can test it here. The team is working to improve this so we do not necessarily have to do the preview, submit, and return steps.
We can preview it again and submit another form. It needs to be on so that it starts to capture the workflow. Let me go back to the workflows.
Now if we test the trigger, it went through the workflow and you can see the wait screen. When I test it here, I get the record. We have the form data passed to the workflow as well as the record coming from the destination data source.
In this case, we are first sending the data into the database and then triggering the workflow. We have the inputs from both systems: directly from the form itself and what has already been persisted. We have a record ID here coming from the database that was inserted into the form.
At some point, I needed the record ID we just created, so it is convenient to have everything right here. I can take over the next steps.
For this workflow to be successful, we need to identify tasks based on the transcript using an AI step. Ideally, I would also like the AI to know who should own what task. In Softr Databases, we will find multiple records from the users table to fetch all of our user data.
[.blog-callout]
Note from Softr: Softr Databases provides a native backend built directly into the platform, offering faster performance and seamless integration with Forms and automations.
[.blog-callout]
Because we have the names and their record IDs, we can have the AI match that with the transcript. That is all the data we need to fetch before using an AI step. I will select a custom prompt to set this up.
To initiate or trigger a workflow, you have different options such as a recurring schedule, a webhook, or when a database record is added or edited. We support triggers for external data sources like Airtable as well as Softr Databases.
We previously had Softr Databases triggers wait about a minute to detect newly added records. We recently improved that behavior so that database triggers execute instantly.
So now that is instant. For the other data sources, we have the same way of working as when using Make or Zapier. They need to poll to see if there is any change in that table, as we do not get direct communication from these external data sources.
It is one of the key benefits of having your app and your workflow as close as possible to the data source. Because Softr is one unified platform, we can make these triggers instant.
[.blog-callout]
Note from Softr: Softr Workflows keeps logic and automation directly inside your app alongside your data, removing the need to manage third-party tools like Zapier or Make.
[.blog-callout]
We need the AI to return a structured output because it has to identify multiple tasks. We cannot simply ask it to output unstructured text listing tasks, because we need to map those tasks directly into our database table. For that, we will be using structured outputs.
JSON is a standard format used to structure data. In the past, formats like XML and HTML were commonly used, but JSON is the modern standard across APIs and AI systems. While AI can return plain text, unstructured text is difficult to process automatically.
With JSON, we provide a schema and instruct the AI to return data in that exact format so we can process it with high certainty. You can provide a very precise schema or simply give an example, and the AI will understand the required structure.
Next, we write the actual AI prompt. We will provide a meeting transcript and instruct the AI to identify the discussed tasks and assign them to the appropriate user. We pass user data dynamically by referencing our earlier action that fetched all records from our users table.
If you have a large user base with thousands of users, you would not want to pass the entire list into the LLM. Instead, you could have the AI extract names or emails from the transcript using the JSON schema first, and then query the database for those specific matching users. For smaller teams with ten or twenty users, passing the list directly works well.
Another optimization is passing only the record ID and user name rather than the full table payload. Getting this structured JSON output ensures we have reliable keys like task title, description, and user ID that we can act on later in our workflow.
Because the output is an array of tasks, we can add a bulk action step to loop over each item in the list. For each task in the array, we will create a corresponding record in our Softr Databases tasks table.
Inside Softr Databases, we select the Add Record action and map each field one by one. We map the current item task title to the name field, map the description accordingly, and set the initial status to To Do.
Here we need to map the related meeting, and I will just get that from the form based on the destination response record ID. As we filled in the form, we created a record, so we have that data here and can directly map them together. For the user, we will be using that generated user record ID, and we can call that step create tasks.
While you are doing that, it is good to note that you are passing IDs here, but you can pass other primary fields as well. For example, if you only pass an email for the user and email is a primary field, the system will still match it. That gives you the flexibility to use the data you already have.
It is very convenient that both the ID and the primary field value work for this kind of mapping. Sometimes you want to keep the primary field readable for dropdown menus in your app, but under the hood, a unique ID is being used. What we forgot to add, which we can quickly do now, is a mini AI step that gives a name to the meeting we just created.
We can add a custom prompt asking for a title of less than 10 words for the meeting and pass the transcript again. You can use a simpler model here, which is a good tip for tuning models to a specific task. We will choose Gemini Flash since we do not need a structured output and will just reuse the generated text.
We can name this step meeting title and test it out. Then, in Softr Databases, we update the meeting in the task manager. We find that exact meeting using the record ID, update the title field, and map what the AI just outputted.
We can specify no formatting in the prompt so we do not get bold markdown in the title, which makes it super easy to iterate on these AI prompts. That should work, so I will update this workflow. Now we are done with the first step of our app.
I will do some cleanup to make sure we have the right pages and rename this form to add a new meeting. In the settings, we can also give it a nice icon. Back on the homepage, we can adjust the studio theme to customize the look of the app.
We can use this block to show a list of all our meetings instead and call it all meetings. The add meeting action will open the form page in a modal. Now, if we preview the app, we can click add meeting, paste the transcript, set a date, and hit submit.
Right now we see the loading screen, though we could also consider running that process in the background. Once it finishes, a new meeting appears right here with its generated title. We can clean up this block to display the tasks, transcript, and date.
Previewing what we have, we can see multiple tasks linked to that meeting. Now it is time to build the second part of our workflow. The tasks are all cleaned up and automatically filled, which is amazing.
Next, we want to add the drag-and-drop calendar feature. To display items on a calendar, we need a date field in our table, so we can add start date and end date fields to keep things organized.
Now we will use our Vibe-Coding block to build this experience. When crafting a prompt, there is no single way to work with LLMs, but you want to be precise without being overly verbose. A good approach is to connect the data source first to ensure context is passed, specifying that we want to show tasks on one side and the calendar on the other.
With vibe coding, you start with something, iterate, and improve rather than trying to get everything in a single prompt. We can start by generating the interface and then test the update functionality using existing CRUD operations or workflows.
Describing the most aspects possible leaves less room for the AI to interpret what you might want. Whenever we preview this app, we act as one of the users, which is something we can configure. We can set it up so that you only see your own tasks.
This is what differentiates building in Softr from many other tools. You can precisely define where it gets data, who has access to what, and which user groups can perform specific actions. Right now, I configured the user sync by mapping our data source fields—email, first name, and task links—directly into Softr.
In a couple of seconds, it syncs our users with the ones in our data source. From there, we can go back into the interface and set the condition to only show tasks where the assigned user matches the logged-in user email. That way, I only see my tasks when I log in.
Now, let us write a prompt. I need a calendar on a weekly view that can also switch to a daily view, taking up the left part of the block. On the right side, I want to see all tasks without a start and end date, so I can drag and drop them onto the calendar with a default duration of two hours.
We could also plan our database to include a field where AI estimates the time needed for each task based on its scope. That way, dragging and dropping would automatically apply the correct duration. Alternatively, we can let users resize tasks manually in the interface to adjust the timing.
Someone asked how to create a JSON schema, and there are multiple ways to approach it. You can stay within Softr and use the AI Co-Builder within Softr Workflows to generate one and place it directly. Providing a simple example instead of a strict schema works just as well.
[.blog-callout]
Note from Softr: You can use Softr Workflows to automate backend logic directly inside your app, or design entire structures using the AI Co-Builder.
[.blog-callout]
You can also use any AI tool to generate the schema by specifying that you want an array containing task titles, descriptions, and user record IDs. Structuring the request this way allows the workflow to iterate through the list and create tasks one by one. The AI follows these guidelines to deliver a clean structured output.
In another app, I used a Vibe-Coding block to import contacts into a CRM via CSV upload, which took just two prompts. The calendar component is now generated, so we can test the initial version. We gave the AI freedom on layout, and the core functionality is in place.
Testing the drag-and-drop shows the event on the calendar, though a two-hour event currently renders as two separate blocks instead of one continuous block. We can switch to the daily view, move items around, and adjust days. Next, we can prompt the AI to refine it so clicking a task reveals its item details block and multi-hour events display as unified blocks.
Regarding the underlying models, this implementation uses Anthropic models like Opus, though we leverage both OpenAI and Anthropic across different internal features. We have many additions planned for the Vibe-Coding block, including planning modes and extended functionality as it continues to evolve.
The grid gets a bit broken when there are events on that day because it gets wider, so maybe you can fix that. My tip would be to try to solve one problem at a time, which is what we also do in engineering. If you ask two or three things at once, it might do them, but if you go more atomic with small incremental steps, you get better results.
While it does some edits, I am preparing my next request. When there is an event on a specific day, the width of the grid increases, which doesn't match the header grid, so maybe find a better way to display those. I'll launch a preview to check the current version that we have.
That is really cool because I can manually edit the description, change the status, and change the start date right here. If I remove one hour, it will probably show up as one single block. The rest didn't change because I just sent the prompt now, but we can also check the content tab.
Can you explain how this works under the hood with the different versions of the block here? Every change is modifying the code, and we are saving every change because sometimes you might want to go back or the LLM might produce a result that you don't like. This gives you full version control so you can go back, continue from an earlier version, and iterate on top of previous iterations.
We have all these versions of code persisted, which provides a lot of flexibility. If someone can code, they can also manually edit the code directly and save their work as a new version. You can always revert if something didn't work out, or you can duplicate it.
In the actions tab, we can see the actual actions that are activated and define which user groups should have access to them. That is a super powerful part because it gives you visibility over actions and permissions. Looking at the new layout, it seems the grid layout has improved and looks pretty solid for the day view.
Here are a few quick tips and upcoming features for the Vibe-Coding block. One feature currently available is the ability to upload an image, such as a screenshot of a calendar you want to replicate, and it will generate a clone as close as possible. It is not widely advertised yet, but it can create components based on whatever image input you provide.
If you want to use screenshots to ask for improvements on an existing design, I would recommend testing that on a new block or a duplicated block first. It generates new controls from the image, and you do not want your working version to be affected. Starting with an image on a new block is a great way to get a quick start.
Another feature coming soon will allow you to update certain text changes directly without needing to reprompt. If you only need to update the block title or simple textual content, you won't need to consume credits or regenerate the whole component. Having instant direct controls for those simple edits will make the workflow much faster.
Even in this early version, we can imagine a full app managing our meetings. You could add a new meeting by pasting the transcript from your meeting tool. When you submit it, a record is added, the background logic generates the related tasks, and it assigns a title to the meeting automatically.
From there, you get all your assigned tasks. The app reloads with the title and tasks ready to go. You navigate to the tasks page, the calendar loads, and you can drag and drop those tasks directly into your agenda to update them.
I do not know what next steps you would see, Artur, to bring this to another level. What I would do next is avoid manually copying and pasting the transcripts. Whatever tool is recording your meetings and transcribing them, I would connect that to Softr Workflows so it runs on autopilot. You have a meeting, everything is created for you, and you can even receive Slack messages whenever tasks are assigned to you and placed on your calendar.
When you start a workflow with a webhook, that URL acts almost like a phone number you can give to your meeting recorder app, assuming it can send webhooks and transfer the transcript via API. Once we receive it, we add an action to actually create that meeting record. Having that automated route in addition to the manual form is ideal, because if the recording tool fails to send the webhook, you still have the manual button available in your app.
In terms of building philosophy using the Vibe-Coding block inside Softr, when is a good time to use it versus native blocks? It is about balance. If you need a scalable table and do not require extensive customization, you should stick to native Softr tables because they are battle-tested and include a lot of UX considerations out of the box.
However, if you need something truly custom and want to go beyond what existing blocks offer, you can build your own. That comes with a trade-off: you have to iterate on it, test changes carefully, and accept that it will not have every native feature right away. For business apps, ninety percent of use cases do not require reinventing layouts; standard forms, tables, charts, a kanban, or a calendar are sufficient.
If you need something specialized, such as dragging and dropping events on a calendar, resizing them, or adding audio capture, you can use the Vibe-Coding block. I released a video showing how to build a custom CSV import interface to bulk-create records in your app using this block. It expands what is possible while keeping you inside a reliable and secure no-code infrastructure with built-in user management and permissions.
The Vibe-Coding block is very secure because it shares the exact same data layer. You still connect the data source, apply conditional filters, and configure action button visibility just as you would with native blocks. Softr deliberately avoids exposing every granular styling control in standard blocks so the interface does not become overwhelming, whereas the Vibe-Coding block lets you describe what you want in plain text.
The boundaries between these two approaches will likely converge over time. We are planning a feature that allows starting with a standard block and converting it directly into a Vibe-Coding block. If you need custom functionality, use the Vibe-Coding block and share your feedback with us.
Regarding the question about whether webhooks should always be auth-key protectable, that is a feature we are actively considering. Within Softr applications, we can make it so only authenticated, logged-in users can trigger the webhook. Since webhooks may also be triggered by external systems without that user context, we plan to make this setting optional so you can configure the exact level of security you need.
Softr avoids exposing every low-level styling detail in native blocks for good reason: padding and mobile responsiveness are already handled out of the box. The Vibe-Coding block also respects these design guidelines and applies your app theme natively, ensuring custom components match your existing colors and styles seamlessly.
And if we were to change it to blue, it would also change. So it is also quite connected to the design rules of Softr overall. But if you want to push the boundaries, you will be able to.
It does not mean that whenever you use a Vibe-Coding block, it will look very different than the rest of the app. It will actually be very well integrated into the app, so the blocks work well together.
