Emerson College built 7 production apps with Claude for the cost of a license
Every IT department has a graveyard of problems that will never become projects. Too specific for a vendor product. Too small to justify a six-figure contract. Too far down the priority list to compete with the ERP upgrade. At Emerson College, two IT leaders decided to stop waiting and build the software themselves using Claude. Seven production applications later, the approach has a name, a repeatable methodology, and a $52,754 vendor cost saving to show for it.
The Problems That Would Not Die
Emerson’s facilities data was spread across spreadsheets, legacy systems, consultant files, utility bills, floor plan scans, and fax-era lease agreements. Finding anything felt like an expedition. Trusting what you found was harder. Each data set was isolated from the others, and without interconnection, the errors compounded over time.
The commercial facilities management market is mature, but for an institution managing fewer than thirty buildings, the gap between what those platforms offer and what Emerson actually needed was wide. Paying for capabilities they would never use while still needing heavy customization was the only option. So they lived with inefficiency.
Account management had the same problem. Help desk requests involving alumni account recovery, contractor access, remote students, or former employees requesting a W-2 required broad system knowledge, familiarity with exceptions, and the right documentation. Student employees could not handle them. The tickets escalated to senior staff and system administrators. On nights and weekends, when students staffed the desk alone, work waited.
️ What They Built
In fall 2025, Brian Basgen (VP, Digital and Physical Infrastructure) and Frankie Frain (AVP, IT Security and Infrastructure) started vibe coding in Claude. Vibe coding means running code you have not read. Their version had limits: they treated the code as flawed by default, constrained it, and tested it relentlessly against someone who knew the operation end to end.
The first project was account management. What started as a few help desk forms grew into a campus-wide privileged access management (PAM) system integrating more than twenty applications, from Wi-Fi and computer inventory to SSO, MFA, and DHCP. Security guardrails let student employees re-enable alumni accounts, manage group memberships, handle name changes, deploy computers, and manage email access through a single interface. The system saved $52,754 in vendor costs in the first few months after deployment.
The second project was GRID, a facilities information system that manages buildings, floors, and rooms across the campus portfolio. Interactive floor plans surface square footage and staff office assignments instantly. Utility dashboards track consumption across buildings and normalize for weather conditions, so a cold February reads in context. Commercial lease agreements, occupancy data, and role-based access for different user groups are built in. What had been scattered across dozens of disconnected sources can now be found in seconds.
GRID took around sixty hours at a keyboard to move into production. PAM took hundreds of hours more. Seven applications total are now running in production, including Zero, a system that started as a budget dashboard and became the tool for managing departmental budgets.
The Five-Step Methodology
The team organized their process into five stages. Every one of the seven applications followed the same path.
- Vision: Before any code, write a comprehensive development plan. Define what the system is, what it is not, who it serves, and what success looks like. This becomes the doctrine document, the anchor point for every subsequent conversation with the AI. Major architectural decisions must be recorded and fed back into the AI to prevent contradictory choices later. Skipping this step wastes time. The AI does not know your institution’s problems and is only as good as the context it receives.
- Data architecture: Design the schema next. Map the atomic data elements, the relationships between entities, what the system owns versus what it consumes, and the resolution rules for integrations. Getting this right early reduces the need to constantly restructure the database as features are added. Note that the AI will put key data elements into code or memory if you do not instruct it otherwise.
- Foundation: Start coding with basic functionality only. Create, read, update, and delete operations, basic lists and detail views, authentication, and basic security roles. For PAM, this meant a basic identity lookup and a single Active Directory integration. The goal at this stage is to prove the architecture works with real data and validate that the platform infrastructure (Docker, SSO, database connections) holds before complexity is added on top.
- Experience: Once the data foundation is stable and populated, build the interface. For GRID, this meant interactive floor plans with layer controls, category-specific detail views, and dashboards for electricity, water, waste, and steam usage. For PAM, it meant a flexible identity lookup, logging, and alert mechanisms. This step works well only because the first three steps give the AI the context it needs about what data exists and how it is structured.
- Operations: Evolve the application from a data viewer into an operational tool. Automated reminders, cross-cutting analysis, and decisions that generate new data. GRID includes a reporting suite that surfaces data problems. Zero grew from a budget dashboard into the full departmental budget management system.
Who Can Actually Do This
A vibe coder does not need to know how to write code, interact with a database, understand technology stacks, or know how routing works between applications. What they do need is deep operational knowledge of the problem. The team identified five skills that matter:
- Domain expertise: Understanding the practical operational details the AI will never know on its own. For PAM, that meant knowing which account types require which approval workflows and which security validations are non-negotiable for student employees.
- Data knowledge: Not SQL skills. Relational thinking. For GRID, this meant understanding that leases attach to the retail unit, not to the tenant, because the unit persists when the tenant changes. That is how you get a complete lease history. The AI cannot reliably define these structures on its own.
- Systems thinking: Understanding how systems authenticate, what security boundaries exist, and which system is the canonical source for each type of data. For PAM, this also meant driving the AI to build an encrypted credential architecture, because its default was to store credentials directly in the code. The AI will not automatically build identity validation gates or role-based access boundaries.
- Product sense: Knowing what makes software usable for the specific people who will run it. For PAM, the primary operators are student employees with limited experience. Auto-responses, clear alerts, and security guardrails for every workflow ensure the application leads the user rather than requiring the user to already know what to do.
- Relentless patience: GRID took around sixty hours. PAM took hundreds more. Running multiple prompts in parallel is possible but requires careful management to prevent sessions from interfering with each other. Every detail must be scrutinized and adapted until all outputs are intentional.
⚠️ The Governance Problem They Have Not Solved
The pace of AI-assisted development creates a genuine governance challenge. Changes are easy and quick to make, and the review process struggles to keep up. The team maintains code in version control and keeps the development environment separate from production. Review focuses on functional testing, input validation, and access verification. But using AI for code review has limits: it can inherit the same assumptions and blind spots present in the code it is reviewing.
For institutions considering this approach, the team’s advice is to build a review framework before the first deployment and expect it to evolve alongside the development process. They do not have a complete solution for the governance gap yet.
The Takeaway for Operators
The team is direct about what changed here and what did not. AI is an outstanding translator. It handled syntax. The intent, the thousands of design decisions behind PAM and GRID, came from people who understood the problems at an operational level. The AI had no idea what problems existed, what the lived experience with those systems was, or how the teams worked.
What shifted is the constraint. It used to be budget, or a vendor’s roadmap, or a developer you could not hire. Those barriers still exist in large ERP territory. But for the backlog of specific, mid-size operational problems that will never justify a six-figure project, the constraint is no longer technical capacity. It is knowing which problem is worth solving and making the time to build it.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
