Nursa gave every employee AI building tools; its first prototypes became real products

Nursa connects healthcare managers who need shifts filled with qualified clinicians. Its founder Curtis Anderson and Lovable head of revenue Lauren Rhode discuss what happened when people throughout Nursa could build software, including employees whose experience came from outside engineering. Lovable is a founding partner of the conference.

Rhode asks how many people in the audience have not only tried Lovable but put an application into production, connected to data and used by others. She sees a gap between the early excitement around “vibe coding” and the harder work of shipping software that supports a business.

She does not want to dismiss the earlier moment: it revealed demand among people who were not software engineers to build and ship. Rhode says Lovable customers increasingly want to take those prototypes further into production.

Anderson says Nursa first used AI mainly for content. He also gave the tools to his children and watched how they approached them. At work, the company set aside time and resources to test what the technology could do.

About six months later, Nursa’s product leader Nenad called him after trying a new Lovable capability and building a new product. The company had given Nenad a mission to explore a separate product and business line, rather than depend immediately on the tools throughout its existing engineering process.

The target was nursing students who need clinical hours at healthcare facilities. Nursa had considered helping them connect with those opportunities but had not treated the idea as time-sensitive. Anderson says the product later became part of its expansion and had several thousand student users after not existing 15 months earlier.

After that experience, Nursa gave everyone access to Lovable. Anderson says the approximately 160-person organization has since seen every employee build something, resulting in thousands of projects. He describes the tool as an approachable place for people who are uncomfortable with code to experiment.

Rhode describes two adoption patterns: leadership can put tools in the hands of the entire knowledge workforce, or teams can start from individual problems and bring their work upward. In either case, she says, organizations need visibility and governance to identify the strongest ideas and prepare them for production.

At Lovable, an account executive built the first version of Catalyst, an internal workspace used by sales and customer-facing teams. Rhode says it brings together information that had been spread across several applications; the revenue-operations team subsequently hardened the initial version.

Anderson describes an accountant at Nursa building a tool to manage commissions and connect information from the customer relationship system. It resembles the Lovable example, but was built around Nursa’s own processes by someone who understood that work.

A retired parole officer at Nursa also built an initial credentialing application. The company needs to verify clinicians quickly, sometimes less than a day before a shift. Anderson says the first version was not something a backend engineer would have been proud of, but accelerated a solution the organization now uses.

Anderson views speed and the context held by people close to customers as advantages. He says Nursa had cut more than $1 million in non-headcount operating expenses over 15 months and reduced its dependence on third-party vendors by more than 80%. Those figures are his account of Nursa’s experience.

Dell asks what must be true before a non-engineer’s application can support a business in production. Anderson points to a culture willing to tolerate ambiguity, access to relevant context and governance that protects the environment where people build.

He asks teams to consider the actual worst case and the potential upside. For Nursa, he says, that framing helped people move past a general fear of experimentation. The question of what information builders can access remains a governance issue.

As implementation becomes cheaper, Anderson argues that more of it can be placed in the hands of people who know a customer’s problem. Earlier product and design processes, in his account, helped justify scarce engineering time; he thinks the cost of trying some ideas has changed.

As an executive, Anderson says he is shipping more code than at any time since Nursa’s first year. He argues that leaders need direct experience with the tools to understand what their teams can do and how the organization is changing.

In hiring, he asks candidates for examples of handling ambiguity and of persistence through difficult situations. His emphasis is on demonstrated willpower and tolerance for uncertainty, with tools and other support used to fill in gaps.

Rhode says successful organizations give more people the ability to build while retaining guardrails, structure and priorities. A hackathon focused on specific leadership-defined problems can reveal ideas from interns or experienced employees with deep knowledge of a subject.

She says Lovable is also working on ways for leaders to see overlapping projects and turn promising work into applications used across a company. The aim is to combine experiments at the edge of an organization with some way to select and develop the results.

An audience member asks about the other side of making everyone a builder: the volume of material and the assumption that more is necessarily better. How can a company prevent a flood of additions from crowding out the value of taking things away?

Anderson says Nursa has added seven revenue lines and extended building across the organization, creating orchestration questions. He offers a design system as an example: without a shared anchor, different contributors could repeatedly change the same button and disrupt a consistent experience.

He argues that decentralized building needs structure, while seeing value in the possibility of serving smaller groups with more tailored products. Rhode returns to people, process and technology: more people need access and support, but leaders also need ways to sort and guide ideas.

Rhode says Lovable sees an average of 4.7 disposable applications built before a person builds something load-bearing or shipped to production. She says that observation comes from more than 70 million projects. Her interpretation is that practice and freedom to experiment can precede a more durable result.

She describes potential product features that would help people find related work, recognize themes or avoid rebuilding an application that already exists. The problem is not simply to stop experimentation, she says, but to give organizations tools to manage it.

Dell distinguishes quantity from quality. In his view, making many things can help people practice, but teams still need standards that reflect their own work, the ability to combine expertise and enough organizational tolerance for ambiguity to learn.

Another audience member asks how to help people who remain resistant to the tools after demonstrations and hackathons. Rhode notes that even enthusiastic organizations have different views about how far to take the idea that everyone is a builder.

Anderson describes Nursa’s transition after he and Nenad had built the new product. Anticipating resistance from a conventional engineering mindset, he says he changed team assignments and priorities and cleared his calendar for six months to work alongside teams.

He says four people quit on the first day, telling him they did not want that direction for their careers. On the second day, a product manager made an application showing flames and a countdown to what the team viewed as an impossible deadline.

At a town hall, Anderson framed the change as a commitment despite uncertainty about which individual changes would last. He asked employees to help whether they felt optimistic about the company, thought it needed a reset or believed it needed a more dramatic intervention.

For six weeks, Anderson says, the organization shipped almost nothing. Output then increased, and he reports that its smallest-ever team shipped more code in six months than it had in the previous seven years. He credits people and leaders willing to stay involved through a difficult transition.