Softr is using AI to help business teams build production-ready apps, workflows, portals, and automations without relying on developers for every custom software need. In an interview with AiNews.com, Shiran Brodie, head of growth and marketing at Softr, explained why AI app building is becoming more practical for non-developers and why business users still need more than vibe-coded prototypes.

The conversation focused on a problem many businesses already know well. Companies buy software, add more tools, and still end up using spreadsheets, manual workarounds, and disconnected processes to get work done. AI now gives teams a new option. Instead of choosing only between buying rigid software, hiring developers, or living with the pain, teams can start building apps around the way their business actually works.

Brodie also drew a clear line between AI-generated demos and business software that can operate in production. Softr’s approach centers on an AI co-builder that asks clarifying questions, generates a connected database, creates app pages, supports authentication and user permissions, and assembles apps from tested software building blocks.

In short, Softr is trying to make AI app building useful for real business operations, beyond fast prototypes or hobby projects. The company’s bet is that business users do not only need AI to generate an interface. They need AI to help build the database, permissions, workflows, and secure structure behind the app.

AI app building is the use of artificial intelligence to turn business requirements into working software components, including databases, user interfaces, permissions, automations, and workflows.

Softr’s AI co-builder helps business teams create apps, portals, workflows, and automations by turning business requirements into connected software components.

In the AiNews.com interview, Shiran Brodie, head of growth and marketing at Softr, connected the rise of AI app building to a familiar business problem. Companies often have software, but not software that fits the way their teams actually work.

Brodie described the software problem facing many businesses as less about tool availability and more about fit. Companies may have dozens of applications, but employees still return to spreadsheets because spreadsheets are familiar, flexible, and easy to start using.

That does not mean spreadsheets are the best operational system. Brodie said they are not secure or scalable at larger levels, but they remain attractive because they do not require onboarding, documentation, change management, or a champion inside the company.

In the past, Brodie said businesses usually had three choices when a workflow did not fit their tools. They could buy software, hire a developer to build the software, or live with the pain.

“It’s almost always more people than you realize are still living in spreadsheets, and they’re working in pretty big companies,” Brodie said.

No-code and low-code platforms changed part of that equation by giving non-developers more ability to create their own tools. But Brodie said no-code did not remove every barrier. Users still needed to understand database structure, logic, and system building to create tools that could work reliably in production.

That is where AI changes the user experience. Brodie said AI has made the idea of building custom software feel reachable for people who previously did not see that as an option.

“I think AI has now made people realize what’s possible, and it’s made people feel like for the first time this is something that’s in reach,” Brodie said.

For businesses, the practical issue is not whether AI can generate something that looks like an app. It is whether AI can help teams create software that matches real workflows, supports real users, and handles real data correctly.

Brodie said Softr’s approach starts with the company’s existing foundation as a no-code platform for business software. Softr uses reusable blocks, such as tables, charts, pages, views, and actions, that users can customize and connect to their data.

These blocks are central to Softr’s AI strategy because the AI co-builder is not generating a full application from scratch. It assembles apps from software components Softr has already built and tested, reducing the risk that business users deploy raw code before it has been proven in a production environment.

Brodie described those components as handcrafted building blocks created with business users and best practices in mind. She said Softr has received feedback from more than one million users, which helps inform what those blocks need to support.

“Our biggest belief has always been, and I think very differentiated and unique in that space, is we wanna make it as easy as possible where it’s the user’s only job is to understand their own business requirements, their own needs, and we take care of everything else,” Brodie said.

That distinction matters because many AI coding tools can generate attractive interfaces. The harder problem is turning those interfaces into software that can be published, shared, scaled, and trusted.

Brodie said vibe coding tools can be useful, but she argued they often leave users with raw generated code they may not understand how to inspect, debug, secure, or maintain.

“This is raw, untested code that has never worked in production before. That’s not the case with Softr,” Brodie said.

The key point: Softr’s AI co-builder does not treat the app interface as the whole product. It generates the database, app pages, and connected structure while using tested building blocks that already include important production requirements, including permissioning, authentication, hosting, and user access controls.

That makes Softr’s product story less about AI replacing developers entirely and more about AI handling the setup work that blocks many business users from building the software they need. It also leaves room for technical teams and experienced builders to use Softr as a faster way to assemble, test, and manage business applications without starting every project from scratch.

During the interview, Brodie demonstrated Softr Studio by asking the AI co-builder to create a client portal for a marketing agency. The app was generated in real time during the conversation, showing how the system responds to a simple business prompt.

The initial prompt was intentionally simple. Brodie explained that users can provide detailed requirements from the start, but Softr can also ask follow-up questions when users do not know how to specify the app upfront.

In the demo, the AI co-builder asked what clients should be able to do in the portal. It asked how work should be organized, including whether clients should see projects, tasks, campaigns, assets, or retainers. It also asked who would use the portal, including whether access should include clients, internal team members, or both.

Those questions are important because business users often understand the problem they need to solve, but they may not know how to translate that problem into an app specification. Brodie said some users are not thinking in terms of a client portal at all. They may only know they have a problem sharing information externally or managing a process.

Softr’s AI co-builder then produced a spec, generated the database, created app pages, and connected the application to the underlying data.

Brodie emphasized that the generated database was not a fake backend or a placeholder for technical setup later. It was a real database that users could edit, add to, and connect to the app in real time.

“This database is not a UI. It’s not a fake. This is the real database that it’s spinning up right here,” Brodie said.

She also said the database setup is one of the places where business app projects often break down. If the database schema and relationships are not set up correctly, the app can become difficult to scale or adapt later.

“When we see users come in, they have this idea for an app. Where do things often go wrong? Almost always at the very beginning, which is just the database,” Brodie said.

In the demo, the app included project views, client details, dashboard-style pages, and the ability to add a project to the database and immediately see that data reflected in the app. Brodie also showed how user groups could control what different people can see and do.

That example made the product capability easier to understand. Softr generates a connected app structure where the database, interface, permissions, and user roles work together from the start.

Brodie repeatedly returned to one of the hardest parts of business app building: real software requires access control.

In a business setting, not every user should see the same information. A client may need to see only their own projects. An internal account manager may need access to assigned accounts. A finance leader may only need invoice approval access. An admin may need a different view from a client user.

Softr’s system allows users to define those user groups and preview what each group can see. Brodie said this is one of the areas where raw vibe-coded applications can become risky, because a non-technical user may not know what needs to be secured or how to review generated code for vulnerabilities.

“So are you gonna be able to review the code and debug and make sure that there are no risks to that data? Not really,” Brodie said.

She said Softr gives users a visual way to inspect and control access without needing to read the underlying code.

“I don’t have to play any guessing games. I don’t have to review code. I don’t have to review a ton of code just to see what’s actually happening or if I’m accidentally exposing data I shouldn’t be,” Brodie said.

Softr also highlights enterprise-grade security and scale on its website, including GDPR readiness, SOC 2, 99.9% uptime, and SSO. Those details support Brodie’s larger point that business app builders need to address access, reliability, and security before companies can use AI-built apps in real operations.

Beyond apps and databases, Brodie described Softr as including workflow automation, forms, and the ability to call large language models inside workflows. That means users can connect actions across the app, database, and other tools in their tech stack.

Her example was a workflow for consultants or agencies handling statements of work and documents from email. Instead of using an LLM to check emails end to end every day, a business could use automation to monitor Gmail, download an attachment when certain conditions are met, call an LLM to extract or summarize text from a PDF, and then send the output into the correct database record.

That point adds an important layer to the story. Brodie is not arguing that every process should become an AI process. She is arguing that businesses should use automation for repeatable system tasks and use AI where reasoning, extraction, summarization, or interpretation is actually needed.

“We can’t only think about the excitement and shininess of AI,” Brodie said. “We also have to think about efficiency and, like, where does it make sense?”

Brodie also discussed how Softr handles cases where users need something beyond the platform’s standard building blocks. Sometimes a business needs a specific component or visualization that does not already exist.

That is where Softr’s AI vibe coding block comes in. Brodie described it as a way to bring vibe coding into a Softr app, but with a more contained structure. Instead of vibe coding an entire end-to-end application, a user can generate a custom block inside the larger Softr app.

If that custom block has a problem, Brodie said the issue remains contained inside that component rather than breaking the entire application. The block can still connect to the same data source, use visibility rules, and operate inside the app’s larger structure.

In the demo, Brodie used the example of generating a Gantt-style view for projects when that exact visualization was not available as a standard Softr block.

Softr’s approach gives users a way to start with stable app infrastructure and add custom components only where the workflow needs something more specific. That keeps customization available without requiring users to build the entire application from scratch.

That approach also addresses a common frustration with AI app generation. If users must prompt repeatedly to change a button, adjust text, repair a component, or debug a layout, the AI tool can create new work instead of saving time.

The key point is to use Softr’s standard structure for the parts of an app that need reliability, then use AI-generated customization for the specific layouts, components, or visualizations a business needs.

The main lesson from Brodie’s interview is that AI app building is moving into a more serious phase for businesses. The excitement around generating software from prompts is real, but business adoption depends on whether those generated systems can support actual operations.

A prototype can impress a user in a demo. A production business app has to handle data relationships, permissions, authentication, hosting, user access, workflows, and changes over time.

That difference is especially important for non-technical teams. If AI gives them the confidence to build software, but the generated app breaks, leaks data, or becomes impossible to maintain, the business has not escaped the old problem. It has only moved the problem into a new interface.

Softr’s approach offers a more practical model for AI business software. The AI acts as a co-builder on top of tested systems instead of operating as a raw code generator without guardrails.

The remaining question is whether AI-built apps will make work easier once teams begin using them every day. Softr’s model may reduce the technical barrier, but business teams still need to understand their workflows, decide who needs access to what, and avoid using AI where basic automation would be more efficient.

The goal is not to turn every employee into a developer. The goal is to help the people closest to the workflow build tools that match how the work actually gets done.

Q: What can you build with Softr’s AI app builder?
A: Softr’s AI app builder helps business users create apps, portals, workflows, and automations by asking clarifying questions, generating the database, creating app pages, assembling tested building blocks, and supporting permissions, authentication, user groups, and workflows through a visual interface.

Q: Why do Softr’s tested building blocks matter?
A: Softr’s tested building blocks matter because business apps need more than a generated interface. They need reliable components for databases, user access, permissions, authentication, and workflows so the app can support real operations instead of functioning only as a prototype.

Q: How is Softr different from vibe coding tools?
A: Softr differs from vibe coding tools because it assembles apps from tested software building blocks instead of generating the entire application from raw code. Brodie said that distinction matters when businesses need secure, reliable apps rather than demos that may break later.

Q: Why does this matter for business teams now?
A: Business teams often need custom workflows that off-the-shelf SaaS tools do not fully support. Softr’s approach gives non-developers a way to build apps, portals, workflows, and automations around the way their teams actually work.

Q: What did the Softr demo show?
A: The demo showed a marketing agency client portal created from a simple prompt. The AI co-builder asked about clients, internal users, projects, tasks, campaigns, assets, authentication, and access levels before generating a connected database and app pages.

Q: Are AI-built apps automatically ready for business use?
A: No. Businesses should not assume AI-generated software is automatically production-ready. Brodie’s interview makes clear that real business apps still need secure data handling, user permissions, authentication, hosting, reliable components, and a structure that can scale beyond a prototype.

Softr’s approach highlights a practical challenge for business AI adoption. AI-built apps only become valuable when they can support real work. A generated screen may be useful for a demo, but a business app has to manage data, users, permissions, workflows, and changes over time.

For many teams, the software problem is not a lack of tools. It is the gap between how a business operates and how its purchased tools expect it to operate. When that gap becomes too wide, employees return to spreadsheets, manual steps, and disconnected workarounds because those systems feel easier to control.

The key point is that AI app builders may give non-developers a new path to custom software, but only if the platforms handle the technical layers business users should not have to manage alone. Databases, authentication, permissions, hosting, and workflow automation are not extra details. They are the difference between a prototype and an operational system.

Business leaders, operations teams, agencies, consultants, and small companies should pay attention because this type of tool could affect whether they buy software, build software, or keep working around software that does not fit. The decision is no longer only “Can we afford a developer?” It is also “Can our team safely build the workflow we need?”

The timing matters because AI has made custom software feel more accessible, but accessibility can create false confidence. If a team can generate an app quickly, it may also publish an app before fully understanding the security, data, and workflow requirements underneath it.

In short, Softr’s interview points to a more mature version of AI app building. The business value is not the prompt-generated interface alone. The business value comes from helping teams turn their own process knowledge into software that can actually run.

The real breakthrough in AI-built apps is giving business teams a practical way to shape software around the way they actually work, instead of stopping at faster prototypes.

Editor’s Note: This article was created by Alicia Shapiro, CMO of AiNews.com, with writing support, AEO/GEO/SEO optimization, image concept development, and editorial structuring support from ChatGPT, an AI assistant. All final editorial decisions, perspectives, and publishing choices were made by Alicia Shapiro.