Build and run your own CRM with Claude Code and Elements

In this video we build a CRM for a small sales team with Claude Code on Elements, from one prompt. The team gets a pipeline board, contacts and companies, follow-up tasks, a dashboard, a CSV export and an email at 8am with each rep's tasks for the day. Then we work out what it costs to run, about $55 a month all in, and look at what Elements gave the agent: the tooling that keeps it on track and the app framework it builds on. A CRM is one part of a business application. On Elements, the same application can hold the newsletter, invoicing, payments and products, with every customer record in one Postgres database, in place of a separate subscription for each. You get exactly the features your business needs, and you can change any of them by asking your agent. ## Setup We use VS Code with Claude Code in the lower left and a terminal in the upper right. Elements does not depend on the editor or the agent: the terminal, VS Code and the Claude Code desktop app all work, and so does any AI agent. In the terminal we start Elements, a project server that runs while you work: ```bash Terminal elements start ``` The browser opens on the starter app. The agent here is Claude Code with Opus 5.5. ## The prompt ```text Agent I want to build a CRM application for a small sales team. The team's data is private to the team. Two kinds of accounts: an owner and a rep. The owner invites reps by email. Everyone sees all the records, but only the owner can delete records or export. - Contacts: name, email, phone, company, an owning rep and notes. - Companies, each listing its contacts and deals. - Deals: name, company, value, stage (lead, qualified, proposal, negotiation, won, lost), expected close date and owning rep. - A pipeline board with a column for each stage and its total value. I want to be able to drag a deal to change its stage. - Deal detail: a timeline of logged notes, calls and emails, plus every stage change. - Tasks: a follow-up with a due date on a contact or deal. At 8 a.m. each rep gets an email listing their tasks that are due that day. - A dashboard: pipeline value by stage, deals won this month and open deals per rep. - Export contacts as a CSV. Seed at least one owner, two reps, five companies, 10 contacts and a couple of deals across the stages so that I can see what it looks like. ``` ## Claude Code builds the app on Elements While the agent works, the state in the terminal turns red now and then. The project server answers the agent in microseconds with the error, the agent fixes it, and the state goes back to green. About 20 minutes later the CRM is running. The agent finished with 47 passing tests and clicked through the app in a browser to check it. Its summary lists what it built and gives us demo accounts to sign in with. ## Trying the app We sign in as the owner and land on the dashboard: open pipeline, deals won this month, deals closing in the next two weeks, pipeline value by stage and open deals per rep. The pipeline board has a column per stage, and a deal's page has its details, its contact, follow-up tasks and a timeline. Every browser connected to the app sees changes as they happen, with no reload. The 8am email has a preview page in development, so we can read what a rep gets each morning before any email is sent. The app uses Elements UI, which comes with a set of themes (editorial, dashboard, playful and more). We ask Claude Code to try one, then go back. A stylesheet change shows in the browser almost instantly. ## What it costs to run Elements deploys to any Ubuntu server you reach over SSH, with providers such as AWS, DigitalOcean or Hetzner. Your agent walks you through the setup and can do it for you. We asked Claude Code for the cost, with prices as of November 11, 2026: - About $25 a month on AWS: a small app server with a disk and a public IP address, managed Postgres with storage, and email through Amazon SES at a few cents a month. - $30 a month for Elements, which covers two machines: your laptop for development and the server you deploy to. That comes to about $55 a month, or about $665 a year, as of November 11, 2026. AWS prices change, so ask your agent for the current figures ([EC2](https://aws.amazon.com/ec2/pricing/), [RDS for PostgreSQL](https://aws.amazon.com/rds/postgresql/pricing/), [SES](https://aws.amazon.com/ses/pricing/)). Each further machine is another license, for a bigger server or for more than one. ## The tooling Elements gives the agent ```bash Terminal elements build ``` The build result comes back almost instantly, in microseconds, because the project server holds the build state in memory and updates it on every save. The agent asks for the same result as JSON with `elements build -json`, or through the editor, and knows about a mistake as soon as it makes one. ```bash Terminal elements test ``` The agent wrote the tests, and their results come back in microseconds too. Tests are how you keep an app working as it passes from one agent session to the next, or to a person: if a new feature breaks something built months ago, a test fails. ```bash Terminal elements db ``` `elements db` opens a shell on the app's Postgres database, with the tables the agent created: users, teams, invites, companies, contacts, deals, tasks and activities. Having every part of the business in one database you can query is worth a lot. Locally the database comes with Elements; in production we recommend a managed database such as RDS, which adds backups. ## The app framework the agent builds on Each page is an `.ehtml` template, Elements' reactive HTML: TypeScript at the top, HTML below it that a person or another agent can read and maintain. The pipeline page imports the kanban board and other components from Elements UI, and `Session` and `LiveView` from `@elements/app`, which give the page its signed-in user and its real-time updates. Constructor attributes type-check the template, and a shared `AppLayout` template gives every page the same look. The tests are short and readable. Styles are plain CSS. Routes are functions you write, and every page is rendered on the server by default, which matters for search. Emails are HTML templates marked for email, and jobs run on a worker off the main process: the 8am task digest is one. Jobs are part of a deploy, with nothing extra to set up. It is all TypeScript. When we call a function that does not exist, `elements build` reports the error right away, and fixing it turns the state back to green. The checks run for the server and browser code. ## Try it yourself The CRM is one of the [demos on elements.dev](https://elements.dev/demos). Each demo has a "Run it yourself" command that creates the app on your machine from its scaffold and starts it.

About 20 minutes later we have our custom CRM application that Claude has built Sometimes we think, oh, the AI writes terrible code, it's all spaghetti and so on, but that's not true when it's using something like Elements. It's going to write quite beautiful code, very maintainable. So if I type elements build, I'm going to get an almost instant build result that shows me that the state is okay. That completes in about 10 microseconds. These tests, when you ask for them, come back very, very fast. And if you include all of the deployment that you would need, it comes out to about $55 a month to run this application. Hey everybody, in this video we're going to build a custom CRM, customer relationship management system from scratch using Elements built with Claude Code inside of Visual Studio Code.

Now a CRM system is a system for managing customer relationships, deal flow, keeping track of where different deals are in the pipeline, what stage they're in, managing tasks around that, things like that. Now there's obviously a lot of SaaS companies out there that provide CRM systems. So why might you want to build one for yourself? Well, one of the benefits of being able to build these days with artificial intelligence is that you can really get exactly what your business needs, exactly the features that you need, and you can get it very, very quickly and run it fairly cheaply. You don't need to have a development team like you used to have to have in order to build these things.

The second reason is that oftentimes our customers are finding that they want a centralized database with lots of different parts of their business combined into one application. So a CRM might be part of that. You might also have payments and invoices as another. You might have a newsletter that goes out every Friday as part of your blog and that's another part of the system. And you start adding more and more and more to the business, to a central business system that you can run. And being able to control all of that from your phone or from a Claude Code session on your desktop is very, very useful. If something goes wrong, you can just fix it immediately.

If you want a new feature, you can add it immediately. And you have an enormous amount of business intelligence at your fingertips because it's in one database that you have access to and that you control. So without further ado, let's build a customer relationship management system. I'm going to use Visual Studio Code for this, and again, just like any other Elements application, I will give you a little bit of a caveat that Visual Studio Code is a fantastic environment to use. It's what we'll use for our tutorials, but if you want to use Claude Code Desktop or the terminal directly, you can use any of those things. Elements doesn't care about your editor environment. If you're using an editor, Visual Studio Code will work really well with that.

We've got LSP integration with Visual Studio Code, but you can also do just as well with Vim or with Claude Code Desktop or something like that. Now down in the lower left here I've got Claude Code as an extension into Visual Studio Code because we our company has a Claude Code subscription but again you can use any model that you would like. Now just like with any Elements application the first thing we'll do up in the upper left terminal is I'll type elements start and that'll boot up the demo application or the boilerplate application and you'll see that open in the right. In the left we'll start with Opus 5.5 as the model and I'll just prompt my way through this.

I want to build a CRM application for a small sales team. The team's data is private to the team. Two kinds of accounts. There's an owner and a rep. The owner invites reps by email. Everyone sees all the records, but only the owner can delete records or export. I want a pipeline board that has a column for each stage with its total value and I want to be able to drag a deal to change its stage. At 8 a.m. Each rep gets an email listing their tasks that are due that day. All right, that was an epic prompt. I'll press enter and we'll let Claude get to work.

All right, about 20 minutes later we have our custom CRM application that Claude has built and it's running over here on the right. It looks like we have a good dashboard going on here. We'll walk through that in a second. We've got a pipeline board that we can look at that has I never know whether I'm pronouncing it properly, a Kanban board of different deals per each stage. And then we've got different tasks. So if I were to click on one of these, we can see follow-up tasks down here and some various information. We've got a timeline and some chat that we can provide here and all of that is built in such a way such that everyone who's connected to this application, every browser that's connected to it.

We'll see this data updating in real time without having to refresh the page. We've got a dashboard. We can export to CSV and a bunch of demo data, and then it talks about how it tested it. 47 tests passed. It clicked through the application in the browser to make sure everything worked. And there's a couple of emails that get sent out, and it's telling me here that I can go to localhost 4000 dev emails. We could do that here to see what they look like. It's saying dev emails daily tasks, and this is what the email is going to look like to one of the reps that they get every morning at 8 o'clock.

And then if we want to test sending an email, we can go to this particular URL here. We'll leave all that for now. Let's go back and take a look at the dashboard. Just kind of click around. It looks like we've got a nice graph here of lead, qualified, proposal, negotiation, won and lost with some sums of the various deals where they are in the pipeline and so you can run this yourself and click through it either have it built from scratch or we actually have a demo that has a CRM built as well and take a look at the various features that are here but I think one of the things to highlight here is that this was built completely custom per our specification and it works perfectly fine so even though this was built in 20 to 30 minutes I fully expect that all of the features in here will be completely working and you can continue to extend this application simply by prompting your way through and asking for additional features.

Now before we leave the application let me just do a little bit more. Let's play with just one other theme. I want to see it live right here on the application. Recommend one of the themes from the Elements themes that we can try and then we'll revert back once I've seen it. Elements ships with Elements UI and Elements UI has a couple of themes that's 15 to 20 themes or so that you can pick and that will provide you some very common types of styling that people typically want like editorial or a dashboard, it could be playful, etc. So it kind of mildly changed the theme here. So you can use one of those pre-existing themes or you can have your agent develop a custom style for you.

You can just tell it what you like and it will create one. Okay, go ahead and revert back to the original theme you had. I liked that better than this. When style sheets are changed, when the theme is changed or code is changed, you can see that reflected almost instantly in the browser over on the right because of hot module reload. A common question we get is how much does it cost to actually deploy and run this application yourself? Elements works with any Ubuntu Linux deployment machine, and so typically a provider of that would be AWS is the one we recommend, DigitalOcean is another one, Hetzner is a popular one that people use. The only real requirement is that it's not a platform as a service.

You're going to use the raw virtual hosting providers like Amazon or Azure or DigitalOcean. Once we have that, we can work with any Linux box as long as we can SSH into it. So is that hard? And what's the cost of owning that? The answer is it's not hard. As long as you have an agent running locally like I do here with Claude, they will walk you through what is required to do it, and it can do the entire setup for you. Amazon in particular is really well-suited for that, and Elements, once it's installed, will help your agent along to make the proper choices. The total cost of ownership if you're on Amazon, you can ask your agent, I actually asked it earlier, what's the total cost here using today's prices, and it went and got all the prices for us and came up with an estimate.

As of today, the price can change, but the price is $30 a month for Elements, which includes a deployment license and your local development. So that's two licenses for the price of one. And if you include all of the deployment that you would need, it comes out to about $55 a month to run this application. And if we walk through that price list, about just over $6 for the App Server and a couple other things you need here, about $12 a month for the database, plus the email is a couple of cents a month. And so the total Amazon bill comes to about $25, $26, and the Elements license for two machines will be $30.

So that ends up being about $55 or about $665 per year. And if you want to add more machines for more redundancy or if you want to have a bigger machine, you can get a bigger Amazon machine. The licenses for Elements will be per machine. So you get your development license, your laptop plus the deployment. That's going to be your first purchase will get you both of those and then each additional machine you have will be an additional purchase So overall does this make sense? I suspect that for a very complicated CRM systems This will be far less than what your subscription price would be for those but I think the real use case is for people who want to consolidate a bunch of different applications into one business application that they run from a central database and also if you want to have a lot of control over exactly what it looks like and exactly how it performs, then you can do that very well today with an AI agent like Claude Code combined with Elements, which gives it the application framework and the build tool and to be able to build something safely like this.

Let's start with the tooling that Elements provides. One of the reasons that the AI agent can be so effective at building something as complicated as a CRM system, is that Elements is providing it guidance. So if I type elements build, I'm going to get an almost instant build result that shows me that the state is okay. That completes in about 10 microseconds. And what the agent will use is Elements build JSON, or it can use the LSP protocol to connect and get real-time feedback that way. But this is a structured JSON result that the agent will get from the Elements project server, telling it whether or not there's any errors that it needs to fix.

And it will get that by the time the agent asks for it, it gets a result back typically in a couple of microseconds and so as soon as it makes a mistake it knows almost instantly and it can fix that mistake and move on and that makes a huge difference in being able to build things correctly. The second thing it does is it creates tests and if we type elements test you can see all of those tests come back and the first thing you notice that the agent created quite a few tests and tests are very useful for knowing that you've created something that's correct but even more useful for being able to maintain an application over time so that it doesn't regress as you pass it on from one agent to the next, from one session to the next, or even to human teams.

You'll know if you build something new and you broke something that was built months ago, you'll have a test that fails. The second thing you should note is that these tests, when you ask for them, come back very, very fast. In a couple of microseconds, you get the entire state of the test. That's because our project server keeps these things in memory such that the current state of the test is available instantly. And that's very important for agents to work effectively. The third thing I want to show you is that you have a database. And if you type Elements DB, you're going to be dropped directly into a database shell where you can see the tables that were created like users, teams, tasks, invites, deals, contacts, companies, etc.

And you can go and actually just run queries against that data, select star from users, for example, and we'll get back some of our three users that were created. Having a central database like this, if you're a business owner, is a superpower. You can have an employee or you can have an AI agent connect to the database, read only, and pull in intelligence and information about your customers that can help you significantly. I found that running my own business this way is really a fantastic way to do it. If you have data that's spread out all over across various SaaS applications, it's much harder to look at that data and get intelligent insights out of it.

So having your database that you can just log into like this is fantastic and that comes with Elements, the database cluster comes with Elements when you're local. If you deploy off to Amazon, we recommend that you get RDS or a hosted database service that gives you some extra services like database backups and things like that. Okay, that's the tooling for Elements. Next up, let's take a look at some of the code that it wrote. In Visual Studio Code, I opened up the Explorer view and opened up the app folder and pages, and these are all the pages that we have in the application. There's quite a few of them, and I've opened up the pipeline page.

The template EHTML file, this is our HTML file that has the extension EHTML for Elements HTML. And this is our custom-built reactive HTML language that's been in the making for over a decade. Let me walk through a couple of items in this file. And the thing to take away from this is that the agent is using the application framework from Elements to be able to build quickly and effectively. So it doesn't have to rebuild all of these primitives every single time it works on a new application. We've written tons and tons and tons of code that you can think of as kind of an operating system for the agent to be able to build an application as sophisticated as a CRM very quickly.

So this is one example of that. This is the template file. It has some code up at the top that doesn't look like HTML, but that's the way we built it. So you can have TypeScript right next to the HTML. And here's some examples of user interface Elements that are being imported from the Elements UI package. And this is the Kanban. This is a sort of complicated user interface structure that lets you drag deals from one stage of the pipeline to the next. And here's a bunch of different user interface components that it got out of the box from the Elements UI package. And then you can see other primitives that it pulls from Elements app like Session and LiveView, which is what gives us real-time publish and subscribe.

Now if I clear this out and scroll down, you'll see the HTML and the thing you should notice about HTML is it looks just like regular HTML and it's written in such a way that it's human readable and you can hand it off to another agent or you can hand it off to a human and it's very, very maintainable. It's just essentially regular HTML with a little bit of syntax extension. These right here are constructor attributes that give us type checking for this template. And down here in the body, you can see that there's a template that's called app layout that's used across all of our pages. And we provided some properties here, but the app layout is something that gives our application a consistent look.

So you can have reusable user interface templates that get created if we were to jump into this app layout, you could see what it looks like. And it itself reuses a bunch of templates that are created like this. And so I don't want to make this into a coding tutorial, but the point of this is that this is a well-factored code base that, despite the fact that it was written by AI, sometimes we think, oh, the AI writes terrible code, it's all spaghetti and so on, but that's not true when it's using something like Elements. It's going to write quite beautiful code, very maintainable, and it's going to write the user interface Elements in a way that you can be easily handed off to either a human team or to another agent.

Next up, let's take a look at the tests. We saw the test from the tool perspective. This is what the code looks like for the test. You can see it's very easy for a human to read, very easy to hand off to another agent, and the agent will really love to write tests, and this is something that Elements gives it to be able to create an application that is maintainable over time.

The styles for the page is not a custom framework. We really try and Elements not to abstract away standards and languages. We just let the agent or the human write CSS using the normal CSS language. We don't have a custom thing for that you plug in. You just write regular CSS. And routes inside of Elements are just functions that you write. There's not a special page or a special directory path You just write a function. So it's much more like Express or like using regular Node.js. And we import the HTML into that route and create a new instance of it, passing it the data that it needs. So all of the pages and Elements are server-rendered by default.

So every page you have is particularly important if you're writing a marketing page or a blog or something like that. You want that to be good with SEO. In order to get that, you need server-side rendering to work. Sometimes with client-side reactive user interface libraries you will not get that by default, so be careful. With Elements you definitely do get it.

Next up, let's go into the emails folder. There's a couple of emails that are written, that are sent to employees as part of this application. All of the framework for building, writing emails, and sending them is baked into Elements. You just need the last mile. You need some kind of service delivery platform like Amazon SES, there might be a couple of others out there that do this, just find the one that has the best price and then you will get the ability to deliver the emails to your customers or to your employees. And emails are just HTML files just like any other one, they just have this special build tag called at email and that lets us link up all the styles and treat this specially because email clients can be finicky about how this stuff gets displayed and so by tagging it with that email, we say take all the extra precautions that are needed to be able to make sure that this gets displayed properly.

And then finally we have a jobs folder here and there's a couple of jobs that get created. Jobs in Elements are a way to create a task that gets processed by a worker off the main CPU of your application. And if you're building anything complicated, you will almost always have some kind of jobs or a job queue and oftentimes with development platforms as a service, you have to pay for that for pay for that extra, but in Elements, it's just baked in. And even when you deploy, it's automatically handled as part of your deployment. So you don't need to do anything special. So here's an example of the send task digest, I presume this sends a digest to the employee with their various tasks.

And this is the code that will do that. And this will get queued up into a queue and processed off of your main application automatically. Okay, so this is a little bit technical, but I wanted to give you some sense of the fact that Elements is providing this framework code, we call this runtime code or runtime packages that allow the agent to focus exclusively on the application you want to build, not reinventing these primitives over and over and over again. Now if you ask the agent to build something from scratch, it will reinvent those primitives. So it will not do it particularly well, but it will try and you will end up with an application that is a spaghetti mess and is not maintainable beyond a session or two.

The last thing to note in this is that it's all TypeScript, if you haven't picked up on that already. So all of this is type checked, and if you make any kind of type checking error, you'll see that instantly in the terminal. So for example, if we type elements build here, and I call some kind of bogus function, I get a build error, and it happened very quickly and if I get rid of that and say if it goes away and we're back to a state okay. Now you might think that an agent doesn't need type checking or doesn't need these types of errors and I strongly disagree with that. We've seen empirically that it makes a huge difference in the ability to create an application to know whether you did it correctly the first time without waiting for these bugs to show up for your users or at runtime.

Otherwise the agent has to do static text analysis which is more difficult and uses more tokens. So type checking is a really good thing. The thing that Elements provides for it is the Microsoft TypeScript compiler is baked directly into the Elements program. But it's the Microsoft type checking that you would expect if you used the TypeScript compiler directly. So we have that baked in and we also do it for server and browser targets, not just for the server. Okay. That was a very technical deep dive, but I wanted you to see that there's a lot going on under the hood here that Elements provides to your agent. All right, I hope you guys had fun building this with me.

Install Elements, try it out, and see whether you can build your own CRM system that does exactly what you want. If you don't feel like doing that and you want to start with one as a scaffold, you can go over to our website, elements.dev, to demos, and the first demo is a CRM demo. If you scroll down a bit, you'll see a run-it-yourself prompt here. If you click that and paste it into your terminal or into a Visual Studio Code terminal, it will create the app from the scaffold, start it up, and you can start playing with a demo right away. Let me know if you have any questions in the comments.